Would there be a chance of rust integration with these stronger types they mention?
I've been wondering, but how is Qt Rust integration actually doing at the moment?
I'm no UI designer/programmer, but it seems to me that Qt being apparently very dependant on C++'s object oriented concepts seems to make integration with Rust very difficult, since Rust very much does not follow's C++ concepts of objects and classes.
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.
Someone did a detailed study of UI responsiveness vs year.
Responsiveness peaked in the 80’s, in the dumb terminal + regional mainframe era. :-(
"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…
Yes! You can already do it, but you pay a lot of overhead in unneeded QObject/QQuickItem features that you don't need, so if they can improve that, and it sounds like they're working on it, then I think that would be fantastic.
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.
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.
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.