Technical Vision for Qt 6 | Hacker News Reader

Technical Vision for Qt 6

blog.qt.io

247 pointspjmlp181 comments

"Make JavaScript an optional feature of QML." and "Support compiling QML to efficient C++ and native code."

Yes! These two things are what's been on the very top of my wishlist ever since QML/QtQuick was first released.

I would love this!

In fact the QML format would not even be a terrible way to write non-UI applications, I'd think. Something like

    MySqlDataBase {
      id: default_db
      host: ...
    }

    UserController {
      items_per_page: 20

      formatter: UserFormatter {}

      repository: Repository {
        table: "users"
        database: default_db
      }
    }

is definitely more easier to follow than the linear version

    auto default_db = std::make_shared<MySqlDataBase>("...");
    auto userformatter = std::make_shared<UserFormatter>();
    auto repository = std::make_shared<Repository>("users", default_db);
    auto controller = std::make_shared<UserController>(20, userformatter, repository);

especially when you do some kind of constructor injection with nested objects. The declarative tree structure of QML is great.

Yes! You can already do it, but you pay a lot of overhead in unneeded QObject/QQuickItem features that you don't need, so if they can improve that, and it sounds like they're working on it, then I think that would be fantastic.

It doesn't look as bad if you skip the intermediate variable declarations, since you're not re-using those variables elsewhere.

(the QML structure only works as long as this is the case, e.g clear nesting of instances)

> clear nesting of instances

You can have references (default_db in the example) to instances to have indirectly nested instances too.

Been there, done that, SQL queries in JSP. Trust me, you don’t want your business and data access layers mixed with your presentation

That's not what they're suggesting though. The suggestion is to be able to implement business / data access layers in the same style/language that people are implementing their presentation. That the two would be intermixed could certainly be an intended consequence / anti pattern, but I don't think it's inevitable.

Thanks for supporting CMake and deprecating qmake. Not that cmake is the best tool ever, but having to deal with several build systems in the same project has always been a nightmare.

Oh yes, finally! That's such a good news! Learning, using, maintaining a qmake + cmake build setup for various platforms is really a pain in my (limited) experience.

It should also be noted that the folks working on Qt Creator have pending issues to add support for other build systems.

Would have hoped they would use bazel instead. It's open-source, and so much easier to deal with than CMake.

Are you kidding me, bazel is written in Java...

so what? Bazel spawns a server, the next invocation is really fast.

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 solves a lot of problems while being quite lightweight. And I’ll take it over qmake, mostly because I know CMake well enough and haven’t ever really gotten into the guts of qmake. CMake is more general purpose.

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

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

It doesn’t depend on additional hardware, but it’s designed to make it very easy to cross compile. The internal Google tool it’s built on also has strong support for sharing build servers between devs, and they want to enable that in the open source version.

It also doesn’t require a daemon: you can ask it not to do that, so the biggest cost is a JVM warmup.

That said, these are really moot concerns: for almost any project where engineering is involved, the cost of having an engineer in the first place significantly outweighs the costs of having as many hefty CPUs as you really need for build. If you can’t get a decent i7 for a build node, there’s probably a lot more things limiting you, too.

I don't get why are you saying it's horrifying. It keeps cached copy of the build graph, among other things, so subsequent invocations of the build systems, there is less to read cold again. It's pretty good design. Also the server dies after some time (controlled by some default). MOC/UIC/RCC would've integrated much easier there, than what's right now.

How much memory does that take, vs something like CMake that starts cold? I can see why you'd want to do that if you have an absolutely massive dependency graph for your build, but outside of a few select companies, that's probably not the case.

Honestly I haven't measured, ballpark figure would be hundreth megabytes to gigabyte. Given that it's standard on dev/build machines to have more than 8GB I don't see it as a problem. Memory is cheaper these days than developer's time.

If you're doing development, having a RPi and 0.5 GB of ram is just weird. In principle I do agree that modern stuff is horribly bloated and I can bitch all day on the subject, OTOH it's where we are now.

Invest in a machine of suitable spec, and BTW that usually means RAM more that CPU (IME anyway). Don't hamstring yourself.

I do have a quite beefy machine, and yet, I'd still rather not have a bunch of RAM-hungry "build servers" running when there's much lighter tools available. They compete with all of the RAM-hungry Electron apps /s

The Pi is like that because I can ssh into it, make a tweak, rebuild, and carry on with life.

I instantly understand what you're saying. I wouldn't want that in my build process either.

Me too. I love bazel, for the plain syntax, sandwiches (deps between languages), determinism, just plain good stuff. I use it for all my new personal projects (linux/windows).

No one loves CMake and it’s custom scripting language.

It’s selling point is that it works, and it does. Its a pragmatic choice.

I think this is one of those “join the crowd” things at this point.

Picking CMake for QT is a great decision.

