Details
-
Suggestion
-
Resolution: Unresolved
-
Not Evaluated
-
None
-
5.15.0, 6.0.0
-
None
Description
Hi,
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.
Binding reference
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:
TextField { text: myDataModel.someTextProperty onEditingFinished: myDataModel.someTextProperty = text }
It would be really convenient to have something like this:
TextField { text: &myDataModel.someTextProperty }
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.
Attachments
Issue Links
- duplicates
-
QTBUG-57549 QtQuick missing important item positioner
- Reported