I am happy for the positive reactions about the listed ideas :)
> Do you have any experience with QML?
Unfortunately not too much, but interested to have a ride :)
> by this idea, we would emit QML + JavaScript from Wt
indeed... that is what I thought, so having once the experience with
Wt, it would not be difficult to write the rendering code... If one
avoids using html template, then it would be possible to deploy the
same logic, just change the rendering.
> + JavaScript) and target a custom viewer rather than a web browser or
> perhaps a combination of both ?
indeed... and the result is a faster and better user experience! and
at the end. ... qt is everywhere :)
> 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.
Well I was thinking about the QSqlQuery family. Specially
QSqlQueryModel and WSqlTableModel. I find QSqlQueryModel practical for
several situations, where one would have to write several lines of
Wt::Dbo code
>> 3. The already proposed idea about using Qt Designer to design Wt
>> widgets, might be a wrong direction. In my opinion a better solution
> Now that 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.
I will call our famous application BeDesigner (from BabelEngine.org I
will probably implement this anyway).
As we were talking about a tool that helps to design. The workflow of
the BeDesigner would allow to build up user interfaces by allowing to
"insert" Wt widgets ( and plugin widgets!) in different parts of a wt
page. This insert could be triggered through an "insert" button in the
"host" widget. One would create settings dialogs etc. to set
properties of the widgets, etc. The BeDesigner application would build
in memory a "Wt tree", and based on this tree one could generate
directly C++ code (or generate xml, then generate C++ code form xml
etc. ) As in any c++ generated code, one would include some other "non
generate file" where the slot handling, etc. would be manually
implement.
> how do we let the Wt Designer learn about new widgets ?
Through widget factories implemented in pluggins. (I started earlier a
discussion answered this questions earlier. )
> 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 ?
Do not se why would it be a problem to generate sthg. like
class GogosWidget: public WtContainerWidget
{
class GogosWidget
{
#include "GogosWidget.HardCoded.h
private:
WidgetType1 * widget;
}
};
> Regards,
> koen
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> witty-interest mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/witty-interest
>
--
rgrds,
mobi phil
being mobile, but including technology
http://mobiphil.com
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
witty-interest mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/witty-interest
