Project

General

Profile

Ideas for Google SoC » History » Version 26

Wim Dumon, 03/31/2014 12:57 PM

1 1 Pieter Libin
h1. Ideas for Google SoC
2
3 13 Koen Deforche
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.
4 1 Pieter Libin
5 14 Koen Deforche
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
6
7 5 Koen Deforche
Contact information: koen@emweb.be or the Wt interest mailinglist: witty-interest@sourceforge.net.
8
9 1 Pieter Libin
h3. WebKit integration
10
11 13 Koen Deforche
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.
12 1 Pieter Libin
13 13 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 Garcia (contact him through the Wt interest mailinglist), which can be found at http://gitorious.org/wtdesktop.
14 1 Pieter Libin
15 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.
16 1 Pieter Libin
17 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.
18 1 Pieter Libin
19
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.
20
21 13 Koen Deforche
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.
22
23
Required expertise: Good C++ knowledge, some familiarity with GTK, Qt, and CMake will be useful.
24 1 Pieter Libin
25 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.
26 1 Pieter Libin
27
h3. Widget set mode
28
29 14 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 and fragment-based history management.
30 4 Koen Deforche
31 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).
32 4 Koen Deforche
33 20 Charles Brockman
Improvements to widget set mode will allow easy development of "OpenSocial":http://docs.opensocial.org/display/OS/Home applications in Wt.
34 4 Koen Deforche
35 14 Koen Deforche
Required expertise: Good C++ knowledge, template meta programming and type traits, some JavaScript knowledge.
36 4 Koen Deforche
37 1 Pieter Libin
h3. Wt Designer
38
39 14 Koen Deforche
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.
40
41 15 Koen Deforche
h5. Wt Designer based on Qt Creator / Qt Designer
42 14 Koen Deforche
43 4 Koen Deforche
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.
44
45
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.
46 1 Pieter Libin
47
More details (detailed steps, roadmap, possible blockers, etc) here: http://article.gmane.org/gmane.comp.web.witty.general/4293
48 14 Koen Deforche
49 15 Koen Deforche
h5. Wt Designer based on a (XHTML-like) template language
50 1 Pieter Libin
51 15 Koen Deforche
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.
52 1 Pieter Libin
53 15 Koen Deforche
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.
54
55
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
56
57
h5. How to tackle ?
58
59
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.
60
61
Required expertise: Good C++ knowledge, requires functional analysis and good communication.
62 6 Koen Deforche
63
h4. MVC integration of Wt::Dbo models with Wt views.
64
65
* Implement a WAbstractItemModel (e.g. WDboQueryModel) that allows iteration of query results.
66
* There could also be support for editing/viewing data of a single Dbo.
67
68
Required expertise: Good to Expert C++ knowledge (template meta programming)
69 7 Koen Deforche
70 12 Omer Katz
h3. Modifications of WTemplate to provide a full grown templating system
71
72
Goals:
73
* Wt will create widgets based on tags in message bundles.
74
* Each property can be set through an attribute.
75
* Creating a declerative markup that can be generated by an IDE.
76
* Creating a templating language that can take a model and generate a display for it.
77
  Possible commands are: If, Else, Foreach, While, Query
78
79
All of those features should be disabled to discard this overhead when working on thight embedded machines.
80 1 Pieter Libin
Instead of binding widgets like now you would just get them using resolve.
81
82
This idea relates also to the Wt Designer idea, the second approach.
83 16 Koen Deforche
84
h3. Backends for Wt::Dbo
85 17 Koen Deforche
86 26 Wim Dumon
Currently (April, 2014), Wt::Dbo supports only SQL backends (SQLite3, mysql, mariadb, postgresql, firebird, oracle). Support for more databases (MSSQL) is welcome. Additionally, we would like to support backends for NoSQL databases.
87 17 Koen Deforche
88 26 Wim Dumon
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.
89 18 Omer Katz
90
h3. Widget (Controller) <-> Model Integration
91
92
The current situation is that only a few of Wt's widgets support models.
93
This situation complicated the development of widgets who have a datasource like a database, a webservice, another process ect.
94
The following code demonstrates how it should be implemented.
95
Wt should have a generic model mixin which will attach itself onto a widget like this:
96 19 Omer Katz
<pre>
97 18 Omer Katz
template <class Widget>
98
class WModel;
99
100
template <template class Model, class Widget>
101
class WModelAttacher;
102
103
 // MyModel only applies to WLineEdit, this can be anything using a template parameter
104
class MyModel : public WModel<WLineEdit>
105
{
106
public:
107
  MyModel(WLineEdit &widget)
108
  : WModel(widget) // attaches change of value/values signals to the model to a uniform valueChanged
109
  {
110
    modelValueChanged.connect(SLOT(this, foo)); // if something changes in the model raise this
111
    valueChanged.connect(SLOT(this, bar)); // If something changes outside the model, update the model which will update the datasource
112
  }
113
};
114
115
// ...
116
117
class SomeApp : public WApplication
118
{
119
  WModelAttacher<MyModel, WLineEdit> *widget; // Creates a combined widget
120
};
121 19 Omer Katz
</pre>
122 25 Sean Dacquis
123
Required knowledge: Good experience with C++, Extensive experience with policy based design or will to learn it and MVC