...for personal projects, by all means take your pick, but bazel wasn’t ever really a contender in this space for them.

They've been working on the transition from QMake to CMake since 2012 (or earlier). It was a topic at the Qt Developer Days when they released Qt5, long before Bazel was an option.

I hope that in future the module system that will be introduced by C++20 will eventually kill CMake. Having said that I don't know the scope of the functionality brought by it, but if not with C++20 the next one will probably be good enough.

I wonder what's the Qt 6 road-map as C++20 is around the corner and is supposed to bring an amount of change similar to Qt 6, I presume. But basing on C++17 is already as new as it gets with their client base in embedded sector for example. Though it may be a bit too new. They can't lay dormant so it's a good deed after all, although timing seems unfortunate.

> I hope that in future the module system that will be introduced by C++20 will eventually kill CMake.

To the contrary - with modules more powerful build systems are needed that the ones which exist today. See this post for a CMake dev : https://www.reddit.com/r/cpp/comments/axnwiz/cmake_gcc_modul...

I hope they fix QtDesigner to not be hot garbage. Elementary operations such as trying to move some controls to a container that has zero size is totally unintuitive (you need to alt+drag to the container in the widget tree view - note that nothing else needs that) and not always possible (the widget tree view doesn't scroll so if the container is out of view you can't move stuff there - the fact that selecting something in the form automatically selects it in the widget tree view and scrolls it doesn't help at all there), or simply pasting widgets in a container without breaking the existing layout (literally, the program tells you to "break" the layout... meaning to remove the existing layout). Or something like making a widget invisible (the visible property is not exposed in the property editor and if you force it to be enabled and mark the widget as invisible then the widget doesn't show up in the editor :-P).

And some widgets are simply missing or accessible through obscure ways (e.g. instead of QSplitter being in the Containers group in the widget box, it is only accessible by ctrl+clicking two controls under a parent container that has no layout and right clicking and selecting selecting Layout horizontally/vertically (two menus) - WTF, what is wrong with simply letting me drop QSplitter in the form and then place controls manually? I can already do that perfectly fine after i perform the magic incantation to bring it in - though of course i cannot change the splitter position from within the form editor, because that would be too convenient i suppose).

I've seen form designers from open source projects written by a single developer in their free time that are more polished than that. The only thing worse is writing those UIs by hand.

I prefer writing UI by hand, rather than using Qt Designer. In C++, I figured out a few simple macros to automatically redefine `auto w` and `auto l` to refer to the parent widget and layout.

Is there a reason Qt Designer generates .cpp files which append a child to the parent after the child is fully fleshed out, rather than when the child is first constructed? Does the latter approach create too many relayouts, or did it do that in the past? I tried to replicate that design quirk in my code, and had to use RAII to "add child to parent at end of scope", even though I don't want the destructors to run if an exception occurs during UI layout.

I doubt order matters much. Typically you call setupUI() and then show(), so the widget is hidden during initialization. I don't think any layout work actually occurs until the widget becomes visible.

“should as such not be disruptive to our users” and “Elements of artificial intelligence will be more commonly used in applications and devices, and we will need to have easy ways to integrate with those.” told me everything I need to keep away.

Focus QT! What do you want? Do that well.

Uggh, yeah. I'm excited (well, as excited as I can be as someone who writes server/web software these days) about some of the stuff mentioned, but this is off-putting. It has no place in a GUI-focused framework in my opinion.

Qt isn’t just a UI focused framework, it’s a full stack framework, from UI widgets over included web frameworks all the way down to native integration.

Especially in automotive you’ll find that pretty much all media/entertainment functionality is running Qt, all the way through the stack.

Telling us that automotive interfaces run Qt is the most scathing comment on Qt that you could possibly have written.

Let me use a car analogy (heh) to critique your reasoning: "Telling us that automotive interfaces run on Linux is the most scathing comment on Linux that you could possibly have written."

I have worked on IVI ("in-vehicle infotainment") software and I can tell you that Qt is not even remotely the problem. The problem is... car companies are really, really bad at software development.

Most of the development is outsourced through so many levels it might as well be done on mars. "Hardware design? Yes we do that all here in Germany. Oh about the software? No we don't do software."

Manufacturers still have not realized that the software is crucial and cannot be regarded as a cost-center which needs to be outsourced at the lowest possible cost.

And it's quite obvious that they don't do much testing at all, either (even without knowing they don't, it's obvious). It's the only way how you can end up with for example a reversing camera that practically never works if you start the car in R.

By that reasoning, no one should criticize Electron because VS Code (and a few others) have managed to make it performant.

My comment was partly tongue-in-cheek, but the kernel of truth in it is this: a good UI tool makes it easy to build what you want without sacrificing speed, not hard.

Electron makes it incredibly hard (though still possible). I'd be interested to know how much better of a balance Qt strikes.

