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

Technical Vision for Qt 6

blog.qt.io

Post reply on HN
Print view View original

171–180 of 184 posts

Re: Technical Vision for Qt 6

#171

Post by sho_hn »

sime2009 wrote: post #157
sho_hn wrote: post #126

Earlier quoted context omitted.

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

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

Re: Technical Vision for Qt 6

#172

Post by wwright »

pjmlp wrote: post #158
wwright wrote: post #133

Earlier quoted context omitted.

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.

Re: Technical Vision for Qt 6

#173

Post by lkschubert8 »

shmerl wrote: post #115
oehtXRwMkIs wrote: post #113

Earlier quoted context omitted.

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)

Re: Technical Vision for Qt 6

#174

Post by anilgulecha »

Iv wrote: post #136
pippy wrote: 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 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…

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

This has not been true for over 5 years.

Re: Technical Vision for Qt 6

#175

Post by tonyarkles »

tempguy9999 wrote: post #170
tonyarkles wrote: post #124

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…

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.

Re: Technical Vision for Qt 6

#176

Post by tonyarkles »

malkia wrote: post #139
tonyarkles wrote: post #124

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…

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.

Re: Technical Vision for Qt 6

#178

Post by malkia »

tonyarkles wrote: post #176
malkia wrote: post #139

Earlier quoted context omitted.

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.

Re: Technical Vision for Qt 6

#179

Post by cerberusss »

4ad wrote: post #70
halflings wrote: post #60

Earlier quoted context omitted.

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

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

Re: Technical Vision for Qt 6

#180

Post by Crinus »

anilgulecha wrote: post #174
Iv wrote: post #136

Earlier quoted context omitted.

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…

> 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.
Post reply on HN