Priority: Not Evaluated
Affects Version/s: 5.15.0, 6.0.0
Fix Version/s: None
Component/s: Quick: Core Declarative QML
I really love the QML language and QtQuick, it's really easy to create custom views and controls with custom styling, and really convenient for creating a good UI experience.
But as an advance QML/QtQuick user I have some frustrations that I think could be really easy to fix and that would definitivelly be a game changer for Qt:
Enhanced C++ API for QtQuick:
This is probably the most frustrating ones, but a lot of basic QtQuick components are private and made really difficult to integrate or create new powerfull and optimized controls.
For example I recently tryed to implements a masonry like view (https://masonry.desandro.com/), but without subclassing Flickable from C++ it's either a mess to implements or a performance issue. It would be really nice and powerfull that Flickable (QQuickFlickable) become a public API in QtQuick c++ module. Since it would prevent us to links again Qt private API.
There is a non-exaustive list of other items I really would love to become C++ available in such manner:
- Flickable (For the reason explained above)
- Text (As it would be convenient to create it from C++)
- Transition (Would be a tricky one maybe, but will allow us to create custom transition for our custom view, will probably need some other API to manipulate it).
- Control (As it would allow us to implements a custom control and tacking advantages of all existings features of controls)
This could be a start and the following ones may be a plus:
- Some Control generic classes, like AbstractButton or Container.
- ApplicationWindow, Popup and Dialog.
I would be nice to have some kind of binding references available in the core language, like in SwiftUI for example.
For now to create a proper bidirectionnal binding we have to make something like this:
It would be really convenient to have something like this:
Or any kind of symbol (Swift use $) or even a global function.
So the text propery could be like a BindingReference<QString> and the & operator could return a BindingReference<QString> instead of a binding to a QString.
A BindingReference<QString> will allow the control to send back a value to the model.
Of course the original synthax should still work, for special cases, so a BindingReference<QString> could accept a simple QString binding. In that case sending back a value from the control will send a warning. The BindingReference<T> should have some kind of canWrite property to prevents the warning.
This is a start, but these two suggestions will be I think a real game changing.