Comment by sho_hn | Hacker News Reader

Comment by sho_hn | Hacker News Reader

Parent Full thread

No, this information is hardly "100% correct". Here's what's actually going on:

(1) During the 4.x cycle, Qt integrated a new declarative markup language called QML, as part of a new language + batteries module called Qt Quick. In Qt 5, Qt Quick has improved significantly and become a very viable choice for many interesting and useful applications.

(2) Desktop-type applications are not yet among those. While Qt 5.2, to be released toward the end of this year (currently it's in alpha) contains some new Qt Quick batteries to implement desktop-type interfaces that are quite promising, they're also still fairly young and rough, and not suitable for demanding applications.

(3) QWidget continues to be maintained and fully supported. It's mature technology that hasn't seen massive changes in the initial leap to Qt 5, but has nonetheless benefitted from many improvements in the core of Qt.

(4) Further, in Qt 5.2, the KDE community in particular (which is in the process of transitioning to Qt 5 and is a major stakeholder of QWidget, while also making strong and increasing use of Qt Quick) has upstreamed tons and tons of features and code that make QWidget and related APIs even stronger than it already was. Qt 5.2 is an exciting release for users of QWidget and QML alike.

(5) Qt is a proper open source project with well-working governance today. It's also a well-modularized, well-layered codebase. There are no significant roadblocks to caring for and maintaining QWidget for as long as the Qt community sees fit. At the same time, Qt Quick offers some compelling advantages and is likely to evolve as well.

Actually, QML has included Desktop Widgets for QML since Qt 5.1 under the name Qt Quick Controls[1], which means that desktop-type applications are now supported for QML as well.

Having used those a bit, I have to conclude that they are FREAKING AWESOME. Sorry for yelling. If you are used to developing Qt applications using C++ and the Widgets only, please do check that out. It is amazing!

[1]: http://qt-project.org/wiki/New-Features-in-Qt-5.1

Righto, I was off-by-one on that, thanks :). We're currently transitioning to Qt 5.2 which involved upstreaming lots of things we need in there, so it's become a mental habit to think of anything shiny we're using as being new in 5.2.

So far we consider Controls to be very promising, but there's plenty of gaps (no form layouts, incomplete QStyle support, some pathological performance problems, lacking automatic keyboard accelerator management, plain missing standard widgets, etc.) that don't quite make it stand up in comparison if you're serious about desktop use (which we are), so I think it best not to overpromise.

We're making quite an investment into the technology anyhow, though; it'll get there with time (and effort).

QML is awesome, no doubt about it (and I am big fanboi myself). But that doesn't take away the fact that Qt Widget -> QML is basically a complete rewrite of your app.

No - not at all. We're doing this right now and we've structured the change by using QDeclarativeView/QtQuickView within our existing QWidget architecture. Depending on how you want to structure your application, using QML can be as easy as converting a widget/dialog/form at a time and allowing the C++ code to drive the QML, or going for a full re-write with the core of the program in QML with C++ helpers bound to it.

QWidget isn't going anywhere. If "Qt Widget -> QML" is an unpleasant "complete rewrite of your app" then don't do it. Stick with QWidget.

Depends. QML sits on top of technologies and API fashions that Qt debuted before QML came along, such as the QAbstractItemModel API contract and the QObject property sytem, as well as QMetaObject in general. Porting an app to Qt Quick Controls is significant work (and currently will get you lossy results as mentioned above), but there's a lot you can do to prepare while using QWidget, or quite possibly already did because it was compelling and useful to architect apps that way before already - so you can likely plain reuse a lot of your code. And the fact remains, there's no pressing need to port to Controls anyway.

This shows a complete lack of understanding of what's has already happened in the Qt project (notice the past tense).

Qt widgets will not see any improvements. They haven't see any improvement for the last 2 years. Here, answer these questions for me and decide for yourself: 1. What new APIs were added in Qt widgets in last 2 years? 2. What new widgets were added in the last 2 years? 3. Is the Qt team working on improving various look and feel aspects of widgets on the Mac and Windows 8?

Just do a git log and see for yourself - https://qt.gitorious.org/qt/qtbase/source/HEAD:src/widgets.

First of all, Qt 5.2 is seeing plenty of new APIs and improvement for authors of QWidget-based applications. Here's a random smattering of concrete, technological examples:

