https://gitlab.com/eql/lqml/-/tree/master/examples/advanced-...
There's also performance issues with large amount of code, and last I checked, Qml doesn't really mix well with the traditional Qt widget and protocols (i.e. sometimes things are reimplemted in Qml under similar names, but with different behaviors)
What? Isn't HTML the daddy of declarative languages for UI ?
Not really. HTML is a way to create documents. It's closer to latex than QML. HTML + CSS + JS is used to create UIs, but it definitely does not match the capabilities of something like QML.
- CSS is used for styling, it is important but is not required.
Don't get me wrong, i think QML and XAML are cool and all, but HTML did this a long time ago.
What do you mean? Qt,WPF, Flex was doing UI with an XML syntax language before React existed, some people prefered doing things by hand instead of rag and drop back then too. The "components" were named Controls or Widgets and the Web still is a inferior pile of shit because in this old tooljits when you needed say a custom DataGrid widget you extended the existing one and where in Web you start from Zero with divs,inputs and buttons.
However, what's less excusable is thinking React components are somehow equivalent to XML: React components are a lot more than bits of JSX (components very often don't contain any JSX, it's an optional syntax extension, not a fundamental part).
There's very little in common between React components and the XML definitions used by Qt,
> UI with an XML syntax language
If you're interested in learning a bit about how React works, I'll start you off with this: React doesn't really do UI directly at all. It isn't layout-aware, layout is handled by the rendering target: e.g. DOM+CSS for the ReactDOM rendering lib, HTML+CSS for the ReactDOMServer rendering lib, UIKit for the RN iOS rendering lib, etc.
> I'm deeply familiar with React
I'm not trying to be snarky here but... React is not declarative.
Though it's good you highlighted that as that is essentially the fundamental difference here: WPF/QT are declarative, CSS is declarative, UIKit is (mostly?) declarative, HTML is declarative(-ish). React components aren't.
It's a far cry from an immediate mode API where you are making draw calls.
And it's not really representing UI: that's the main point here. Layout is decoupled; it's only really representing front-end logic and state.
I liked this about react, you create a render function and render your stuff. It is miles of head or the angular horrible architecture but the Web needs basic components implemented naively that developers can extend and not start every time from Zero with divs and other basic stuff.
To cut the explanation short, the former means while initial UI state was declarative (with XML), runtime mutations of UI were mostly imperative with a binding turing complete language.
The recent Component based model of composing UI - the runtime mutations of the elements are expressed as state updates inside the UI declarations itself(and declarations are usually done with a turing complete language)
is pretty much how Qt does it with QML (released in 2011), except that instead of requiring explicit function calls, the variables are themselves reactive so that:
Button { text: "foo" + counter.value }
Compos ability for me means I can make a big component by combining smaller ones, what does it mean to you?
Extensibility is the important part, you can get a DataGrid and add 10 lines of code to add some feature to it and you inherit everything from the base component, you get it all: the performance, the events, the accessibility. In web I only see shitty implementation that fail in different ways, even the YouTube search + dropdown input fails sometimes and remains open until you reload the page, a ton of Google "geniuses" can't implement a shitty component with all their languages and frameworks.
I personally like about react the functional part of it and not the JSX part, that is sugar syntax, though when doing complex stuff the functional part brke and you had no choice then get your hands dirty and find workarounds and do ugly stuff.
Most business work is still done with mice. Everybody thought fingered mobile would displace mouse-oriented UI's, but that was a bad prediction. Let's do open-source GUI's right this time. (Could QML be reworked to XML and made open-source?)
I doubt Chrome will stop using Skia, though Google can always do something akin to a fork or name-change that will break all existing apps.
Highly doubtful that will happen.
What "recent ideas" do you find in Jetpack Composer, Flutter and React Native that Qt lacks? These tools let you write apps with a nice user interface for Android exactly like Qt; supporting Kotlin, Dart, Javascript etc. besides C++ and various Qt language bindings is useful, but not necessarily superior.
why don't you consider NeXTSTEP from 1988 on to the present day in macOS UIKit?
1 is no longer an advantage since C++ is no longer a desirable language for UI engineers, largely because UI went from desktop to mobile and web which created an opportunity to disrupt the status quo
2 is no longer trendy either as functional programming becomes more popular. People realized they can be declarative in real programming languages and don't have to turn UI into a bunch of config files.
Actually I find this to be a serious pain point. Qt leans heavily on C++ features for core parts of its API (subclassing to create new widgets, for instance), and has its own C++ pre-processor. Getting to work in a different language in any capacity greater than "toy demo" is insanely hard - PyQt is probably the only success story here. I don't believe I have ever encountered a "real" program that uses Qt that was not written in C++ or Python.
2. You will need a big amount of hacks to make your project work on different platforms. Especially if you do something fancy.
Not to mention serious licencing issues.
>You will need a big amount of hacks to make your project work on different platforms. Especially if you do something fancy.
Having done Windows-Linux Qt, I haven't noticed needing "hacks" (unless you count the hacks necessary to build anything on Windows at all cuz the OS wasn't meant for programming ;p).
The fanciest thing I've done is theming (light, dark, etc.), which Qt doesn't seem to support natively, and which is difficult to do sanely without some "hacking".
>Not to mention serious licencing issues.
What issues? Is it just that it's LGPL, or what?
Light/dark theming should be easy with stylesheets.
On top of that, priorities are just different now. I spent an afternoon chasing down why QtCore has incomplete or missing methods for handling JSON documents (TLDR: "won't fix"), but I get a constant stream of marketing email promoting their new in-app advertising structure. And now there's a speech recognition engine?
I'm just done with it all. Guess I need to learn React.
Their bad licencing made sense back in the day. But they now face strong competition and instead of moving to a more open licence system, they seem to be doubling down. They don’t seem to understand that not only they aren’t the only framework in town anymore, they are currently worse than much better licenced systems.
As a Linux user, do tell me what the "native" solution is that I should be using! I love performance.
What does it feels like to spit random beliefs out of your hat and state them as truth? Native doesn't even mean anything, there really is something wrong going on on the mental models people have when talking about GUIs. IIRC QT use GDI+ on Windows for drawing 2D GUIs, which is mostly CPU based. And its shows in many tasks, see e.g. the strokePoly40 https://blend2d.com/performance.html Chromium use Skia and gecko use webrender, those are much much much faster on average. In fact the web has more FPS than native libraries in general.
1. Performance that matches native speeds
2. Single codebase for multiple platforms (without relying on web technologies)
3. Not limited with a single language (has bindings to all major languages)
4. The core is written in a performant language (C++)
But recent developments in UI programming is sidelining frameworks like Qt with some really good innovations.
- Like React/React-native ecosystem pioneered the component based declarations of UI elements.
- Flutter pushed it to all platforms with Skia as the rendering engine
- Jetpack Compose is pushing it with a better language (Kotlin)
- State management had matured a lot with redux style immutable stores
The irony is even with all these recent developments there isn't a single UI framework that took the best parts of older frameworks like Qt and combined it with the recent ideas from Flutter and Jetpack-compose!
If it did it all, the multi-platform support is handicapped. Either the native strategy becomes an afterthought or the Web becomes an afterthought, hurting accessibility, etc.
We still have a long way to go in cross-platform UI frameworks :)