UI development is not a purely technical discipline, in fact it's very much shaped by design and user experience. To put it another way - if font rendering's poor or the UI's rendered at 15fps maybe one could blame the UI framework (although not always), otherwise it's on the programmers and designers.

Tesla is using Qt, that's not a bad ui imho.

Not sure what my Toyota is running but the base system is QNX and Qt runs on that system too. The touch screen and cpu is crap though not necessarily the ui.

It could also be Crank Storyboard. They're more tightly-focused on pushing pixels than Qt is and their framework is more focused on turning your Photoshop drawing of a UI into a UI but they skewed heavily into the Automotive realm.

And all the users hate it and just connects their mobiles instead. It’s like they ask each developer at the firm what they want to do instead of their customers.

Ideally developers would ask their users so that information would roll towards Qt developers. In practice developers just ask for whatever shiny toys they want to play with.

That's fair enough, I suppose. It is a large full featured batteries-included framework. Still, I feel like the existing stuff (last I used Qt anyway) all felt at home all made some sense: it was either interface related (user interface, network interface, file interface) or general tools to work with those interfaces (event loop, signals & slots, containers, MVC). I suppose maybe you could argue that AI stuff is also interfacing with other stuff. Still, it seems that its constantly expanding its scope. I wish it didn't, I wish they'd focus on making Qt Quick more desktop friendly (sounds like they have some plans for that in Qt 6, but.. I wish they'd focus heavily on that). A big reason why I stopped using Qt was because of the disconnect between Qt Quick and QWidgets. I like QML a lot, but I'm not making mobile apps.

Then again, its been ages that I had any use for Qt. Most of my work is backend or web and even mobile apps, which is something I would have considered Qt for in the past, I would now look into react native or PWA's.

Ya I read the AI think and I was like hmmm... I guess the editor thought there wasn’t enough buzzwords in the article. I’d love to see what this “easy integration” between “AI” and a GUI framework looks like.

AI is the "mobile" of 2019.

I mean, the second one makes sense to me. Medical loves QT, and I can see them wanting easier integration of visual recognition models (think "detects breast cancer on an MRI" models) with the GUI. I could totally see wanting to really easily plug and unplug different models and overlaying their results, bringing you full circle to the GUI. Basically easier integration with complex heavily multipass GPGPU visual results.

Can you explain what you mean? Normally you just send in the pic to Tensorflow that then uses the gpu, where would QT enter the picture that would be more than two lines of code?

If they mean better python integration.. then YES

TensorFlow needs a lot of scaffolding for managing the lifecycle of data/&c. A big attraction of Qt is that it is often more like writing Java than C++.

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.

@pjmlp Thanks for the suggestion. I can see using WPF/WinUI for corporate-type apps where it will run under Windows on thousands of desks. However, if WPF/WinUI doesn't run on macOS, there is no incentive to use it for consumer products. When I do customer presentations, the number one question is "When will it run on the Mac?"

Maybe sooner than we would expect, but it will take a while still.

https://devblogs.microsoft.com/dotnet/calling-all-net-deskto...

It's good to see language compatibility mentioned, and I hope they follow through with it.

There were really fantastic Common Lisp bindings for Qt4, but they relied on a tool called "Smoke", which stopped working with Qt5. My understanding is Smoke was used to create the early Python binding, but a different mechanism was used for the Python bindings in Qt5. For some reason the new technique wasn't as easy to use from other languages, so a lot of alternative language bindings stagnated on Qt4.

I don't know if it's improved lately, but between using C++, the non-standard moc pre-processor, qmake, and little support from Qt itself, it's really hard to generate bindings for Qt now.

Here's a quick history lesson. Long ago Smoke was created by one guy, Richard Dale, to do bindings for Ruby (QtRuby). Smoke was generic enough to be used for other languages like Lisp and also the .Net CLI. Language bindings other than Python didn't really catch on and the community needed to make it all viable and self sustaining didn't emerge. It was mostly one person's passion project and they didn't get any real help. So it died.

PyQt (Python) came from a small one man company in the UK called Riverbank Computing. It is mature and has been around for a long time. It used a custom tool called SIP for the bindings. Last time I checked it was still around.

In the Qt Nokia era, a team was assembled by Qt to create official Python bindings to compete with PyQt. IIRC they used Swig to do it. Then they lost funding for a few years before being revived in some form at which point they were busy moving to their own home grown binding generator.

And that binding generator is called Shiboken, which was motivated by boost::python and the same idea behind the binding generator written for Java in the old days (from QtJambi).

At the moment Shiboken is more general, and mature and can be used even for C++ projects (which are not related to Qt). https://wiki.qt.io/Qt_for_Python/Shiboken

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 it or not, there's a reason why electron apps and native ui sdks become the zeitgeist. While reusability is often cited as the main reason why electron has become the cross platform defacto, there's a lot more to it than that.

