31–40 of 184 posts
“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'm looking forward to doing a comparison of Qt 6 and Electron in terms of both usability and performance.
Earlier quoted context omitted.
C++ (and even Rust) is not the best language to build UIs. Even if your app heavily uses C/C++ to do heavy computations, "scripting" language will be preferable for "glue code". QML is not a crazy new idea, for example Tk used Tcl. And due to C++ API, Qt has poor language bindings, compared to GTK and many others with C API.
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…
That may be true for Python, but the Common Lisp bindings for Qt4 were equally as "powerful" as the C++ bindings. It had higher level abstractions that generally made it easier to read and write, as well.
> Bindings are not C++'s problem
Actually, bindings are a problem with C++. Some features (like templates) and implementation details (like name mangling) make it very difficult to create bindings to C++.
And some widgets are simply missing or accessible through obscure ways (e.g. instead of QSplitter being in the Containers group in the widget box, it is only accessible by ctrl+clicking two controls under a parent container that has no layout and right clicking and selecting selecting Layout horizontally/vertically (two menus) - WTF, what is wrong with simply letting me drop QSplitter in the form and then place controls manually? I can already do that perfectly fine after i perform the magic incantation to bring it in - though of course i cannot change the splitter position from within the form editor, because that would be too convenient i suppose).
I've seen form designers from open source projects written by a single developer in their free time that are more polished than that. The only thing worse is writing those UIs by hand.
Earlier quoted context omitted.
C++ (and even Rust) is not the best language to build UIs. Even if your app heavily uses C/C++ to do heavy computations, "scripting" language will be preferable for "glue code". QML is not a crazy new idea, for example Tk used Tcl. And due to C++ API, Qt has poor language bindings, compared to GTK and many others with C API.
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'm looking forward to doing a comparison of Qt 6 and Electron in terms of both usability and performance.
If not for developer experience, why is electron ever used for anything?
Earlier quoted context omitted.
Uggh, yeah. I'm excited (well, as excited as I can be as someone who writes server/web software these days) about some of the stuff mentioned, but this is off-putting. It has no place in a GUI-focused framework in my opinion.
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.
Then again, its been ages that I had any use for Qt. Most of my work is backend or web and even mobile apps, which is something I would have considered Qt for in the past, I would now look into react native or PWA's.
"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.
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
}
}
auto default_db = std::make_shared("...");
auto userformatter = std::make_shared();
auto repository = std::make_shared("users", default_db);
auto controller = std::make_shared(20, userformatter, repository);
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.