Integrating the web into desktop apps is now incredibly easy thanks to Qt WebKit.  Qt WebKit also allows us to embed any Qt widget inside the html. This feature makes it extremely tempting to develop full blown desktop applications using Qt WebKit – your interface is entirely designed using html/css (instead of .ui) and you as a C++ developer decide what parts are best done in Qt/C++ and embed them into the html page.

The above scheme works very well (for the most part). However, there are a lot of features that make our applications feel native, that we take for granted in desktop apps when using Qt/C++ but not so when using Qt WebKit. So here is a list of short comings that you should know about.

1. Focus handling – Tab focus  doesn’t work at all when navigating from html into a c++ plugin and vice versa.

2. Keyboard accelerators – In html, you can specify accelerator using ‘accesskey’. They don’t seem to work in QtWebKit. They do work in google chrome, so must be something to do with the Qt port.

3. Text can be selected and images can be dragged – Your main ui is html, what did you expect ?

4. Plugins will get deleted if you hide them – If you hide your C++ plugin/widget using ‘display: none’, Qt/WebKit will delete it. In your traditional Qt program, all your data is part of the widget – now it’s all gone. To prevent this, you have to write all your widgets to use the model-view paradigm. An alternative is to use ‘visibility: hidden’ which won’t delete the plugin but the plugin will continue to hog space in the layout. Side note: In Qt 4.4.x, plugins weren’t deleted (aka leak). Starting Qt 4.5.x, they were deleted – we found this problem when our app starting crashing gloriously when we moved to Qt 4.5.x.

5. Fluid layouts – When the windows resizes, UI elements inside are expected to reposition and resize nicely; the window must have a nice minimum size – that is all done by QLayout does. This is really hard to get right when using html. You will most likely end up writing js layouting code.

6. Moving data back and forth is slow – Passing Qt types from C++ to JS works very well using QJson. Converting complex types like a QPixmap to html img is really really slow, since you have to convert in into png first. Also, using this method crashes Asus laptops/Windows, probably some graphics card issue, nevertheless your app has to deal with it.

8. RTL – Qt will layout your widgets automatically when your app is run in a RTL environment. With HTML, you will have to provide an alternate html file, do your own RTL detection, implement sizing fixes to elements for different languages and so on.

9. Translations – Qt provides you linguist, lrelease, lupdate. When using HTML, you will have to roll out your own translation framework (this is an awful lot of work).

10. Misc – There are other minor problems depending on your Qt version – the default fonts of html and qt didn’t match. There was a time when a 12pt font of Qt and 12 pt font of webkit don’t match (this seems to be fixed now). Displaying plugins inside divs had some artifacts.

Note that the above is not a case against using Qt/WebKit for developing desktop apps since they can all be worked around. It’s more for you to know what you will be up against if you decide to go down this road.

Update 1: Added note on rtl and translations