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

51–60 of 184 posts

Re: Technical Vision for Qt 6

#51

Post by pjmlp »

blub wrote: post #26
ungzd wrote: post #11

Earlier quoted context omitted.

C++ (and even Rust) is not the best language to build UIs. Even if your app heavily uses C/C++ to do heavy computations, "scripting" language will be preferable for "glue code". QML is not a crazy new idea, for example Tk used Tcl. And due to C++ API, Qt has poor language bindings, compared to GTK and many others with C API.

I believe you're incorrect, C++ is a good language for building UIs, as proven by the plethora of UI libraries and frameworks built in C++ for pretty much all platforms. This is visible when comparing PyQt and C++: yes, PyQt is easier to get into, has nicer syntax, but C++ offers more power. Even hot-loading UIs, a typical scripting language advantage is supported. Declarative UI languages do have some advantages com…

They have the graphics layer written in C++, but get used from managed languages.

QML, Swift, Android, UWP, WPF, Forms, Blueprints, Unity, React Native.

Re: Technical Vision for Qt 6

#52

Post by tyfon »

smt88 wrote: post #23
kuschku wrote: post #21

Earlier quoted context omitted.

Qt isn’t just a UI focused framework, it’s a full stack framework, from UI widgets over included web frameworks all the way down to native integration. Especially in automotive you’ll find that pretty much all media/entertainment functionality is running Qt, all the way through the stack.

Telling us that automotive interfaces run Qt is the most scathing comment on Qt that you could possibly have written.

Tesla is using Qt, that's not a bad ui imho.

Not sure what my Toyota is running but the base system is QNX and Qt runs on that system too. The touch screen and cpu is crap though not necessarily the ui.

Re: Technical Vision for Qt 6

#54

Post by coldtea »

blub wrote: post #30
ygra wrote: post #18

Earlier quoted context omitted.

Developer productivity when building or redesigning a UI is often far more important than raw performance. There's usually no noticeable difference for a user whether the dialog they opened via a button click is built in highly optimized C++ or from an XML resource stream that is read, parsed, and the UI constructed on the fly by effectively interpreting the UI description. It's okay to have expensive abstractions wh…

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…

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

Really, did you measure it? Since we are, scientists and everything? Where are the numbers?

And how do any differences you've found compare (timing wise) with human initiated action and perception latencies -- like those required to click an on-screen button and see it being depressed?

>as seen in Mozilla's XUL or typical web apps

You see button being pressed time/action as a problem in "XUL or typical web apps"?

(Memory consumption when the drawing is done with DOM, or slow rendering of large scene graphs, I'd buy -- but this is not the model we're talking here, where JS calls a native control directly, and doesn't render through DOM/web rendering).

>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 of building UIs.

Actually that's the way tons of native apps work, from games, to Gnome, to Windows and so on.

Second, if you think the "parsing a XML UI declaration" is in any meaningful way more expensive that imperatively calling a bunch of UI functions directly, you have a distorted idea of what makes a UI slow, or of the time needed to parse an XML file and initialized controls based on it...

Re: Technical Vision for Qt 6

#55

Post by blattimwind »

ahartmetz wrote: post #45
smt88 wrote: post #23

Earlier quoted context omitted.

Telling us that automotive interfaces run Qt is the most scathing comment on Qt that you could possibly have written.

Let me use a car analogy (heh) to critique your reasoning: "Telling us that automotive interfaces run on Linux is the most scathing comment on Linux that you could possibly have written." I have worked on IVI ("in-vehicle infotainment") software and I can tell you that Qt is not even remotely the problem. The problem is... car companies are really, really bad at software development.

Most of the development is outsourced through so many levels it might as well be done on mars. "Hardware design? Yes we do that all here in Germany. Oh about the software? No we don't do software."

Manufacturers still have not realized that the software is crucial and cannot be regarded as a cost-center which needs to be outsourced at the lowest possible cost.

And it's quite obvious that they don't do much testing at all, either (even without knowing they don't, it's obvious). It's the only way how you can end up with for example a reversing camera that practically never works if you start the car in R.

Re: Technical Vision for Qt 6

#56

Post by mort96 »

ahartmetz wrote: post #47
tomjen3 wrote: post #32

Earlier quoted context omitted.

Unless the QT guys do something completely of the charts, it will be a lumbering wheelbarrow vs an Aston Martin.

Cool, so you have worked with both, right?

Most people have used lots of Qt apps and lots of Electron apps, which is enough to get an impression of the general performance characteristics of each.

Re: Technical Vision for Qt 6

#57

Post by monocasa »

danielscrubs wrote: post #10

“should as such not be disruptive to our users” and “Elements of artificial intelligence will be more commonly used in applications and devices, and we will need to have easy ways to integrate with those.” told me everything I need to keep away. Focus QT! What do you want? Do that well.

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

Re: Technical Vision for Qt 6

#58

Post by slavik81 »

blub wrote: post #30
ygra wrote: post #18

Earlier quoted context omitted.

Developer productivity when building or redesigning a UI is often far more important than raw performance. There's usually no noticeable difference for a user whether the dialog they opened via a button click is built in highly optimized C++ or from an XML resource stream that is read, parsed, and the UI constructed on the fly by effectively interpreting the UI description. It's okay to have expensive abstractions wh…

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.

Re: Technical Vision for Qt 6

#59

Post by halflings »

stabbles wrote: post #39
dkersten wrote: post #9

"Make JavaScript an optional feature of QML." and "Support compiling QML to efficient C++ and native code." Yes! These two things are what's been on the very top of my wishlist ever since QML/QtQuick was first released.

I would love this! In fact the QML format would not even be a terrible way to write non-UI applications, I'd think. Something like MySqlDataBase { id: default_db host: ... } UserController { items_per_page: 20 formatter: UserFormatter {} repository: Repository { table: "users" database: default_db } } is definitely more easier to follow than the linear version auto default_db = std::make_shared ("..."); auto userform…

It doesn't look as bad if you skip the intermediate variable declarations, since you're not re-using those variables elsewhere.

(the QML structure only works as long as this is the case, e.g clear nesting of instances)

Re: Technical Vision for Qt 6

#60

Post by halflings »

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