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

71–80 of 184 posts

Re: Technical Vision for Qt 6

#71

Post by blub »

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.

Popular doesn't mean good. In fact Electron is born out of the idea that developer productivity and comfort is everything and performance is a secondary concern.

These apps seem to be popular with device manufacturers. I have the displeasure of using two such apps, both have crap usability and custom UIs that don't make any effort to integrate with the platform. One of them doesn't even respond to the quit shortcut.

Re: Technical Vision for Qt 6

#72

Post by blub »

smt88 wrote: post #66
ahartmetz wrote: post #45

Earlier quoted context omitted.

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.

UI development is not a purely technical discipline, in fact it's very much shaped by design and user experience. To put it another way - if font rendering's poor or the UI's rendered at 15fps maybe one could blame the UI framework (although not always), otherwise it's on the programmers and designers.

Re: Technical Vision for Qt 6

#73

Post by leadingthenet »

hedora wrote: post #36
azhenley wrote: post #14

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

I think the suggestion here involves comparing the developer experience for the two. (QT would clearly win on all of the user experience and runtime performance metrics.) If not for developer experience, why is electron ever used for anything?

Because a vast number of mediocre JavaScript developers can suddenly easily port their mediocre web apps to the desktop, and because companies love the "only one codebase" idea.

There's no technical merit to Electron.

Re: Technical Vision for Qt 6

#74

Post by leadingthenet »

notathing wrote: post #69
jbarberu wrote: post #68

Earlier quoted context omitted.

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

> before Electron existed.

And what an amazing time that was.

Re: Technical Vision for Qt 6

#75

Post by notathing »

blub wrote: post #71
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.

Popular doesn't mean good. In fact Electron is born out of the idea that developer productivity and comfort is everything and performance is a secondary concern. These apps seem to be popular with device manufacturers. I have the displeasure of using two such apps, both have crap usability and custom UIs that don't make any effort to integrate with the platform. One of them doesn't even respond to the quit shortcut.

> These apps seem to be popular with device manufacturers.

All apps written by device manufacturers are crap, regardless of what they are written in. It has nothing to do with Electron, just with the fact that they only know how to do hardware, and are clueless on the software side.

Re: Technical Vision for Qt 6

#77

Post by ilikehurdles »

hedora wrote: post #36
azhenley wrote: post #14

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

I think the suggestion here involves comparing the developer experience for the two. (QT would clearly win on all of the user experience and runtime performance metrics.) If not for developer experience, why is electron ever used for anything?

If Qt would win on user experience, why isn't it doing so now?

This list[1] is out-dated (spotify uses electron, for example). But after skimming it I don't recognize any big software applications that have an exceptional user experience. Some, like Google Earth and Calibre are abysmal at best.

[1]: https://en.wikipedia.org/wiki/Category:Software_that_uses_Qt

Re: Technical Vision for Qt 6

#78

Post by blub »

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…

I'm not a scientist, so I did not measure it, however my empirical analysis suggests that this is indeed the case. Non-native UIs are noticeably slow. They don't have a monopoly on being slow, but they are slow across the board.

You might want to read this ode to fast software: https://craigmod.com/essays/fast_software.

Re: Technical Vision for Qt 6

#79

Post by [deleted] »

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…

[deleted]

Re: Technical Vision for Qt 6

#80

Post by sime2009 »

jlarocco wrote: post #29

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

Here's a quick history lesson. Long ago Smoke was created by one guy, Richard Dale, to do bindings for Ruby (QtRuby). Smoke was generic enough to be used for other languages like Lisp and also the .Net CLI. Language bindings other than Python didn't really catch on and the community needed to make it all viable and self sustaining didn't emerge. It was mostly one person's passion project and they didn't get any real help. So it died.

PyQt (Python) came from a small one man company in the UK called Riverbank Computing. It is mature and has been around for a long time. It used a custom tool called SIP for the bindings. Last time I checked it was still around.

In the Qt Nokia era, a team was assembled by Qt to create official Python bindings to compete with PyQt. IIRC they used Swig to do it. Then they lost funding for a few years before being revived in some form at which point they were busy moving to their own home grown binding generator.

Post reply on HN