Personally, the difference between using electron and Qt is black and white. Looking at setting up alone, With Qt you have to struggle to compile a massive library which inevitably won't work. After sinking hours into compiling it, you're confronted with a unknown markup language and toolchain just to get a window displaying. And the documentation is incomplete, and to top it all off the minor versioning differences will cause your app to break in spectacular ways. Compare this to electron, where everything just works out the box, and with npm you have every single library you could ever think of. Microsoft and Apple roll out the red carpet for developers to make ui development super easy, so making two apps with a shared library is often just as tempting.

The way I'd try and save qt would be to make a react-native binding a first class citizen and ditch QML/js engines. I'd also remove the custom tool chains and release extensions for VSCode/Atom that outputted jsx that could get interoperated by a virtual dom. developers would kill for that.

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, but there's literally dozens of these built on Qt and shipping), medical equipment, industrial machines (e.g. the entire HMI sector), kiosk systems, coffee makers, ... Qt is an excellent choice for these, often the only one, and the web stack is very unattractive there due to performance/hardware overhead, quality, security, etc. They're product use cases in industry, with a lot of available very high-paying jobs.

And it's worth keeping in mind that the use cases I cited above by and large pay better than making desktop software does today, unless you're an entrenched player like Autodesk (which uses Qt doe many of its apps). In the only "this pays for a decently sized staff of engineers" desktop app products that are new that I can think of, Qt is also still doing well - say, Pix4D's apps for drone mapping/photogrammetry - because they likewise solve hard problems where you don't want to deal with the web API abstraction/quality barrier and performance overhead.

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.

As for making desktop apps, if your experience is "Looking at setting up alone, With Qt you have to struggle to compile a massive library which inevitably won't work" it shouldn't be ignored and the developer experience should be improved - tooling, build system and getting modules to devs are all mentioned in this blog. However, I have to say this has never been my experience - between Qt being packaged in Linux distros and the SDK installer on other platforms it's never been hard to set up Qt for me.

The article itself lists portability as their most important selling point.

Yes, but - the point the blog makes is more subtle than that. If you read closely, you'll find two contrasting and complementary statements - "desktop is the root of our offering" and "we see our biggest growth in embedded".

