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

161–170 of 184 posts

Re: Technical Vision for Qt 6

#161

Post by jcelerier »

hawski wrote: post #103
jupp0r wrote: post #12

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.

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…

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

Re: Technical Vision for Qt 6

#162

Post by jcelerier »

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…

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

Re: Technical Vision for Qt 6

#163

Post by jcelerier »

slavik81 wrote: post #58
blub wrote: post #30

Earlier quoted context omitted.

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

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)

Re: Technical Vision for Qt 6

#164

Post by jcelerier »

Spivak wrote: post #147
rossy wrote: post #129

Earlier quoted context omitted.

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?

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…

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

Re: Technical Vision for Qt 6

#165

Post by 0lpbm »

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…

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

Re: Technical Vision for Qt 6

#167

Post by sime2009 »

0lpbm wrote: post #165
sime2009 wrote: post #157

Earlier quoted context omitted.

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

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

Re: Technical Vision for Qt 6

#169

Post by FraKtus »

notathing wrote: post #63

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.

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

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

Re: Technical Vision for Qt 6

#170

Post by tempguy9999 »

tonyarkles wrote: post #124
malkia wrote: post #118

Earlier quoted context omitted.

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

Post reply on HN