Project

General

Profile

Ideas for Google SoC » History » Version 11

Omer Katz, 03/09/2010 12:48 PM

1 1 Pieter Libin
h1. Ideas for Google SoC
2
3 3 Koen Deforche
This page lists ideas for Google SoC 2010 applications for Wt, pending the approval of Emweb as a mentoring organisation.
4 1 Pieter Libin
5 5 Koen Deforche
Contact information: koen@emweb.be or the Wt interest mailinglist: witty-interest@sourceforge.net.
6
7 1 Pieter Libin
h3. WebKit integration
8
9 9 Koen Deforche
The idea is to integrate WebKit into Wt. The level of integration may evolve over time, as are the possible applications.
10 1 Pieter Libin
11 3 Koen Deforche
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, which can be found at http://gitorious.org/wtdesktop.
12 1 Pieter Libin
13 3 Koen Deforche
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.
14 1 Pieter Libin
15 3 Koen Deforche
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.
16 1 Pieter Libin
17 3 Koen Deforche
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.
18
19 1 Pieter Libin
Required expertise: Good C++ knowledge, knowledge of or willing to learn the CMake build system, familiarity with GTK or Qt application development.
20
21 4 Koen Deforche
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.
22 1 Pieter Libin
23 4 Koen Deforche
h3. Widget set mode
24 1 Pieter Libin
25 4 Koen Deforche
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 <div>'s. The Wt application is loaded as a JavaScript library, which then renders into these &lt;div&gt;'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.
26
27 1 Pieter Libin
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).
28 4 Koen Deforche
29
Improvements to widget set mode will allow easy development of OpenSocial applications in Wt.
30
31
Required expertise: Good C++ knowledge, some JavaScript knowledge.
32
33
h3. Wt Designer
34
35
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.
36
37
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.
38
39 10 Pau Garcia i Quiles
More details (detailed steps, roadmap, possible blockers, etc) here: http://article.gmane.org/gmane.comp.web.witty.general/4293
40
41 6 Koen Deforche
Required expertise: Good C++ knowledge, experience with Qt Designer is a plus.
42
43
h4. MVC integration of Wt::Dbo models with Wt views.
44
45
* Implement a WAbstractItemModel (e.g. WDboQueryModel) that allows iteration of query results.
46
* There could also be support for editing/viewing data of a single Dbo.
47
48
Required expertise: Good to Expert C++ knowledge (template meta programming)
49 7 Koen Deforche
50 8 Koen Deforche
h3. WSocketNotifier
51 7 Koen Deforche
52
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).
53 11 Omer Katz
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 ect.