What's going on there is that for that lucrative OEM product market I mentioned, it's a very attractive quality of Qt that their developers can test builds (of what is technical not a desktop app as it doesn't aim to integrate with the host platform) on their desktop system instead of having to remote-deploy to the embedded device or spin up an emulator for every change (cf. https://www.youtube.com/watch?v=EswaK8hTonA&t=42s). A lot of Qt's lesser competitors in the domain don't offer this to the same extent.

The other reason is that the desktop is very important as a recruitment vector for the companies that end up picking Qt partly because of the quality of the developer talent available. Not every young developer has access to a car infotainment test rig, but they have access to a desktop system; Qt needs to be on the desktop to allow you to learn it with just a desktop system. Plus open source communities like KDE that make a lot of desktop and mobile software act as a breeding ground for talented devs.

Portability is in many ways about Qt not narrowing into a specialist/niche product, many of which it outcompetes in domains where it's the best option. So it is critical, but it's critical to avoid that slippery slope that would eventually hurt the markets that keep it afloat, even if not all the platforms equally bring in the money all times. It's about generality as a feature for a healthy systems technology.

Another big user of Qt for their desktop products is Tableau, since it provides the same experience across Windows and OS X.

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

> Those skills are not very transferable.

I think you are very wrong. Qt is just a bunch of C++ with preprocessing. Knowing C++ is a very transferable skill.

Yes, I'm fully aware of what C++ is. I'm talking about Qt skills specifically.

My point is that in Electron development, the Electron specific skills is very small part of development. Most of the skills and tools used are also widely used elsewhere in industry. This is not the case for Qt work.

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

This isn't how it shakes out in practice, though. If you're "specializing in Qt", what you really become is a GUI systems engineer who in the course of their career will learn the fundamentals of many of the things this entails. You'll be the person that knows how the browser works and how to write it, not the person who is beholden to its crummy abstractions on top of better APIs. Case in point - the Chromium/Blink engine used by Electron was originally a Qt codebase (KHTML).

Most Qt engineers I know have a lot more fundamental, transferable knowledge than the web engineers I know.

Don't forget that Qt has its own market where Electron even can't play well: Embedded systems.

I guess you are a JS developer. Some of us have a C++ background and C++ code base. Qt is for us a more natural choice (and has been for a long time) than electron is. "a unknown markup language and toolchain just to get a window displaying" is basically what JS/CSS is for me (is it still hard to get a text center-aligned vertically and horizontally or have they finally gotten over that?)

Qt does not force you to use that language, the C++ API works fine and in my experience, the documentation has been one of the best I had the pleasure to work with.

"Microsoft and Apple roll out the red carpet for developers to make ui development super easy"

Microsoft I agree. Apple, on the other hard... Last time I checked (admittedly, a few years ago) there was no way to code an app without having a Mac hardware and a developer license. I ended up borrowing a friends' mac to compile... a Qt app. That worked immediately.

> is it still hard to get a text center-aligned vertically and horizontally

This has not been true for over 5 years.

It had never been true at all if you didn't care about gaining kudos from CSS purists and just used a table :-P.

Since this discussion I have checked to see if one of the projects I want to do, that requires OpenGL rendering inside an UI, would not be doable with electron.

Google Qt and OpenGL and you get the documentation of the appropriate widget. Google GL and electron and you get a bunch of github issues and people complaining it does not work well yet.

Nah, JS is struggling to get where Qt has been for years. I am happy that it solved its text alignment issue in 2014 though.

> With Qt you have to struggle to compile a massive library which inevitably won't work. After sinking hours into compiling it, you're confronted with a unknown markup language and toolchain just to get a window displaying. And the documentation is incomplete, and to top it all off the minor versioning differences will cause your app to break in spectacular ways.

I'm not sure if you have used Qt recently based on this description. There is no need to build it from source, just use the installer, then launch QtCreator, everything just works, on win, linux and mac.

The Qt document is the best I have ever seen.

> With Qt you have to struggle to compile a massive library which inevitably won't work. After sinking hours into compiling it,

why would you have to compile Qt if you just want to make an app ?

I'm looking forward to doing a comparison of Qt 6 and Electron in terms of both usability and performance.

What? That would just be a rant.

Electron apps generally have no accessibility consideration, and accessibility is often the cornerstone of usability. Especially for keyboard users.

Additionally, their performance is abysmal. Even the latest Slack update, which was focused on improving performance, see Slack using more CPU than my Java-based IDE (Jetbrains) sometimes.

One would think that a browser-based app should excel in terms of accessibility, because it's practically built into the engine.

Unless the QT guys do something completely of the charts, it will be a lumbering wheelbarrow vs an Aston Martin.

Cool, so you have worked with both, right?

Most people have used lots of Qt apps and lots of Electron apps, which is enough to get an impression of the general performance characteristics of each.

The order in which they were mentioned made Qt the lumbering wheelbarrow.

I'm not sure which is the wheelbarrow in your analogy.

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?

Because a vast number of mediocre JavaScript developers can suddenly easily port their mediocre web apps to the desktop, and because companies love the "only one codebase" idea.

There's no technical merit to Electron.

The native desktop application has been replaced for all but the most complex and inertia-driven established behemoths. Was there technical merit in moving desktop applications to the browser in the first place throughout the 2000s? In most cases: no. All of the functionality of the web interfaces could have been written as more performant native desktop analogues, but it's 2019 now and starting on the web is the defacto default while making a desktop application is the exception.

Being mediocre has nothing to do with it.

Also portability from a popular platform is a technical merit.

That Qt is better on its own is also a merit, but not the only one.

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.

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.

I had to search for the video, but I guess you are talking about this?

https://youtu.be/TZnajQqqKV8?t=2894

Yep, that one.

So, RN can be used as an Electron replacement?

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

Evolus Pencil is a cool desktop app for creating wireframes (open source). It really offers great functionality.. it's now based on Electron (was based on Mozilla XULRunner)

... Performance is terrible on a quad-core i5 notebook with 16gb of ram and a gtx 1060 graphics card... I am talking about dragging the first element on an empty canvas and resizing it.

Hopefully Electron will improve - more choices are always nice.

But then again, Electron is based on Chromium and Node.js, both are "C++-based". Improvements in those C++ codebases and improvements in C++ compilers will probably also lead to better performance in Electron itself.

I'm quite skeptical that this is a problem with Electron.

I use nw.js which is similar to Electron for a UI that also allows dragging shapes and text around. It's SVG-based and it's stupid inefficient-- for every mousemove event I'm sending coords over the socket to a backend and receiving back a message that triggers a callback to do the actual property/attribute updates to the respective DOM elements. In other words, I'm using the browser's slowest graphics API in such a way that any layout changes are guaranteed to trigger the least performant graphics updates.

Still it performs just fine on a Lenovo from 2006.

What you are probably seeing is that the Electron GUI toolkit allows devs to throw together a GUI so quickly that they can ship a product in the time it takes to read the documentation of other GUI toolkits. You may thus be comparing a class of cross-platform applications in Electron which simply don't/can't exist in other GUI toolkits given the same amount of effort.

Would there be a chance of rust integration with these stronger types they mention?

There are a couple of projects attempting Rust integration with QML. In particular, I forked Jos van den Oever's seemingly unmaintained bindings generator:

https://gitlab.com/rhn/rust-qt-bindings-generator

It's for Qt5, and I think I know how to achieve strong typing (just turn everything into different QObjects, they don't get converted), but haven't implemented that idea yet.

