Wt

Hey,

1. There are no readily available 'tools' for that. Even with the greatest amount of effort it would probably also be very hard to make a web application look and behave exactly like a native application, and I think that there is no point in doing this if the end result is 100%.

What is quite simple to do (and we have customers doing that) is use a small WebKit application which integrates your Wt application and package that as the 'standalone' application. This allows you to remove the normal browser decorations (buttons, toolbars, etc...) but doesn't affect the appearance of the application itself.

2. There isn't. It's been lurking at the back of my mind to add something like this to Wt though (given that all modern browsers support SVG).

3. There are no scale/stability advantages of FastCGI. If you do not wish to expose the Wt application naked on the web (or do not want to allocate an IP address for a single Wt application) you should deploy it behind a reverse proxy. This also works for scaling your application to multiple processes / hosts. Our recommendation is to use wthttpd unless you can't. One reason for example could be that you are integrating a legacy library which uses a lot of global state as it was designed for one-user-per-process --- there is a FastCGI deployment option to spawn a separate process per session to handle this case.

Regards,

koen

Hi Mike:

I've got a professional Qt app that I'm currently implementing in Wt, so I've gone down this path. I am unfortunately maintaining two code bases, but what I've done to minimize code duplication is to slowly break parts of my Qt app out into generic static libraries, then link both apps against those libraries. My model classes, for example, are all using std::string, and I perform string conversion much "later" than I did previously in the Qt app.

The biggest headache I've found in re-using code between these libraries is how to work with WString and QString. I considered templating my generic classes based on string type, but QObject classes don't do that well. In retrospect I consider my reliance on QString to be a major liability, hence the desire to push QString/WString as far out to the presentation as possible.

I've found that although Qt and Wt are extremely similar and great libraries in an of themselves, they are different enough that you'll likely need two code bases if you want both Qt and Wt user interfaces. IMO.

- Bud

Koen/Bud, thanks for your answers!

with regards to Qt / std::string; i have written all my cross platform libraries based on std::xxx. It's really annoying that Qt can't provide a better interface to std::string and others. My code is littered with conversions :/

Regards,

Mike