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

41–47 of 47 posts

Re: Understanding the Layout Process in Qt Widgets

#41

Post by Joel_Mckay »

ranger_danger wrote: post #37
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

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.

It uses the native OS themes, so should appear as a standard program.

Ever consider what happens when designers try to redefine 40 years of interface inertia. You get Windows Vista or MacOS 8.... lol =3

Re: Understanding the Layout Process in Qt Widgets

#42

Post by ranger_danger »

Joel_Mckay wrote: post #40
ranger_danger wrote: post #38

Earlier quoted context omitted.

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 opinion…

but both Qt and WX is LGPL ?

Re: Understanding the Layout Process in Qt Widgets

#43

Post by Joel_Mckay »

ranger_danger wrote: post #42
Joel_Mckay wrote: post #40

Earlier quoted context omitted.

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 opinion…

but both Qt and WX is LGPL ?

wxwidgets is a slightly more permissive license than lgpl.

When people must static link on some closed mystery object, than the subtle difference becomes very important.

lgpl works great in the Linux .so design paradigm, but it can cause problems on rare occasion for porting. =3

Re: Understanding the Layout Process in Qt Widgets

#44

Post by Remnant44 »

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.

I haven't had a high DPI issue with QT in quite a while. Early in QT 5, high DPI presented many problems, but they have been slowly settled over time, including by using sane defaults.

Source: I develop a QT widget app and develop on a workstation with mixed high and low DPI monitors.

Re: Understanding the Layout Process in Qt Widgets

#46

Post by neobrain »

throwup238 wrote: post #39
neobrain wrote: post #32

Earlier quoted context omitted.

> 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 gr…

Ah, I somehow assumed more magic would be needed, but indeed it's really as simple as deleting the top-level widget and recreating it. And then repopulating the properties is what gives it the illusion of being dynamically live-patched.

I'll take a shot at implementing this in some of my code as well. Thanks!

Re: Understanding the Layout Process in Qt Widgets

#47

Post by chris_wot »

felipefar wrote: post #24
chris_wot wrote: post #23

I’d love to see an article on Qt text layout processing.

That's actually a great idea for a second follow up article. I've worked a lot with rich text and custom text objects, but would also like to explore itemization and the lower level layers. What would you like to know more about it?

I'm curious how they are doing it from paragraph segmentation to text runs... it's an incredibly complicate algorithm if you are accounting for all scripts known.

I've looked at the LibreOffice text layout algorithm, so I'm curious how Qt handle text layout!

Post reply on HN