You know, I just had a crazy thought. It might be easier if Witty was
implemented in Qt. Then many more things could be shared. I'd take a stab at it
if knew how to do half the things. Like the JS events and C++ -> JS
translation. (I'm weaker on the web stuff) But that would be a fork of epic
proportions. But we'd eliminate boost, stdlib, etc. And wind up in the end with
a much better situation. The GUI and WebUI could use the same internal
application server.
mind: blown
________________________________
From: Koen Deforche <k...@emweb.be>
To: Jason H <scorp...@yahoo.com>; witty-interest@lists.sourceforge.net
Sent: Wednesday, December 14, 2011 3:14 AM
Subject: Re: [Wt-interest] Wish: More Qt compatibilty?
Hey Jason,
2011/12/13 Jason H <scorp...@yahoo.com>:
> I think I've stated before that I'd like to use Wt as a companion to Qt.
> I've been able to accomplish this, but it isn't pretty. I was wondering for
> 3.3 if the goal could be more Qt compatibility?
Actually, compatibility with Qt has never been a goal for Wt.
[ Actually, the very first version of Wt was called 'qtweb' did
actually implement the Qt API so that some of the Qt tutorial examples
worked out of the box -- including a moc clone. This plan was however
discarded as too ambitious since it required solving two problems at
the same time: implementing a widget library for the web, and making
it Qt compatible ]
Instead, we look at the Qt API to avoid making bad API decisions, as
in our opinion Qt is (or certain was) the best API in town.
The main problem with stating that Qt compatibility is a goal, is that
it cannot be achieved (unless we go back to moc, ignore sessions, the
fact that most things are not painted), and it would also ignore
aspects that are web-specific.
In the end, the Qt API is optimized for frame buffers, while Wt needs
to be optimized for HTML.
What I suggest instead, is to create a Qt compatibility layer on top
of Wt. This allows you to avoid the #ifdef mess in the application
code, gives you freedom on mapping Qt widgets and features on Wt, and
also allows you to use Qt UIC as-is.
> The modifications to the Qt UIC work well enough. But after that there is
> much pain. A lot of it seems trivial ("Why didn't they stick with the Qt
> API?" i.e WString::empty() vs QString::isEmpty()) but I have to admit that
Because for some things, we actually preferred to stay compatible with
the 'std' API.
So, what do you think about the library-layer approach ?
It believe it may be a bit more (boring) work to get it started, but
once it rolls it will be more flexible and have less hack-ish issues.
It's also easier to manage than patches on top of UIC and, because of
the appeal to many existing Qt users, it may easily get enough
contributors to thrive.
Regards,
koen------------------------------------------------------------------------------
Cloud Computing - Latest Buzzword or a Glimpse of the Future?
This paper surveys cloud computing today: What are the benefits?
Why are businesses embracing it? What are its payoffs and pitfalls?
http://www.accelacomm.com/jaw/sdnl/114/51425149/
_______________________________________________
witty-interest mailing list
witty-interest@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/witty-interest