I've been wondering, but how is Qt Rust integration actually doing at the moment?

I'm no UI designer/programmer, but it seems to me that Qt being apparently very dependant on C++'s object oriented concepts seems to make integration with Rust very difficult, since Rust very much does not follow's C++ concepts of objects and classes.

HN hug of death? https://archive.is/VVpgQ

I just hope they gonna keep memory footprint as low as possible so I can keep bashing electron devs.

> I just hope they gonna keep memory footprint as low as possible so I can keep bashing electron devs.

well, they want to focus on microcontrollers apparently :-)

I hope QML/js crap will be abandoned, and C++ API will be prioritized.

That’s not going to happen. Did you read the blog post?

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.

>C++ (and even Rust) is not the best language to build UIs.

Why? And why are scripting languages better?

Developer productivity when building or redesigning a UI is often far more important than raw performance. There's usually no noticeable difference for a user whether the dialog they opened via a button click is built in highly optimized C++ or from an XML resource stream that is read, parsed, and the UI constructed on the fly by effectively interpreting the UI description.

It's okay to have expensive abstractions where a few milliseconds simply don't matter, but tasks can be done in minutes instead of hours. Declarative UI descriptions also have the benefit of being friendly to visual designer applications, so you need fewer build/run/test cycles (which are far from quick with C++).

>There's usually no noticeable difference for a user whether the dialog they opened via a button click is built in highly optimized C++ or from an XML resource stream that is read, parsed, and the UI constructed on the fly by effectively interpreting the UI description.

I dare you to compare the speed of UIs of Windows XP and Windows 10, even when using the hardware that was current when those OSes were released.

Someone did a detailed study of UI responsiveness vs year.

