Qt Widgets or QtQuickControls?

I previously blogged about the progress Martin Klapetek and I since that I started another round of changes making sure the new Breeze theme works nicely with QtQuickControls.

It poses an interesting question; which should you use when making a new project?

With all the hype and excitement about QtQuick it’s hard to get a straight answer. The reality is there is no one single answer that fits everything.

In defence of using QWidgets

It’s alive and well

Reports of its death have been greatly exaggerated.

There are (at time of writing) over 1000 commits in the qtbase/widgets directory just since Qt5.0. It quite clearly is still supported and still maintained.

There are not a lot of new features being added, because there is not a lot else to add. From a developer POV this is a good thing as less things are going to break.

We have a huge library of assets

Our Frameworks have several widget based libraries; providing pre-built complex widgets from highlighted text editors, to kparts to buttons with integrated KAuth knowledge.

Discarding these and re-inventing these is not only wasteful and time consuming, but also going to result in many inconsistencies.

It’s easy to subclass and extend

The styling approaches are very different. In QWidget’s QStyle, styles supplied generic margin sizes and would draw generic frames and buttons.

In QtQuickControls styles are very very tied to the control; the style themes a button, or a combo box or checkbox explicitly.

Yesterday I tried to re-create the KColourButton in our KQuickAddons repository; the plan being to subclass the QtQuickControls Button and add a rectangle in the middle… something that should be ridiculously simple turned into an impossible mission; there’s just not information in the public API for the developer to get the margins from the theme. In order to fix this, I need to go and add extra API into Qt.

In support of QtQuickControls

There are some misnomers about QtQuickControls, mostly obvious:

QtQuickControls is for desktop, non-touch systems

QtQuickControls is destined to be the future replacements of widgets for
_all_ platforms. In 5.4 there is a theme for Android that fits in with the device including opening pickers for comboboxes.

Their is one style/backend for QtQuickControls that uses QStyle to replicate the desktop style. It is a stop-gap measure and not the main objective.

It’s rapidly getting better and better

If I was writing this article 6 months ago I would have written about how broken layouts were, I would have a whole paragraph about the difficulties in making the tab key work, I would have pages about blending in with existing widgets or the lack of dialogs. It is a very fast paced world, and each time I revisit the subject the list of places where QWidgets trumps QtQuick keeps falling.

Upstream are open to feedback

I have multiple changes in QtQuickControls already with a ever growing TODO list. If we put in the work we can shape the future of the widget replacements.

Mobile portability

With the android QtQuickControls landing soon, including native dialogs it’s very relevant for cross device applications.

Conclusions

I have absolutely no doubt that QtQuickControls is the future way of making applications. However it’s important to stress the word “future”.

Realistically, even though it’s possibly to get quick results in QML, it currently requires a lot more work to add in all the additional functionality that brings it on par with a QWidget application.

What I would like to see within the KDE community:

  • Thinking about your requirements and goals of a project before choosing which technology to use
  • Working upstream with Qt and frameworks to build a larger collection of re-usable components not just working within our applications
  • No regressions. The user shouldn’t care what tools a developer chose to use, they shouldn’t have to suffer for our technology shifts