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

131–140 of 184 posts

Re: Technical Vision for Qt 6

#131

Post by kbumsik »

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…

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

Re: Technical Vision for Qt 6

#132

Post by sho_hn »

wwright wrote: post #130
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…

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.

Re: Technical Vision for Qt 6

#133

Post by wwright »

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…

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

Re: Technical Vision for Qt 6

#134

Post by wokwokwok »

halflings wrote: post #60
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.

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

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.

Re: Technical Vision for Qt 6

#135

Post by wwright »

danielscrubs wrote: post #86
monocasa wrote: post #57

Earlier quoted context omitted.

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

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?

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

Re: Technical Vision for Qt 6

#136

Post by Iv »

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

Re: Technical Vision for Qt 6

#137

Post by yakubin »

mkl wrote: post #117
yakubin wrote: post #50

Earlier quoted context omitted.

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

Re: Technical Vision for Qt 6

#138

Post by billconan »

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

Re: Technical Vision for Qt 6

#139

Post by malkia »

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…

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.

Re: Technical Vision for Qt 6

#140

Post by slavik81 »

halflings wrote: post #60
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.

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

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