Responsiveness peaked in the 80’s, in the dumb terminal + regional mainframe era. :-(

Do you have a link? If it is the one i remember it was about keyboard-to-output responsiveness (and the winner was something like a C64 or Apple 2 or something like that), not overall UI (and i'm a bit skeptical about the dumb terminal part considering the communication latencies involved, especially in the 80s).

This "productivity is more important than raw performance" meme again... Your first paragraph claims the opposite of what's happening reality: there is a noticeable difference between clicking that highly optimized C++ button and going through XML, as seen in Mozilla's XUL or typical web apps.

I can't even imagine why you'd think that reading and parsing XML and constructing a UI would be cheaper than any other way of building UIs.

>there is a noticeable difference between clicking that highly optimized C++ button and going through XML, as seen in Mozilla's XUL or typical web apps.

Really, did you measure it? Since we are, scientists and everything? Where are the numbers?

And how do any differences you've found compare (timing wise) with human initiated action and perception latencies -- like those required to click an on-screen button and see it being depressed?

>as seen in Mozilla's XUL or typical web apps

You see button being pressed time/action as a problem in "XUL or typical web apps"?

(Memory consumption when the drawing is done with DOM, or slow rendering of large scene graphs, I'd buy -- but this is not the model we're talking here, where JS calls a native control directly, and doesn't render through DOM/web rendering).

>I can't even imagine why you'd think that reading and parsing XML and constructing a UI would be cheaper than any other way of building UIs.

Actually that's the way tons of native apps work, from games, to Gnome, to Windows and so on.

Second, if you think the "parsing a XML UI declaration" is in any meaningful way more expensive that imperatively calling a bunch of UI functions directly, you have a distorted idea of what makes a UI slow, or of the time needed to parse an XML file and initialized controls based on it...

>Really, did you measure it? Since we are, scientists and everything? Where are the numbers?

This remark should (also) have been directed at his parent comment, who made the contrary claim without any measurement either.

> Second, if you think the "parsing a XML UI declaration" is in any meaningful way more expensive that imperatively calling a bunch of UI functions directly, you have a distorted idea of what makes a UI slow, or of the time needed to parse an XML file and initialized controls based on it...

The numbers?

I'm not a scientist, so I did not measure it, however my empirical analysis suggests that this is indeed the case. Non-native UIs are noticeably slow. They don't have a monopoly on being slow, but they are slow across the board.

You might want to read this ode to fast software: https://craigmod.com/essays/fast_software.

I don't understand why they would parse the XML on the fly. Qt's designer spits out *.ui XML files that are compiled by Qt's uic into the same plain old C++ you would write to create and arrange the widgets.

Lots of C++ Qt apps create their UIs from XML. They just do it at compile time.

.ui files can also be parsed at run-time (with QtUiTools iirc)

Memory management.

The user interface tends to be a relatively dynamic part of the application.

Most of this is no longer as relevant in C++, can't speak for Rust. Programming languages have been converging for quite some time, C++ of today is more dynamic and convenient than any version that came before.

That being said, you can't beat dynamic languages for some tasks. Runtime code generation/eval being the most obvious I can think of. Any kind of extension/plugin architecture has everything to win from going all in with a full scripting language from my experience.

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 compared to regular programming languages, but that's unrelated to the claim you made.

Bindings are not C++'s problem, they're the problem of the other languages which try to use UI frameworks written in C++, like Rust, which still doesn't have any decent UI library.

> This is visible when comparing PyQt and C++: yes, PyQt is easier to get into, has nicer syntax, but C++ offers more power.

That may be true for Python, but the Common Lisp bindings for Qt4 were equally as "powerful" as the C++ bindings. It had higher level abstractions that generally made it easier to read and write, as well.

> Bindings are not C++'s problem

Actually, bindings are a problem with C++. Some features (like templates) and implementation details (like name mangling) make it very difficult to create bindings to C++.

I keep coming back to the differences between OPENSTEP and Taligent and believe C++ isn't the best choice.

What were some of the differences? (Other than Taligent dying and OPENSTEP surviving via Mac OS X, which is all I know about the topic.)

There's a reason Qt had to invent the MOC.

https://books.google.com/books?id=e35JCAAAQBAJ&pg=PT139&lpg=...

Gives the basics of the difference

They have the graphics layer written in C++, but get used from managed languages.

QML, Swift, Android, UWP, WPF, Forms, Blueprints, Unity, React Native.

I've worked on two products with touchscreen UIs now and I can safely say this is exactly how I want to do things. Have a tight core engine but with a flexible declarative language that I can get imperative with. And make it easy for me to declare connections between the model and the view without specifying data types. And give me a way to work with a statically typed language when that's beneficial.

QML is way faster to develop in than C++. And it hides a lot of signal/slot boilerplate that doesn't matter. And I can still write C++ classes that interface with QML when I want.

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

QML is amazing and I hope your hopes are dashed.

For better or worse, pure C++ APIs have lost the war on GUI frameworks.

Microsoft is the only consumer OS vendor that still supports C++ for doing full stack GUI apps, everyone else moved into a mix of C++ plus managed language or layout DSL.

> Microsoft is the only consumer OS vendor that still supports C++ for doing full stack GUI apps

On modern Windows you have C++, and also layout DSL, specifically XAML. And that C++ is not particularly idiomatic, it’s IUnknown-derived interfaces.

If you mean windows desktop, WinAPI uses quite a few DSLs. Dialog and menu resources are the most obvious, but there’s more: WMF/EMF vector graphics format, ribbon markup XML for ribbon control, theme files…

You are talking about Win32 legacy API, stuck in Windows XP feature level.

Modern Windows desktop UI, UWP aka WinUI, uses C++17 with a framework called C++/WinRT, that hides those IInspectable COM interfaces.

Yes there used to exit C++/CX and Windows Runtime Library, both now considered legacy and replaced by C++/WinRT.

Who is „everyone else“? GTK‘s primary API is C, Apple‘s is Objective C or Swift, none of them are „C++ plus managed language“, only SwiftUI is „layout DSL“ and it isn’t even released yet.

So for targeting X11/Wayland or Windows, you can bet 100% on C++, only Apple platforms do not offer native C++.

Metal is written in C++. Try to display graphics in Objective C or Swift without Metal, going further.

Which UNIX OS SDK uses a C++ GUI full stack?

One could argue for Kubuntu or SuSE, maybe, except KDE isn't tied to a specific OS and then again it uses Qt alongside QML since Plasma, so no pure C++ stack here.

And since you missed to fully read my comment, here it is again:

> Microsoft is the only consumer OS vendor that still supports C++ for doing full stack GUI apps

The KDE desktop shell is QML + C++. The vast majority of KDE applications are QWidgets + C++ without QML.

I like QML but it's not that great for many / most desktop applications. It works better for creating fully custom touch UIs from scratch. The plan for Qt 6 mentions a styling API which is one of the most important missing pieces, and discussion in the comments maybe indicates more ready to use controls.

Anyone remember Motif's UIL?

Plus ca change…

I hope for the overlap of their TypedQML with TypeScript. I am a C++ dev by career and had recently an opportunity to use TypeScript. It's quite nice. It has it's warts as it's structural typing, because of limitations within implementation goals - type erasure and being JavaScript but with types. As much as I would like to see TypeScript Native it's probably to difficult to marry JavaScriptness with relative ease of compilation to C++. Hopefully Qt effort could be extended beyond Qt itself and that would be something I would look forward to.

I wonder whether Qt could get rid of the C++ moc preprocessor. There are wonderful native signal-slot libraries for C++, and RTTI, introspection and reflection are either there or about to be standarized.

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 fixes styling, I would be onboard 100%. Performance is amazing and I like being able to develop one codebase for all operating systems.

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" }

Any ideas in Flutter or React that might be useful to have in Qt?

Where did this question come from?

GUI frameworks borrow ideas and innovations from each other all the time. It's a totally normal thing, and hence an obvious question.

Yes, but I would expect that there is a particular aspect of a framework one might be interested in seeing adopted in another framework. But asking what a random framework X has to offer for framework Y, when framework X wasn't mentioned anywhere previously is unexpected. It's like seeing under the release notes of a new linux kernel version a question "any ideas from windows that might be useful in linux?". I'm probably overthinking it. :)

I hoped there would be more focus on how their web assembly support will be improved (specifically, how they intend to handle the narrow viewports of mobile devices).

Web Assembly QT enables a really nice way for customers to mess with an app without installing anything on their systems. It works with Q5\, but a still has much to be improved.

\ with a bit of modification to QT's output.

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.

They should add official Rust bindings.

is it possible to have safe bindings for something like Qt? never understood if that's a thing or not since I've heard FFI usage is inherently unsafe.

I assume if the logic is wrapped into something that handles it correctly, you can declare it as safe, even if inside it's unsafe.

Yeah, unsafe doesn't have to pollute callers (async in C# is a good example of something that does)

I have given up on Qt since it doesn't work efficiently with X11. GTK works OK though.

Eh? X11 is probably Qt's best target, and it's one of the most popular toolkits for building X11 applications. What made you think it wasn't efficient?

Lack of support for X forwarding in Qt5 perhaps? JPEGs are being sent over the network and so the experience when using e.g. X2GO with a recent Qt Creator on a server is crappy.

Check out https://bugreports.qt.io/browse/QTBUG-50338

They made a choice that was good for local rendering but because it sends full bitmaps to the X server to display it uses a lot of bandwidth which killed performance when forwarding X applications over the network.

I'm personally of the opinion that today's X is only accidentally network transparent and a bad remote desktop solution but I don't deny that it's part of a lot of peoples' workflows.

Right, that makes sense. I didn't know they removed QT_GRAPHICSSYSTEM=native in Qt5. I'm of the same opinion as you, but I can see why it would be a problem for some. (For some reason we still had to use Solaris X terminals in my first year of university.)

Native painting was reimplemented since 5.10. You need to configure Qt with with -xcb-native-painting though.

Does that mean all current KDE applications will soon become binary incompatible with the future KDE libraries that will be based on Qt 6?

KDE applications and KDE libraries will be updated together. How else could it be?

It won't be soon, either. Qt is aiming for a first release of Qt 6 by the end of 2020.

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.

How about direct support for modern, UI-focused languages like Swift and Kotlin?

Any cheaper licensing options for us embedded folk?

Could someone please please fix vncserver to properly display applications using qt?

Have you considered rewriting it in Rust?

Honestly at this point they should just rewrite it in Javascript and focus on javascript bindings. Javascript is simply more productive and friendlier for devs to work with. This would allow Qt to compete with Electron for how well my hands are kept warm by my laptop during the winter.

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.

Autodesk Maya 2019 is one pretty good example off the top of my head

Maya uses Qt since 2010, before Electron existed.

https://www.youtube.com/watch?v=7zWlwdr7exo

> before Electron existed.

And what an amazing time that was.

Popular doesn't mean good. In fact Electron is born out of the idea that developer productivity and comfort is everything and performance is a secondary concern.

These apps seem to be popular with device manufacturers. I have the displeasure of using two such apps, both have crap usability and custom UIs that don't make any effort to integrate with the platform. One of them doesn't even respond to the quit shortcut.

> These apps seem to be popular with device manufacturers.

All apps written by device manufacturers are crap, regardless of what they are written in. It has nothing to do with Electron, just with the fact that they only know how to do hardware, and are clueless on the software side.

The apps function correctly, it's the UI that is the problem.

It's modern looking, but obviously not native and doesn't respect some platform idioms or shortcuts, so all in all it's a subpar experience. This is completely related to Electron and would not happen for a native app, where the framework takes care of the look & feel and integration.

If every app were written like this, we'd end up with scores of slightly inconsistent apps, all of them trying to be unique and cool and resulting in a mediocre platform. i.e. Windows.

WebOS, Qlik and Tableau are built using Qt.

https://resources.qt.io/customer-stories-all

Also, Tesla's dashboard user interface is apparently built on Qt. I honestly would not feel safe in a car built around Electron, even if it's just the UI.

krita,

vlc,

VLC is not using Qt, at least not on macOS, I just checked.

https://wiki.videolan.org/Qt_Interface/

Blizzard launcher.

Isn't that just a website running locally under CEF?

I don't believe so, unless it's changed recently.

The Linux version of Mathematica

This is bait.

But easily, Skype.

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

Roblox Studio is using Qt 5; I just tried that yesterday.

As too often for a Qt application, the interface looks alien on macOS.

Reply on news.ycombinator.com