Wt GSoC 2010

Here is my list of ideas that are related to Wt, maybe they would fit for Wt GSoC 2010.

1. as about qt-wt integration: Considering that even well tuned browsers like the webkit based ones on embedded devices, would make sense to create a rendering engine for wt, that interacts with the Qt Declarative UI (QML). Such a combination would result in a very fast client and very fast server for deploying services on embedded devices

2. Implement WSqlQuery/WSqlModel etc family, as QSqlQuery/QSqlQueryModel . The Wt::Dbo family is nice, but they do not provide at the moment the integration with views.

3. The already proposed idea about using Qt Designer to design Wt widgets, might be a wrong direction. In my opinion a better solution would be 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 Wt 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 a html template. Any .ui interface etc. would mean unnecessary overhead in the development cycle etc. etc.

01
March 9th, 2010 8:00 am

Interesting idea !

Do you have any experience with QML? Do I understand it correctly that by this idea, we would emit QML + JavaScript from Wt (instead of HTML + JavaScript) and target a custom viewer rather than a web browser or perhaps a combination of both ?

I think we should definitely add this to the Ideas page, but also discuss better what it means, and especially, how feasible it is ?

I am not sure WSqlQuery is needed, as it seems to overlap with Wt::Dbo::Query, but I do agree MVC integration of Wt::Dbo is needed. I’ve added this to the wiki Ideas page.

Now the HTML-based Wt Designer is a fantastic idea indeed. But it also has a number of
non-trivial challenges: how do we connect signals with slots? Wt does not have a moc and
does not use string-based signal/slot connections. how do we let the Wt Designer learn about new widgets ?

I do agree that you have the same issues with the Qt Designer approach to a large extent, so it makes sense to go by a HTML-based approach
rather that Qt…

I think this is all pretty difficult (I think it will definitely be the heardest Idea on the list), unless I am missing an obvious solution ?

Leave Your Comment

Name*
Mail*
Website
Comment