Hey,
If one would want to retrofit Qt's API on Wt's bastard dialect of it, there
are however some fundamental draw-backs, from the top of my head:
- events (mouse/key) are now nicely filtered by Wt based on connectivity --
e.g. a mouse click event is totally ignored if there is no widget listening
for it. Because Qt does this using virtual functions, one cannot know
whether this function has been re-implemented and thus you cannot do this
filtering.
- Wt embraces CSS as a fundamental constraint (or feature, depends on how
you look at it) of layout in a browser. Qt fundamentally assumes it is
painting everything. Merging this is tough and will require a compromise,
which will necessarily be bad. I would be surprised if Qt is modular to the
extent that you can express that a backend does not paint everything to
bitmaps).
- Wt does not assume one process = one Application. I'm not sure how
fundamental this is baked into Qt, nor how you could make this "optional".
Of course (for us) there is the business side of it, which starts with: how
big is the market for this, and does the size of the market justify the
initial and continuous investment ? In our experience, more and more users
that start with Wt do not have any Qt experience or have never heard of it.
The few users that I know of that
actually do a single source desktop/web application, do not actually use Qt
for the desktop part !
It is probably less daunting to experiment with some true web-like backend
(not the current bitmap-based hack!) functionality in Qt (e.g. get
QPushButton to render as an HTML5 button) trying to work through the
exercise of using Qt's modularity to implement a radically different
back-end without the legacy of an existing Wt API, than to somehow merge
the two code-bases ? I would be astonished, and intrigued, if it can be
done.
Regards,
koen
2013/1/18 Pau Garcia i Quiles <pgqui...@elpauer.org>
>
>
> On Fri, Jan 18, 2013 at 10:42 PM, Jason H <scorp...@yahoo.com> wrote:
>
>> With Qt5 here, Qt has been highly modularized.
>> Several of us think it would be "really cool" if we could unite Qt and
>> Wt. AFAIK, Boost and Qt's implementation are the only limits? Once things
>> were converted over to QObjectsand the http server was ported, well the sky
>> is the limit.
>>
>> What would the barriers be to getting Wt to merge with Qt?
>>
>>
> The only serious problem is the business model for Emweb.
>
> Then, there is the license, which is intimately related to the former.
>
> Boost, QObject, threads, HTTP server? There is no technical problem money
> cannot solve.
>
> --
> Pau Garcia i Quiles
> http://www.elpauer.org
> (Due to my workload, I may need 10 days to answer)
>
> ------------------------------------------------------------------------------
> Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
> much more. Get web development skills now with LearnDevNow -
> 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
> SALE $99.99 this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122812
> _______________________________________________
> witty-interest mailing list
> witty-interest@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/witty-interest
>
>
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
_______________________________________________
witty-interest mailing list
witty-interest@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/witty-interest
