Live data from Hacker News

Technical Vision for Qt 6

blog.qt.io

151–160 of 184 posts

Re: Technical Vision for Qt 6

#151
post #100

Can someone please show me how to style a qt app relatively easily? I've built qt applications, and making some effort to make it look passable takes twice as much time as actual programming. QSS just sucks in making luxurious feeling interfaces, and this is where electron succeeds. Its much easier to make your own 'widgets' and have a great feeling application at the expense of ram and performance on electron. If Qt…

This is geared towards qtquick (not widgets) applications, but to create a general theme you can use this pattern:

https://doc.qt.io/archives/qt-5.11/qtquickcontrols2-flatstyl...

Then before the engine is loaded in main.cpp call

qmlRegisterSingleton( QUrl(QStringLiteral("qrc:/Theme.qml")), "mycustomname.theme", 1, 0, "Theme");

Then in a qml file:

import mycustomname.theme 1.0

This allows you to do something like:

Rectangle { width: 100 height: 100 color: Theme.mainColor }

You can also do things like set the application font which would be done in main.cpp before the engine is loaded:

QFont appFont("NameOfLoadedFont); appFont.setPixelSize(16); QGuiApplication::setFont(appFont);

You would need to load the font, which you can do in the Theme.qml file:

property FontLoader someFont: FontLoader { source: "qrc:/locationOfFont/Font" name: "NameOfLoadedFont" }

Re: Technical Vision for Qt 6

#152

What Qt needs is more Electron. Please show me one major new desktop application written today which uses Qt. Major meaning used by millions of people.

Telegram for desktop. Easily the most usable "modern" (read: not IRC) instant messaging client available today in terms of features, responsiveness, and portability.

Re: Technical Vision for Qt 6

#153
Their tricky licensing makes using Qt for personal projects a non-starter and anything commercial really hard to justify.

If they streamlined the licensing and created (C)sensible language bindings then it would be great. I tried the python bindings and they were problematic. Can't even imagine using one of the unsupported bindings.

Re: Technical Vision for Qt 6

#154
post #36

Earlier quoted context omitted.

I think the suggestion here involves comparing the developer experience for the two. (QT would clearly win on all of the user experience and runtime performance metrics.) If not for developer experience, why is electron ever used for anything?

If Qt would win on user experience, why isn't it doing so now? This list[1] is out-dated (spotify uses electron, for example). But after skimming it I don't recognize any big software applications that have an exceptional user experience. Some, like Google Earth and Calibre are abysmal at best. [1]: https://en.wikipedia.org/wiki/Category:Software_that_uses_Qt

Really? I see quite a few pieces of well known and often recommended software on that list. Dolphin, KeePassXC, Krita, OBS, Telegram, VirtualBox, and wireshark for the more common ones. There's some less well known gems in the list as well, eg pcmanfm is one of the first things I install on any new system.

Re: Technical Vision for Qt 6

#155
post #127
post #43

Earlier quoted context omitted.

Easy just watch React Native for Windows talk at Microsoft BUILD 2019. Electron has 700% performance lost over UWP/C++, which is the baseline. Expect similar results when comparing against Qt.

So, RN can be used as an Electron replacement?

Lots of frameworks can be used as Electron replacement, including RN.

Re: Technical Vision for Qt 6

#156
post #26
post #11

Earlier quoted context omitted.

C++ (and even Rust) is not the best language to build UIs. Even if your app heavily uses C/C++ to do heavy computations, "scripting" language will be preferable for "glue code". QML is not a crazy new idea, for example Tk used Tcl. And due to C++ API, Qt has poor language bindings, compared to GTK and many others with C API.

I believe you're incorrect, C++ is a good language for building UIs, as proven by the plethora of UI libraries and frameworks built in C++ for pretty much all platforms. This is visible when comparing PyQt and C++: yes, PyQt is easier to get into, has nicer syntax, but C++ offers more power. Even hot-loading UIs, a typical scripting language advantage is supported. Declarative UI languages do have some advantages com…

> I believe you're incorrect, C++ is a good language for building UIs

I agree, not necessarily with c++ but it's much better to build UI's with code than declarative xml crap.

It will be a shame if Qt sticks to a pure c++ interface though, I'd hope the build something more usable from more languages so it's an option for C, Zig, Rust, etc.

Re: Technical Vision for Qt 6

#157
post #126
post #121

These changes are very welcome, but in my opinion are too little too late. Qt has missed the boat with the current developer mindset. While I want Qt to 'win', as the end result is superior to say an electron app, most developers are willing to sacrifice usability and add bloat by using electron. Or simply paint them selves into a corner with a native SDK. Qt has a massive uphill battle to try and stay relevant. Like…

I respect your comment, but I think it's a narrow look at what Qt is and what it's used for. You mentioned "native UI SDKs" having become preferrable, but keep in mind that in many scenarios, Qt is the native UI. On desktop Linux there isn't a lower level toolkit Qt is translating to, but also in the many embedded products Qt is used on: Car and aviation infotainment (a prominent example is Mercedes-Benz' MBUX OS, bu…

> My bottom line here is: Right now, and very likely ten years from now, if you are good at at Qt you're probably going to work in a very good and stable job at a solid business. I don't see this being the case for Electron developers, and I know where I'd rather be.

What?! If you're specialising in Qt then your skills are tied to Qt and you are tied to the health of the Qt job market. Those skills are not very transferable. On the other hand, 90% of the skills needed for Electron development are web technologies which are relevant to the massive web related job market. I know where I'd rather be.

Re: Technical Vision for Qt 6

#158

Earlier quoted context omitted.

You’re not helping your case! Spawning a server (a JVM-based one at that!) to be able to get reasonably performant builds is horrifying! As a simple example, I hack on a Qt app on a Raspberry Pi (it has a tiny display on it and I run a dashboard). It’s only got 512MB of RAM and spinning up a JVM server to run my builds will likely cause it to run out of RAM. I’m not the world’s biggest fan of CMake, but it sure solve…

Bazel’s approach is to cross compile from a stronger platform

So it not only requires a daemon, it also depends on additional hardware.

Re: Technical Vision for Qt 6

#159

I'm converting a 500KLOC C++ consumer app from Win32 to Qt so it can also run on macOS. All the app-specific code remains the same. I'm very pleased with how easy it is to design dialogs. Qt is better than anything Microsoft has to offer; what would entice me to forego portability?

Have a try at WPF/WinUI, Blend tooling and the myriad of companies selling ready made components.

Otherwise, yes Qt is the best option for cross platform C++ code.

Re: Technical Vision for Qt 6

#160

Why a scene graph? I had the same question about GTK 4 and have yet to see any sensible answer.

Declarative layouting is in fashion, which works well with scene graphs. GUI frameworks have usually been tied to inheritance-based object oriented systems.

It is fashion because on modern GPUs is easier to optimise what actually needs to be done, and combine passes as well.

During the early days of GUI development, immediate mode won because scene graphs are more demanding in regards to memory consumption, and graphic chips were quite limited anyway.

Post reply on HN