It's time to give up _cross-platform_. Doesn't work well with the increasingly different UX concepts of different platforms anyway. The only viable cross-platform is the web.
The difference is that each environment for non-Web apps - Mac, Windows, KDE etc - has each own somewhat well defined look and feel, that applications should follow in order to feel native. That's not true for Web apps in different Web browsers - they are supposed to look the same. Qt compromises that native experience by letting you target multiple platforms. For Web toolkits, at worst you'll end up with an app that doesn't stand out (e.g. by using Bootstrap) but certainly not with one that won't blend in.
I don't know if you've used Qt or not, but one of the things that always impressed me about it was how good it was at defining the abstraction just right at the level so that out of box each platform's app did in fact look right on that platform and fit in with the same look and feel. Obviously that doesn't catch everything, but the areas where Qt apps didn't fit perfectly into the platform's native look and feel by default, it was always easy to insert some platform specific code to go in and call a few functions that brought it up to the level you wanted to see it get to. You know I'm not going to say it's exactly 100% as it would be writing a whole separate app for each platform, but it gets shockingly close with shockingly little extra effort, and as someone who helped write an app using Qt and OpenGL to run on Linux, Windows and OS X on a short timeframe, Qt was amazing.
We're not talking about write once look the same everywhere here like old Java/Swing or a webapp. That's just not what Qt does unless you twist its arm. By default it compiles a version that's intended to fit in on that platform target you compile towards.
And seriously. A webapp compromises the native experience much more than a Qt app would. Pretending you can avoid that by stuffing your stuff in a web browser where there are no cohesive look and feel standards that make any sense and that this is somehow supposed to yield a better user experience?
I've used Qt a lot. In fact, I'm still a big fan and wasn't trying to sound negative about it in any way. I absolutely agree that Qt does a tremendous job at abstracting away the differences but still, it's the little details that matter and no toolkit could address them all. Things like ribbons on Windows. Multi touch support, cover flow and proper OS X-like multiple window management on Mac. Not to mention mobile. For big applications, these glitches add up and in no time you find yourself resorting to way too many native workarounds.
But my main point was to that cross-browser Web toolkits and cross-platform GUI toolkits are apples and oranges. On the Web there are no UI guidelines. It's essentially free for all. The chrome of the Web browser constitutes a clear separation point between the native experience and the Web experience, which makes it possible for things like Gmail not to feel hostile on Mac, Linux, Windows and any other Web-enabled environment. Whether or not that's good for UX is irrelevant, the fact remains is that Web apps have never tried to integrate seamlessly with the look and feel of the host environment and the users have grown accustomed to that.
If the problems with that "crap" were insurmountable we wouldn't have the huge variety of websites like we do today. And I would argue that just as big cross platform issues exist with Qt/Swing.
With Modernizr, JQuery etc you can get 95+% of the features on 95+% of computers.
I''m sure Autodesk, Virtualbox, Google Earth, Mathematica, VLC, Transmission, Scribus, Skype, etc, etc would be very interested to hear how unviable they are.
Native apps, be they desktop or mobile, still very much have their place. The iPhone is irrefutable proof of this. Right in the middle of the golden age of the web, Apple has built a ground breaking native app platform that has taken the world by storm. So much so that even web apps like Google+ and Facebook find themselves in an arms race to provide the best native clients.
Please provide some proof when making such extraordinary remarks. Given their requirements, these companies would have to be insane to try to build their apps with web technologies. Are you really suggesting that they do CAD and VOIP using JavaScript?!
Developing interfaces in html/js even factoring the added IE crap is a breeze compared to C++ development. Even with Qt sanding a lot of rough patches
Not that C++ per se is too complicated, rather, building an interface in C++ and doing "a desktop application" with it is a complex task, something that the web model was made to do
Now, for something like a headless application, C++ is fine (and of course it's harder than Python, but not a lot with STL, etc)
Hence QML. Right now I'm developing a desktop application with the interface done with QML and the main app in C++, and I would say the interface development is easy, as is connecting it to the C++.
The caveat at present is that the standard desktop widgets are not yet fully available from QML (see [1] for a recent update). For most of my application this doesn't matter (I haven't decided how I'll do the settings dialog yet), but for enterprise apps it quite likely does.
The caveat at present is that the standard desktop widgets are not yet fully available from QML
I hear Qt5 will have have all (or a lot of) the standard widgets available in QML. Until then, using QGraphicsProxyWidget is a quick and easy way to embed QWidgets inside QML. Here's an example: http://qt-project.org/doc/qt-4.8/declarative-cppextensions-q...
I haven't decided how I'll do the settings dialog yet
Thanks for the links - didn't know about the property browser thing.
It's not quite as simple as waiting for Qt5. From my earlier link:
The components are hosted as a Qt Playground project and won’t be a part of the 5.0 release. They will instead have separate releases, most likely in sync with the Qt 5 releases. At some point we will look at making them a proper part of Qt 5.
These separate component releases will be important, as the proxy widget mechanism won't be available for Qt5's QSceneGraph-backed QML. Nor does there seem to be a replacement coming yet, mostly for performance reasons [1].
Yeah, I agree with this. I still like seeing the discussion here, since I'll concede that there may be some special circumstances and constraints that lead a developer or team to go with one of these cross-platform UI toolkits, but I think on the whole people are better off picking a platform and creating a truly native experience, including exploiting the unique strengths of the platform. Same goes for the cross-platform frameworks available for iOS, Android, etc.
