Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Understanding the Layout Process in Qt Widgets

felipefarinon.com

Post reply on HN
Print view View original

31–40 of 47 posts

Re: Understanding the Layout Process in Qt Widgets

#31

Post by wokwokwok »

throwup238 wrote: post #2

I'm curious why you chose Qt Widgets for a relatively new application? Is desktop support that much better than QML? There's a bunch of tradeoffs for everyone who has to make that choice and it's always interesting to know why people choose the one that they do.

Rust bridge with C++ is a solved problem; since they have the same calling semantics you can easily bind rust callbacks to your c++.

JavaScript-Rust bridging (or any managed language) is slower and more effort to explicitly design.

My $0.02 would be: with widgets you can implement a lot of complex backend logic in rust, using a package manager that works (ie. cargo) to get significant productivity gains from the rust ecosystem for implementing the logic of your application. Specifically for example, threaded processes, network interactions and file parsers / exporters which get you “for free” functionality for eg. Loading .vox or .fbx files in an app, then passing them to c++ for processing / editing / rendering in the ui.

With QML you’d have to do that by hand. What a meaningless chore.

Also with QML, the runtime is not node compatible, so forget using existing packages in that ecosystem to help.

(There are obviously downsides too, like rust for mobile, but for desktop applications rust static builds are trivial to bundle in the c++ build process using cmake).

Re: Understanding the Layout Process in Qt Widgets

#32

Post by neobrain »

throwup238 wrote: post #6
felipefar wrote: post #5

Earlier quoted context omitted.

Well, I don't want to bash on QML, since I really appreciate the efforts that the team puts in it. But I do think its current state is not the best when compared to Qt Widgets, and lament that there's a split between the two toolkits inside the framework. The problems I had with QML are: 1) The controls that Qt Quick 2 provides are oriented toward touch interfaces, and some are not even feature-complete. For example,…

Thanks for the detailed response! I'm definitely feeling the majority of these paint points. > 2) Communication between QML and C++ is finicky. You have to use macros and Qt-specific constructs (Q_PROPERTY, signals, slots) to bridge both worlds. Qt Widgets doesn't need bridging in the first place, since it's C++ all the way down. This hurts so bad. I'm actually implementing in Rust so I've got double the pain and any…

> The big thing that sold me on QML over Widgets - other than the latter being the redheaded step child by this point - was implementing hot reloading. Having the entire UI completely refresh when changing the QML is definitely a nice coming from browser frontend, especially given Rust compile times.

Interesting, are there any public examples on how to implement this? All tools I've seen to do this seemed to be commercial offerings, though maybe implementing it in an existing application is easier than I think.

actually now that I'm looking again I found https://github.com/patrickelectric/qhot, which also looks promising

Re: Understanding the Layout Process in Qt Widgets

#33

Post by rubymamis »

felipefar wrote: post #11
throwup238 wrote: post #9

Earlier quoted context omitted.

Sidenote: Have you seen the new TextEdit improvements in Qt 6.7? I'm curious if that bridges the gap that you had when you started working on your app. My app is also text editing heavy so I'm hoping it's a big improvement.

I saw them, they are a very small step in what I believe is the right direction, since you can use a custom textDocument. Anyway what I think would be useful is to jailbreak the QML API. Make the QML C++ API publicly available. Let us derive from the controls, manipulate and customize them with C++, as the Qt team devs themselves do.

I've created my own block editor from scratch using Qt C++ and QML, which is way faster than a regular QML TextArea[1]. Which is funny since it's just a ListView with Blocks (that contain TextAreas).

[1] https://www.get-notes.com/

Re: Understanding the Layout Process in Qt Widgets

#34

Post by rubymamis »

felipefar wrote: post #5
throwup238 wrote: post #2

I'm curious why you chose Qt Widgets for a relatively new application? Is desktop support that much better than QML? There's a bunch of tradeoffs for everyone who has to make that choice and it's always interesting to know why people choose the one that they do.

Well, I don't want to bash on QML, since I really appreciate the efforts that the team puts in it. But I do think its current state is not the best when compared to Qt Widgets, and lament that there's a split between the two toolkits inside the framework. The problems I had with QML are: 1) The controls that Qt Quick 2 provides are oriented toward touch interfaces, and some are not even feature-complete. For example,…

> For example, QML's Flickable on desktop can be scrolled by clicking and moving the mouse, a behavior that is clearly an artifact from the touch implementation.

This should be fixed in Qt 6.9: https://bugreports.qt.io/browse/QTBUG-97111

> Ironically, even though Qt Quick is touch-centric, Qt has lots of bugs on mobile platforms, and has a history of presenting regressions on those platforms.

That's interesting. I'm soon planning on porting my app to mobile using QML so I'm curious how that would go.

> QML's TextEdit doesn't support much that QTextEdit does, which was particularly important for implementing an app that offers advanced text editing. Ironically, even though Qt Quick is touch-centric

I think the latest changes that expose textDocument and others are very good improvements[1]. Even without these, I managed to write my own advanced block editor using QML[2]. It took around 5 months but it was well worth it and quite straightforward to implement.

> The latency of interfaces built with QML is higher than the ones built with Widgets. QML's rendering engine is lagging behind in the input latency mitigation front when compared to browsers, although they've been making efforts in this area.

When you speak on input latency, what do you mean? For text? I really don't see much of a difference (at least here on my Mac). I saw you wrote that on Windows and Android it's worse. On Windows I didn't see an issue nor did someone reported about it.

