Wt

h1. Ideas for Google SoC

This page lists ideas for Google SoC 2010 applications for Wt, pending the approval of Emweb as a mentoring organisation. The page lists ideas that come from community members, project maintainers, in no particular order. We recommend interested students to show interest on the mailing list and discuss with the community the idea that they would like to work on before applying formally with Google SoC.

In addition the the summary of ideas here, an interested student may also wish to look at the extensive discussion that happened on the mailing list: http://thread.gmane.org/gmane.comp.web.witty.general/4611

Contact information: koen@emweb.be or the Wt interest mailinglist: witty-interest@sourceforge.net.

h3. WebKit integration

It would be fantastic to have WebKit integrated with Wt. The level of integration may evolve over time, as are the possible applications. The combination of both a top-notch browser implementation, together with a web framework, all in C++, provides a whole world of new possibilities from new application options to kludge-free automated test frameworks based on an actual browser and rendering logic.

The first step is to combine WebKit with the built-in httpd to provide a desktop application using Wt. This could be useful for distributing an off-line version of a Wt application or during development. The webkit would be configured to act as a single application (instead of as a general purpose browser). Some preliminary work has been done and the project has been bootstrapped by Pau Garcia (contact him through the Wt interest mailinglist), which can be found at http://gitorious.org/wtdesktop.

In a second step, some of the widgets provided by Wt could be made aware of the integration with webkit to provide improved functionality. For example, WFileUpload could use a native file open widget instead of HTML. Other features are the binding of WApplication::quit() to exit the actual application, and the ability to control and use the native menu provided by the Qt or GTK toolkit from Wt code.

A third level of integration is to allow introspection of the DOM inside WebKit from a Wt application session. This could become the basis for an automated testing framework which verifies that the widget tree and the DOM tree are in sync. By querying the DOM for information on the location and CSS properties of widgets, it can be checked that the application works properly. By allowing for events to be simulated on the DOM tree, the application can be checked for correct event handling.

The fourth level of integration is to by-pass the HTML/JavaScript and HTTP protocol for certain rendering steps. For example, a new WPaintDevice could be developed which paints directly instead of encoding it first as SVG or HTML Canvas5 JavaScript. This would allow significant speedups for vector graphics.

Another idea that circulated on the mailing list was to target QML for rendering certain parts of the user interface, skipping the webkit dependence and targetting directly Qt. This would result in even better performance and be more light weight.

Required expertise: Good C++ knowledge, some familiarity with GTK, Qt, and CMake will be useful.

The scope and goals of this idea can be adapted to the skill set of the student, since for every additional level of integration, more detailed intimate knowledge of WebKit and Wt are required. Since the project has already been bootstrapped, the student will be able to more directly start actual development rather than be busy with setting up and configuring the build system.

h3. Widget set mode

Since about a year, Wt includes a so-called widget-set mode. In this mode, a Wt application does not take responsibility to render the entire user interface, but only selected 's. The Wt application is loaded as a JavaScript library, which then renders into these <div>'s, which then correspond to a set of "top-level" widgets. Any of Wt's features may be used inside such a widget, including portable vector graphics and fragment-based history management.

This would allow a Wt application to also expose a JavaScript API, such as for example Google Maps, but this has not yet been provided. To provide support for this in the Wt library, it would require that a Wt application can extend its JavaScript object with JavaScript methods that map onto C++ methods, which assumes a system that helps as much as possible to convert between JavaScript objects and C++ data structures (for example based on maps).

Improvements to widget set mode will allow easy development of "OpenSocial":http://docs.opensocial.org/display/OS/Home applications in Wt.

Required expertise: Good C++ knowledge, template meta programming and type traits, some JavaScript knowledge.

h3. Wt Designer

A lot of discussion has been going on over the years on a visual designer tool for Wt. Inevitably, many directions can be taken and proponents of different ideas can be found on the mailinglist.

h5. Wt Designer based on Qt Creator / Qt Designer

Since Wt shares alot with Qt, in terms of API and programming model, it should be possible to adapt Qt Designer to design Wt widgets.

