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

81–90 of 184 posts

Re: Technical Vision for Qt 6

#81

Post by ilikehurdles »

leadingthenet wrote: post #73
hedora wrote: post #36

Earlier quoted context omitted.

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.

The native desktop application has been replaced for all but the most complex and inertia-driven established behemoths. Was there technical merit in moving desktop applications to the browser in the first place throughout the 2000s? In most cases: no. All of the functionality of the web interfaces could have been written as more performant native desktop analogues, but it's 2019 now and starting on the web is the defacto default while making a desktop application is the exception.

Re: Technical Vision for Qt 6

#83

Post by afiori »

leadingthenet wrote: post #73
hedora wrote: post #36

Earlier quoted context omitted.

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.

Being mediocre has nothing to do with it.

Also portability from a popular platform is a technical merit.

That Qt is better on its own is also a merit, but not the only one.

Re: Technical Vision for Qt 6

#84

Post by badsectoracula »

hedora wrote: post #42
qekbg wrote: post #25

Earlier quoted context omitted.

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

Someone did a detailed study of UI responsiveness vs year. Responsiveness peaked in the 80’s, in the dumb terminal + regional mainframe era. :-(

Do you have a link? If it is the one i remember it was about keyboard-to-output responsiveness (and the winner was something like a C64 or Apple 2 or something like that), not overall UI (and i'm a bit skeptical about the dumb terminal part considering the communication latencies involved, especially in the 80s).

Re: Technical Vision for Qt 6

#86

Post by danielscrubs »

monocasa wrote: post #57
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 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?

Re: Technical Vision for Qt 6

#87

Post by sgt »

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.

Also, Tesla's dashboard user interface is apparently built on Qt. I honestly would not feel safe in a car built around Electron, even if it's just the UI.

Re: Technical Vision for Qt 6

#89

Post by happyweasel »

azhenley wrote: post #14

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

Evolus Pencil is a cool desktop app for creating wireframes (open source). It really offers great functionality.. it's now based on Electron (was based on Mozilla XULRunner)

... Performance is terrible on a quad-core i5 notebook with 16gb of ram and a gtx 1060 graphics card... I am talking about dragging the first element on an empty canvas and resizing it.

Hopefully Electron will improve - more choices are always nice.

But then again, Electron is based on Chromium and Node.js, both are "C++-based". Improvements in those C++ codebases and improvements in C++ compilers will probably also lead to better performance in Electron itself.

Re: Technical Vision for Qt 6

#90

Post by nerdponx »

azinman2 wrote: post #31
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.

Ya I read the AI think and I was like hmmm... I guess the editor thought there wasn’t enough buzzwords in the article. I’d love to see what this “easy integration” between “AI” and a GUI framework looks like.

AI is the "mobile" of 2019.
Post reply on HN