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

91–100 of 184 posts

Re: Technical Vision for Qt 6

#91

Post by v-yadli »

danielscrubs wrote: post #86
monocasa wrote: post #57

Earlier quoted context omitted.

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?

If they mean better python integration.. then YES

Re: Technical Vision for Qt 6

#93

Post by ahartmetz »

mort96 wrote: post #56
ahartmetz wrote: post #47

Earlier quoted context omitted.

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.

The order in which they were mentioned made Qt the lumbering wheelbarrow.

Re: Technical Vision for Qt 6

#94

Post by blub »

notathing wrote: post #75
blub wrote: post #71

Earlier quoted context omitted.

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.

The apps function correctly, it's the UI that is the problem.

It's modern looking, but obviously not native and doesn't respect some platform idioms or shortcuts, so all in all it's a subpar experience. This is completely related to Electron and would not happen for a native app, where the framework takes care of the look & feel and integration.

If every app were written like this, we'd end up with scores of slightly inconsistent apps, all of them trying to be unique and cool and resulting in a mediocre platform. i.e. Windows.

Re: Technical Vision for Qt 6

#96

Post by dkersten »

halflings wrote: post #59
stabbles wrote: post #39

Earlier quoted context omitted.

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)

> clear nesting of instances

You can have references (default_db in the example) to instances to have indirectly nested instances too.

Re: Technical Vision for Qt 6

#97

Post by _fbpt »

Crinus wrote: post #34

I hope they fix QtDesigner to not be hot garbage. Elementary operations such as trying to move some controls to a container that has zero size is totally unintuitive (you need to alt+drag to the container in the widget tree view - note that nothing else needs that) and not always possible (the widget tree view doesn't scroll so if the container is out of view you can't move stuff there - the fact that selecting somet…

I prefer writing UI by hand, rather than using Qt Designer. In C++, I figured out a few simple macros to automatically redefine `auto w` and `auto l` to refer to the parent widget and layout.

Is there a reason Qt Designer generates .cpp files which append a child to the parent after the child is fully fleshed out, rather than when the child is first constructed? Does the latter approach create too many relayouts, or did it do that in the past? I tried to replicate that design quirk in my code, and had to use RAII to "add child to parent at end of scope", even though I don't want the destructors to run if an exception occurs during UI layout.

Re: Technical Vision for Qt 6

#98

Post by jschwartzi »

tyfon wrote: post #52
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.

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.

It could also be Crank Storyboard. They're more tightly-focused on pushing pixels than Qt is and their framework is more focused on turning your Photoshop drawing of a UI into a UI but they skewed heavily into the Automotive realm.

Re: Technical Vision for Qt 6

#99

Post by jschwartzi »

pjmlp wrote: post #51
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…

They have the graphics layer written in C++, but get used from managed languages. QML, Swift, Android, UWP, WPF, Forms, Blueprints, Unity, React Native.

I've worked on two products with touchscreen UIs now and I can safely say this is exactly how I want to do things. Have a tight core engine but with a flexible declarative language that I can get imperative with. And make it easy for me to declare connections between the model and the view without specifying data types. And give me a way to work with a statically typed language when that's beneficial.

QML is way faster to develop in than C++. And it hides a lot of signal/slot boilerplate that doesn't matter. And I can still write C++ classes that interface with QML when I want.

Re: Technical Vision for Qt 6

#100

Post by kart23 »

Can someone please show me how to style a qt app relatively easily? I've built qt applications, and making some effort to make it look passable takes twice as much time as actual programming. QSS just sucks in making luxurious feeling interfaces, and this is where electron succeeds. Its much easier to make your own 'widgets' and have a great feeling application at the expense of ram and performance on electron. If Qt fixes styling, I would be onboard 100%. Performance is amazing and I like being able to develop one codebase for all operating systems.
Post reply on HN