In a first step, the .ui format used by the Qt Designer tool and User Interface Compiler (UIC) could be adapted to so that it can be used to instantiate a custom Wt widget at runtime, or can be used to compile to a C++ file.

More details (detailed steps, roadmap, possible blockers, etc) here: http://article.gmane.org/gmane.comp.web.witty.general/4293

h5. Wt Designer based on a (XHTML-like) template language

Another line of thought is to create a Wt application that would allow the construction of "empty" widgets, through a web application. The advantage of this approach is that contrary to t Designer, the widgets would render on the final web application as they render in the Wt. The product of this designer Wt application would be an HTML-based template. Any .ui interface etc. would mean unnecessary overhead in the development cycle etc. etc.

This approach thus centers around an (improved) templating widget (current, WTemplate, is really very minimalistic, supporting only string substitutions), which has a counter-part implementation that provides an editing mode.

This would require a start from scratch. The designer application can still be a desktop application, using the Wt / WebKit integration approach as above, or one could still consider to implement the whole application in Qt

h5. How to tackle ?

This idea will first require some discussion on the mailing list. Both approaches seem valid and have there merits, and both are alot of work. The first approach would require getting to understand Qt Designer, the second approach requires a lot of original code.

Required expertise: Good C++ knowledge, requires functional analysis and good communication.

h4. MVC integration of Wt::Dbo models with Wt views.

• Implement a WAbstractItemModel (e.g. WDboQueryModel) that allows iteration of query results.
• There could also be support for editing/viewing data of a single Dbo.

Required expertise: Good to Expert C++ knowledge (template meta programming)

h3. WSocketNotifier

Implement WSocketNotifier (like QSocketNotifier) properly with a custom select loop. The current implementation (on httpd) tries to tie into asio's select loop, but asio does not support this use-case very well (with socket numbers instead of boost asio's socket abstraction).

It is also possible to wrap a socket completely to WSocket and define specific use cases for Wt applications communicating with other applications/web services etc... Given the convenience of asio, it probably makes sense to define an API in terms of boost::asio sockets.

h3. Modifications of WTemplate to provide a full grown templating system

Goals:

• Wt will create widgets based on tags in message bundles.
• Each property can be set through an attribute.
• Creating a declerative markup that can be generated by an IDE.
• Creating a templating language that can take a model and generate a display for it. Possible commands are: If, Else, Foreach, While, Query

All of those features should be disabled to discard this overhead when working on thight embedded machines.
Instead of binding widgets like now you would just get them using resolve.

This idea relates also to the Wt Designer idea, the second approach.

h3. Backends for Wt::Dbo

Currently (March, 12, 2010), Wt::Dbo supports only a single backend (SQLite3), with a PostgreSQL backend being developed. Support for other databases is thus welcome. More specifically, we would like to support MySQL through "libdrizze":https://launchpad.net/libdrizzle, but also backends for other SQL and NoSQL databases.

The API for adding a backend is quite light-weight (, and an automated test suite is in place to check that the backend works well.

h3. Widget (Controller) <-> Model Integration

The current situation is that only a few of Wt's widgets support models.
This situation complicated the development of widgets who have a datasource like a database, a webservice, another process ect.
The following code demonstrates how it should be implemented.
Wt should have a generic model mixin which will attach itself onto a widget like this:

template
class WModel;

template
class WModelAttacher;

// MyModel only applies to WLineEdit, this can be anything using a template parameter
class MyModel : public WModel
{
public:
MyModel(WLineEdit &widget)
: WModel(widget) // attaches change of value/values signals to the model to a uniform valueChanged
{
modelValueChanged.connect(SLOT(this, foo)); // if something changes in the model raise this
valueChanged.connect(SLOT(this, bar)); // If something changes outside the model, update the model which will update the datasource
}
};

// ...

class SomeApp : public WApplication
{
WModelAttacher *widget; // Creates a combined widget
};

Required knowledge: Good experience with C++, Extensive experience with policy based design or will to learn it and MVC