Hey Pau,
2009/10/19 Pau Garcia i Quiles <[email protected]>:
> Well, I'm using WRun since a connector needs a WRun(). This way you
> only need to link to libwtdesktop.so, not to libwtdesktop.so and
> libwthttp.so.
True, but every connector also needs a WServer implementation that
behaves in the same way as WRun, and WRun() can be implemented based
on the WServer implementation.
> My approach is simpler than what the wtwithqt example/library does: I
> just start a QApplication and a QThread in WRun and launch the WServer
> in the QThread. Would it be possible to launch the QApplication from
> WServer::start without trouble with Qt's threads, etc? I don't know, I
> didn't try that.
Yes, that should work without unexpected trouble. The wtwithqt example
is complicated because Qt cannot stand that objects are being used in
a different thread than the thread that created them. But wt on the
other hand uses whatever thread that is available to server a
particular session. So the wtwithqt library provides a way to bind a
specific Qt thread to a session, and uses that thread to handle
requests.
>> Great work !
>
> Pretty trivial, actually. No merit in it :-)
>
> I'm attaching a new version of the patch which adds a toolbar with
> navigation buttons and a print button (which does not work yet). It no
> longer needs you to specify parameters in the command line, so you can
> just double-click the executable, like a desktop application.
I still haven't found time to try it, and I better do not get caught
up in the fun stuff as long as I have a backlog of other work that I
need to look at :-)
> I have one request: a Wt::connector() method which returns an
> enumerate which tells you what connector the application is linking
> to. Something like this:
>
> namespace Wt {
> enum ConnectorType {
> HttpConnector = 1 << 1;
> FcgiConnector = 1 << 2;
> DesktopConnector = 1 << 3;
> }
> }
>
> Then in each connector there'd be this:
>
> namespace Wt {
> Wt::ConnectorType connector() {
> return WtDesktop; // or whatever it is for that connector
> }
> }
>
> Why this? Because I'd like the wtdesktop to have a "File", "Edit", etc
> menus, like a real desktop application. For that, we'd need:
That sounds like a good idea. In fact, there is already an
enum Configuration::ServerType {
WtHttpdServer,
FcgiServer
}
So it would be a matter of making that indeed available through a
Wt::serverType() method ?
> - Signals and slots in the WtDesktop connector: file->open (probably
> when developing an application you'll connect this to WFileUpload),
> file->save, file->print, etc. It would be even better if we could
> define some kind of declarative language (something like QML) so that
> you can easily say "file->open (which is a QAction in a QMenu) should
> be connected to my Wt slot XXXX()". Doing that currently requires some
> work because we are connecting a Qt signal with a Wt slot (and vice
> versa).
I think we should try to get rid of the threads in the wtdesktop
connector, since this causes problems when connecting from a session
to the browser and back. In principle, this could be easily done (you
can already build wt without threads), except for the recursive event
loops (WDialog::exec() and co). These could be solved without threads
by using blocking I/O instead of asio. But that is not an easy change.
It does sound like you would also want to add custom entries in the
browser menu from within the application? So, in principle you would
like to have a more explicit manipulation of the Qt menu (which you
could then wrap in some wtdesktop-only Wt API).
> Also, I'd like to see a WBundleResource like Qt's .qrc resources. By
> doing this, we could distribute a single executable, statically
> linked, which encapsulates the application, Wt runtime, Qt runtime and
> all the images, Javascript, sqlite databases and whatnot. I took a
> look at Qt's resource compiler rcc and implementing it in terms of
> Boost should not be too difficult.
I'm not proficient with rcc, but, you can provide custom
implementations of WLocalizedStrings that resolve strings WString's
using another mechanism ?
> I'm not expecting any of this for Wt 3.0 but IMHO all this would make
> Wt rock :-)
I totally agree!
Add to it my own wishlist for qtdesktop, next to indeed the uber cool
session sharing: definition of end-to-end test-cases for web
applications with the browser and JavaScript in the loop!
Regards,
koen
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
witty-interest mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/witty-interest
