Hacker News Reader

Comment by majewsky | Hacker News Reader

Not sure what you're talking about. Qt 5 didn't remove anything that was there in Qt 4 [1], and added quite a few nice things like native Wayland support and more OpenGL integration.

Sure, the main development focus is on QML etc., but that's mostly because desktop is a more mature platform than mobile.

[1] Except for the QtWebkit to QtWebengine transition perhaps. I haven't followed that very closely.

View on HN

The main development focus is the very thing I was curious about. I remember Qt being slow to support new things eg. high dpi, unless you were using QML.

Getting the "feel" of a company's priorities can be hard, if you're not actively using their platform. I was hoping someone on HN had a somewhat realistic picture of where Qt is going these days.

It looks to me like they're very underfunded and have completely lost focus. The high DPI "debacle" is a good proof of it.

Sure /s. We have a Qt app with GUI completely written in Qt. Scales pixel perfect on HiDPI out of the box as long as you make sure to not hardcode pixel values.

Things have definitely accelerated since Nokia regarding desktop platforms. High DPI support has gone through a few iterations and is working pretty well now. Also, Qt is now using open governance model. Qt Quick is still important, but I wouldn't say it's the single, most important thing it used to be anymore.

Now the focus of QML is mostly embedded where it really shines. Desktop and mobile is still possible with qml.

All new APIs are done with focus of improving the QML experience.

For embedded and mobile deployments, QML is the only option.

If you try to use a common C++ widget dialog, you will get a tiny desktop like window, regardless of the platform.

Ever heard of

    QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling);

(to be set before creating the QApplication instance).

How does it help, when displaying a tiny file selection dialog on an Android device?

https://bugreports.qt.io/browse/QTBUG-42491

These file dialogs are not for mobile! But it's easy to make your own ones, please see: https://gitlab.com/eql/EQL5-Android/blob/master/screenshots/...

The above is on an android tablet; but it displays perfectly fine on phones, too. Just see the sources of the above project for implementing such a dialog:

https://gitlab.com/eql/EQL5-Android/blob/master/examples/my/...

Which proves you failed to understand my point, C++ Widgets don't work everywhere, only QML.

That depends on your screen size! But of course I would never use QWidgets on mobile, with the only exception of direct painting (using a QPainter on a plain QWidget).

QML is easier anyway, and gets better with every version...

Not all Qt developers are happy to be forced to use QML, which again, was my point to start with.

C++ Widgets should be able to offer a mobile friendly version of themselves.

Which was actually a point that was discussed for the Qt roadmap at Qt World Summit 2017.

OK, I understand your point. Good luck, then!

Thanks, but actually I don't use Qt anymore, that bug and a few other ones in 5.4 lead me to use Java and C++/CX for the UI, with common business logic in C++, in a MVVM approach.

The approach of re-doing in QML standard UI components is not appealing.

> native Wayland support

It's still pretty unusable though :/ The default for Qt apps is via Xwayland in Fedora for example.

I'm using some KDE apps under Wayland (Sway, to be precise), and they're definitely not running under Xwayland (as confirmed by `xlsclients`). There is a lot of scaling confusion, but it's far from "unusable". Just not pretty.

Must have been some bug with my configuration then: There were scaling issues resulting in some buttons being unclickable.

Qt5 dropped the QWindowing Server for embedded platforms.

Reply on news.ycombinator.com