Live data from Hacker News

Ask HN: Time to give up on Qt?

news.ycombinator.com

51–60 of 72 posts

Re: Ask HN: Time to give up on Qt?

#51
You could have both wx and qt - check out https://github.com/enthought/enaml . Enaml is a python based UI toolkit which makes writing cross platform UI's ridiculously easy.

Heres a clone of osx preview written in about 250 lines of code -https://github.com/enthought/enaml/tree/master/examples/prev....

Enaml has qt and wx backends. Layout is constraint based and uses the same Cassowary algorithm used by iOS. As a result ive had the incredible experience of writing UI's and have them perform identically on windows, mac, linux and freebsd. Also since the sizing is handled by Enaml itself, the same ui can be run on both wx and qt and will appear identically sized.

Disclaimer: I work at Enthought and am friends with Chris Colbert who is the primary author of enaml.

Re: Ask HN: Time to give up on Qt?

#52
post #49

Earlier quoted context omitted.

The thing is, C++ is hard 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 (…

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 dia…

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

I would use QGraphicsProxyWidget and this: http://doc.trolltech.com/solutions/4/qtpropertybrowser/index...

Re: Ask HN: Time to give up on Qt?

#53
post #49

Earlier quoted context omitted.

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 dia…

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 I would use…

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].

[1] http://www.mail-archive.com/development@qt-project.org/msg04...

Re: Ask HN: Time to give up on Qt?

#54
post #34

Earlier quoted context omitted.

You realize the Qt basically does exactly that for non-web apps except it's far more comprehensive and tested, right?

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…

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 don't buy it.

Re: Ask HN: Time to give up on Qt?

#55
post #51

You could have both wx and qt - check out https://github.com/enthought/enaml . Enaml is a python based UI toolkit which makes writing cross platform UI's ridiculously easy. Heres a clone of osx preview written in about 250 lines of code - https://github.com/enthought/enaml/tree/master/examples/prev... . Enaml has qt and wx backends. Layout is constraint based and uses the same Cassowary algorithm used by iOS. As a re…

Disclaimer notwithstanding, sounds sweet

Re: Ask HN: Time to give up on Qt?

#56
post #33
post #25

This is something between desktop and web, but you could use Chromium Embedded ( http://code.google.com/p/chromiumembedded/ ). It uses GTK+ on Linux, Cocoa on Mac OS X, and it's own library on Windows (but it looks identical to Windows' UI elements).

@Jarred. Thanks for sharing about the CEF project. I need to build a cross-platform GUI in Python if possible and wanted to use wxWidgets with the python binding. Now CEF seems really great: The possibility to make an HTML5-Javascript App and having also the opportunity to deploy it on a web-server is really exiting. I will have to evaluate it, seems really cool. Can you access files on the file system as a normal na…

Adobe Bracket(https://github.com/adobe/brackets/) are using it and they are editing files from the disk. From looking at the source of their implementation I think that this is how you access system functionality https://github.com/adobe/brackets-app/blob/master/src/win/ce...

Re: Ask HN: Time to give up on Qt?

#57
post #50

Qt is not going anywhere. I recently attended Akademy and the current QtCore maintainer, Thiago Macieira, showed some interesting stats: over 40% of the commits in the past few months (IIRC) came from non Nokia people.

Just curious: what % of the commits are coming from the larger Qt consulting houses (ICS, KDAB, Digia, etc)?

Re: Ask HN: Time to give up on Qt?

#58
post #50

Qt is not going anywhere. I recently attended Akademy and the current QtCore maintainer, Thiago Macieira, showed some interesting stats: over 40% of the commits in the past few months (IIRC) came from non Nokia people.

Just curious: what % of the commits are coming from the larger Qt consulting houses (ICS, KDAB, Digia, etc)?

I found the full stats here: http://www.macieira.org/blog/qt-stats/

Re: Ask HN: Time to give up on Qt?

#59
post #35

> Something else? GTK+ still doesn't look very native on Windows or OS X, so for many cross-platform apps it's not a viable option. GTK+ can look just like Windows XP, Windows 7, Mac OS X. It has themeing capability.

No, it really can't. Every single GTK+ app I've used in Windows has looked terrible and has behaved in very strange ways compared to native UI's. It really makes no attempt to fit in: just as one example, see the dialogs in every GTK+ app. That file picker needs to die. The buttons are in opposite orders.

Qt technically doesn't use the native UI widgets either, but it does a much, much better job at emulating them (and the visual side is completely flawless at least on Windows). In addition, it actually proxies to native functionality where available, which means that you get the real file picker of your platform, dialogs have the correct button order, etc.

GTK+ is only good for GNOME. This is why I wish that Qt would become the de facto standard toolkit for Linux developers: it fits in perfectly in both KDE and GNOME. (Actual KDE apps that use their libraries are a different story, though.)

I've never had anything to complain about the UI of Qt apps on any of the desktop platforms I've used them on. Qt is the best choice for cross-platform UI.

Re: Ask HN: Time to give up on Qt?

#60
post #58

Earlier quoted context omitted.

Just curious: what % of the commits are coming from the larger Qt consulting houses (ICS, KDAB, Digia, etc)?

I found the full stats here: http://www.macieira.org/blog/qt-stats/

Very interesting, thank you. I'm amazed how quickly Intel jumped into the fray here.
Post reply on HN