[1] https://www.qt.io/blog/text-editing-improvements-in-qt-quick

[2] https://www.get-notes.com/

Re: Understanding the Layout Process in Qt Widgets

#35

Post by hermitcrab »

joezydeco wrote: post #22
hermitcrab wrote: post #14

Managing widget size and layout in complex UIs is definitely one of the more challenging aspects of programming with Qt. But you usually get what you want with a bit of trial and error.

Qt has a chronic problem with High DPI displays, especially when mixed with a lower DPI display in a multiple monitor situation. You will never get it 100% right and when you start shipping it to users that percentage will fall quickly.

Qt 6 is supposed to handle high DPI better. Does that not apply to multiple monitors? I have not noticed any issues.

Re: Understanding the Layout Process in Qt Widgets

#36

Post by magicmicah85 »

Joel_Mckay wrote: post #30
magicmicah85 wrote: post #28

QGridLayout is my go-to for applications. I like how it allows a responsive design when resizing. Most of my desktop apps are for simplifying tasks that my coworkers and me are doing, so no one's expecting the most professional look and Qt has gotten the job done. Have you used Qt Creator? Once I started using this, my app development started flying because I didn't have to edit, run program, edit again. Just drag an…

Why do your prefer it over https://wxwidgets.org given the licenses? Personally, I was keen on Qt right up to the 5.x change over. =3

What's the concern with Qt's licenses? Afaik, their current license works for me.

Re: Understanding the Layout Process in Qt Widgets

#37

Post by ranger_danger »

Joel_Mckay wrote: post #30
magicmicah85 wrote: post #28

QGridLayout is my go-to for applications. I like how it allows a responsive design when resizing. Most of my desktop apps are for simplifying tasks that my coworkers and me are doing, so no one's expecting the most professional look and Qt has gotten the job done. Have you used Qt Creator? Once I started using this, my app development started flying because I didn't have to edit, run program, edit again. Just drag an…

Why do your prefer it over https://wxwidgets.org given the licenses? Personally, I was keen on Qt right up to the 5.x change over. =3

WX just looks ancient to me, and doesn't have anywhere near as large a community, or as many nice-looking applications built with it. The only big license change in 5.x I'm aware of was moving from LGPL 2 to 3... I don't think that really affects the majority of users unless you're shipping hardware and don't want the anti-tivoization clause.

Re: Understanding the Layout Process in Qt Widgets

#38

Post by ranger_danger »

magicmicah85 wrote: post #36
Joel_Mckay wrote: post #30

Earlier quoted context omitted.

Why do your prefer it over https://wxwidgets.org given the licenses? Personally, I was keen on Qt right up to the 5.x change over. =3

What's the concern with Qt's licenses? Afaik, their current license works for me.

Qt 5.6 and later switched from LGPL v2.1 to v3. The main difference is the addition of the anti-tivoization clause that the regular GPLv3 has, wherein you cannot sell hardware that integrated Qt without providing a way for the user to replace your copy of the libraries with their own. Although at that point most people just buy a commercial license, and I think the majority of people that complain about this don't have a legitimate use-case that really affects them as much as they lead on.

Re: Understanding the Layout Process in Qt Widgets

#39

Post by throwup238 »

neobrain wrote: post #32
throwup238 wrote: post #6

Earlier quoted context omitted.

Thanks for the detailed response! I'm definitely feeling the majority of these paint points. > 2) Communication between QML and C++ is finicky. You have to use macros and Qt-specific constructs (Q_PROPERTY, signals, slots) to bridge both worlds. Qt Widgets doesn't need bridging in the first place, since it's C++ all the way down. This hurts so bad. I'm actually implementing in Rust so I've got double the pain and any…

> The big thing that sold me on QML over Widgets - other than the latter being the redheaded step child by this point - was implementing hot reloading. Having the entire UI completely refresh when changing the QML is definitely a nice coming from browser frontend, especially given Rust compile times. Interesting, are there any public examples on how to implement this? All tools I've seen to do this seemed to be comme…

It’s very easy to implement a naive version. It only took me a few hours with the help of GPT/Claude and most of that was figuring out how to save and restore all window positions.

All it is is Rust’s notify listening for any changes in my QML directory and calling a C++ function on QQmlEngine: https://pastebin.com/08QKu84H

It'll require a bit more work once I'm loading multiple root QML files but for now it works great. It doesn't explicitly restore any state, however, but I store most of my UI state in Settings and a custom component that syncs arbitrary JSON values to Sqlite so the previous state is automatically restored when the QML is reloaded.

Re: Understanding the Layout Process in Qt Widgets

#40

Post by Joel_Mckay »

ranger_danger wrote: post #38
magicmicah85 wrote: post #36

Earlier quoted context omitted.

What's the concern with Qt's licenses? Afaik, their current license works for me.

Qt 5.6 and later switched from LGPL v2.1 to v3. The main difference is the addition of the anti-tivoization clause that the regular GPLv3 has, wherein you cannot sell hardware that integrated Qt without providing a way for the user to replace your copy of the libraries with their own. Although at that point most people just buy a commercial license, and I think the majority of people that complain about this don't ha…

Mostly, 5.x broke many dependencies due to how the linking impacted license compliance issues. This meant users would be left to figure out why several features were turned off in the Debian package built.

I prefer wxwidgets, as its lgpl style license allows static-linking on both open or closed projects without submarine-IP-fees... undeniably useful when cross-porting to some platforms.

We may have differing opinions, as our use-cases likely differ. =3

Post reply on HN