* KDE upstreamed tons and tons of little widget features from its kdeui library into Qt, e.g. more complete keyboard navigation and title support for QMenu, tab bar hiding for QTabBar, default vs. active shortcuts in QAction, clear buttons in QLineEdit, URL drops in QComboBox, place holder texts in QTextEdit, ... there are several dozen improvements to widgets, I don't know where to stop. KPrintDialog features in QPrintDialog is pretty big. QColorDialog, QInputDialog, ...

* KDE upstreamed lots of things it used to do via KGlobalSettings and KStyle into QStyle and Qt's platform plugin system, which means pure-Qt QWidget apps now integrate a lot better with KDE and potentially other target platforms.

* KDE upstreamed its KStandardDirs APIs by adding and extending QStandardPaths, which allows applications authors to more easily deal in standard locations on various desktop platforms.

* KDE upstreamed lots of work on Qt's MIME type system.

* KDE upstreamed its X11 session management handling.

* Lots of stuff in QDesktopServices, QCommandLineParser, QLocale ...

So ok, that should put the "no improvements" spiel to rest; you're not really aware of what's been going on. But even if this wasn't so - why would QWidget be bad to use just because it's not making huge changes?

Let's be clear: Qt 5 swapped out the entire backend underneath QWidget by porting everything to QPA, and it just keeps working. That didn't take no effort. That's called commitment.

Edit: Good and pertinent comment by someone else: https://news.ycombinator.com/item?id=6566635

You can't add API into Qt 4, there are new additions only in Qt 5 and as someone already explained, a lot of stuff from KDE widgets is being upstreamed to Qt 5. New widgets and API are being added. There are no or just little changes simply for one reason: why change something that works? To change stuff just for the sake of change is not a justification and it would only make it more difficult for devs to port their apps from Qt 4 to Qt 5.

We are building a small desktop app (to complement a hardware device) using Pyside (or PyQt). Would you say that is a risk ?

Do you recommend a different way to go about it with sufficient productivity as Python ?

I don't see any significant risk there. QWidget has many large commercial as well as FOSS deployments that will see it stick around for many years to come, and Riverbank's PyQt Python bindings are likewise used by many large commercial and FOSS offerings, and very actively maintained, tracking upstream Qt quite closely. I've written some PyQt apps as well (alongside lots of C++ and Qt Quick) and I think it's a very nice way to use the toolkit (in fact I'm relieved C++11 added some of the things that made using PyQt so nice).

I've been a KDE developer for the last 8 years, and in that time I've seen Qt steadily improve as an open source project. When I started out using Qt, getting code into it was essentially impossible without becoming a Trolltech employee. Today it's quite open to its various stakeholders, who manage to collaborate constructively. My confidence in Qt's resilience has increased with our level of agency in making that resilience happen.

Just saw the PyOtherSide project as well for Qml, Qt5 and python - fairly interesting.

https://github.com/thp/pyotherside

Aye, PyQt has recently also introduced some pretty interesting new Python integration bits with the new pyqt5qmlplugin that allow you to write QML extensions in pure Python without C++ boilerplate.

Completely misleading. Have you ported a Qt Widgets project to QML? Show me the code if you have done so and I would agree that I am wrong. They are completely different code bases.

You seem to be misunderstanding my argument, which is that there's no risk to writing a QWidget app because there's no need to stop using QWidget, as QWidget isn't going away. You've yet to produce any arguments for why this isn't correct.

I don't have a reply button anymore to sho_hn's comment. Take this as a reply to the adjacent comment :)

What I am saying is: if you have a new _native_ widget in a new OS release (layout spacing, new views, new controls, new features - there are so many), it won't be implemented in the Widget code base. The Qt project will tell you to use QML. How are you going to make your C++ Widget based app look modern now when all your code is QML based?

Answer: there is no answer. The Qt project has made it extremely difficult to decide for their existing users. For new users, it's a trivial task to choose QML but how many new desktop apps are being developed from scratch these days.

Several of the things you list are the duty of the platform plugin and the style engine plugin and don't actually require any changes to the core widgets. Yay layering.

Personally I think entirely new widget classes should be accepted into the QWidgets module, but you may be right that there's some resistance to that - but the bar for new widgets has always been fairly high actually, it was a rare occurence even before QML (neither Qt 3 or Qt 4 saw much in the way of new widgets during their respective lifetime). I think the case that a lot of the "new UI challenges" are better met by QML is also somewhat legitimate, in which case there's an incentive for porting to it.

Reply on news.ycombinator.com