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

61–70 of 184 posts

Re: Technical Vision for Qt 6

#61

Post by ptx »

protomyth wrote: post #35
blub wrote: post #26

Earlier quoted context omitted.

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…

I keep coming back to the differences between OPENSTEP and Taligent and believe C++ isn't the best choice.

What were some of the differences? (Other than Taligent dying and OPENSTEP surviving via Mac OS X, which is all I know about the topic.)

Re: Technical Vision for Qt 6

#62

Post by ajconway »

dotancohen wrote: post #22
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.

One would think that a browser-based app should excel in terms of accessibility, because it's practically built into the engine.

Re: Technical Vision for Qt 6

#64

Post by rat9988 »

pjmlp wrote: post #43
azhenley wrote: post #14

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

Easy just watch React Native for Windows talk at Microsoft BUILD 2019. Electron has 700% performance lost over UWP/C++, which is the baseline. Expect similar results when comparing against Qt.

I had to search for the video, but I guess you are talking about this?

https://youtu.be/TZnajQqqKV8?t=2894

Re: Technical Vision for Qt 6

#65

Post by Const-me »

pjmlp wrote: post #49
zerr wrote: post #5

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

For better or worse, pure C++ APIs have lost the war on GUI frameworks. Microsoft is the only consumer OS vendor that still supports C++ for doing full stack GUI apps, everyone else moved into a mix of C++ plus managed language or layout DSL.

> Microsoft is the only consumer OS vendor that still supports C++ for doing full stack GUI apps

On modern Windows you have C++, and also layout DSL, specifically XAML. And that C++ is not particularly idiomatic, it’s IUnknown-derived interfaces.

If you mean windows desktop, WinAPI uses quite a few DSLs. Dialog and menu resources are the most obvious, but there’s more: WMF/EMF vector graphics format, ribbon markup XML for ribbon control, theme files…

Re: Technical Vision for Qt 6

#66

Post by smt88 »

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.

By that reasoning, no one should criticize Electron because VS Code (and a few others) have managed to make it performant.

My comment was partly tongue-in-cheek, but the kernel of truth in it is this: a good UI tool makes it easy to build what you want without sacrificing speed, not hard.

Electron makes it incredibly hard (though still possible). I'd be interested to know how much better of a balance Qt strikes.

Re: Technical Vision for Qt 6

#67

Post by rat9988 »

coldtea wrote: post #54
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…

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

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

This remark should (also) have been directed at his parent comment, who made the contrary claim without any measurement either.

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

The numbers?

Re: Technical Vision for Qt 6

#69

Post by notathing »

jbarberu wrote: post #68
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.

Autodesk Maya 2019 is one pretty good example off the top of my head

Maya uses Qt since 2010, before Electron existed.

https://www.youtube.com/watch?v=7zWlwdr7exo

Re: Technical Vision for Qt 6

#70

Post by 4ad »

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.

Are you kidding me, bazel is written in Java...
Post reply on HN