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

21–30 of 184 posts

Re: Technical Vision for Qt 6

#21

Post by kuschku »

dkersten wrote: post #15
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.

Uggh, yeah. I'm excited (well, as excited as I can be as someone who writes server/web software these days) about some of the stuff mentioned, but this is off-putting. It has no place in a GUI-focused framework in my opinion.

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.

Re: Technical Vision for Qt 6

#22

Post by dotancohen »

azhenley wrote: post #14

I'm looking forward to doing a comparison of Qt 6 and Electron in terms of both usability and performance.

What? That would just be a rant.

Electron apps generally have no accessibility consideration, and accessibility is often the cornerstone of usability. Especially for keyboard users.

Additionally, their performance is abysmal. Even the latest Slack update, which was focused on improving performance, see Slack using more CPU than my Java-based IDE (Jetbrains) sometimes.

Re: Technical Vision for Qt 6

#23

Post by smt88 »

kuschku wrote: post #21
dkersten wrote: post #15

Earlier quoted context omitted.

Uggh, yeah. I'm excited (well, as excited as I can be as someone who writes server/web software these days) about some of the stuff mentioned, but this is off-putting. It has no place in a GUI-focused framework in my opinion.

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.

Re: Technical Vision for Qt 6

#24

Post by danielscrubs »

kuschku wrote: post #21
dkersten wrote: post #15

Earlier quoted context omitted.

Uggh, yeah. I'm excited (well, as excited as I can be as someone who writes server/web software these days) about some of the stuff mentioned, but this is off-putting. It has no place in a GUI-focused framework in my opinion.

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.

And all the users hate it and just connects their mobiles instead. It’s like they ask each developer at the firm what they want to do instead of their customers.

Re: Technical Vision for Qt 6

#25

Post by qekbg »

ygra wrote: post #18
qekbg wrote: post #16

Earlier quoted context omitted.

>C++ (and even Rust) is not the best language to build UIs. Why? And why are scripting languages better?

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…

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

I dare you to compare the speed of UIs of Windows XP and Windows 10, even when using the hardware that was current when those OSes were released.

Re: Technical Vision for Qt 6

#26

Post by blub »

ungzd wrote: post #11
zerr wrote: post #5

I hope QML/js crap will be abandoned, and C++ API will be prioritized.

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 compared to regular programming languages, but that's unrelated to the claim you made.

Bindings are not C++'s problem, they're the problem of the other languages which try to use UI frameworks written in C++, like Rust, which still doesn't have any decent UI library.

Re: Technical Vision for Qt 6

#28

Post by Crinus »

danielscrubs wrote: post #24
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.

And all the users hate it and just connects their mobiles instead. It’s like they ask each developer at the firm what they want to do instead of their customers.

Ideally developers would ask their users so that information would roll towards Qt developers. In practice developers just ask for whatever shiny toys they want to play with.

Re: Technical Vision for Qt 6

#29

Post by jlarocco »

It's good to see language compatibility mentioned, and I hope they follow through with it.

There were really fantastic Common Lisp bindings for Qt4, but they relied on a tool called "Smoke", which stopped working with Qt5. My understanding is Smoke was used to create the early Python binding, but a different mechanism was used for the Python bindings in Qt5. For some reason the new technique wasn't as easy to use from other languages, so a lot of alternative language bindings stagnated on Qt4.

I don't know if it's improved lately, but between using C++, the non-standard moc pre-processor, qmake, and little support from Qt itself, it's really hard to generate bindings for Qt now.

Re: Technical Vision for Qt 6

#30

Post by blub »

ygra wrote: post #18
qekbg wrote: post #16

Earlier quoted context omitted.

>C++ (and even Rust) is not the best language to build UIs. Why? And why are scripting languages better?

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

Post reply on HN