[Development] QAction-like API for QML
Stephen Kelly
stephen.kelly at kdab.com
Thu Dec 13 17:18:31 CET 2012
On Wednesday, December 12, 2012 11:41:27 Alan Alpert wrote:
> The original Action API I proposed was approaching it as a UI logic
> element. Let's see what we come up with when we split it into UI and
> business elements
>
> CoreAction://Names are for illustrative purposes only
> QtObject { //Prototyped in QML, probably a C++ class that QAction
> could migrate to using later
> property bool checkable: false
> property bool checked: false
> property bool enabled: true
> signal triggered(bool checked)
> }
>
> UIAction://Illustrative purposes ONLY!
> QtObject {
> property string text
> property string secondaryText
> property url imageSource
> property string shortcut
> property alias checkable: core.checkable
> property alias checked: core.checked
> property alias enabled: core.enabled
> signal alias triggered: core.triggered //not valid QML, but you get the
> idea property CoreAction core: CoreAction{} //implicity gets one but you
> could also set one manually
> }
The use of QML to suggest C++ APIs is confusing, because we are talking about
both QML and C++ APIs in these emails. Please prototype your proposals for C++
APIs in (pseudo)C++.
The reason for the split is not clear to me. Do you suggest that UIAction
would be a QML element, not a creatable C++ class? Do you suggest that
CoreAction would be a creatable C++ class? Why does it not have a text?
> CoreAction may not even need a QML API. QML users either implicitly
> use one through UIAction, or explicitly use one from C++.
I think the goal should be not to have such a split at all.
Presumably you suggest that UIAction is not a visible element, but its
properties need to be bound to Text {} elsewhere?
Rectangle {
UIAction {
id : uiAction
action : _cpp_exported_action
}
Text {
text : uiAction.text
}
MouseArea {
onClicked : uiAction.trigger()
}
}
Why not just this:
Rectangle {
property QtObject action :
_cpp_exported_action_manager.get("_cpp_exported_action")
Text {
text : action.text
}
MouseArea {
onClicked : action.trigger()
}
}
> Theoretically a new QAction could be written to use CoreAction
> internally too, and then a QAction and a UIAction could share the same
> CoreAction instance.
If CoreAction and UIAction are merged (as QGuiAction for example), then
QAction can the implemented in terms of that too.
>
> Does this API solve the hybrid problems the previous one was having?
How does my counter proposal sound?
> QML-only users ignore the core property and it works exactly like the
> Action API we started with, but the CoreAction can be shared between
> multiple UIs for the other usecases. For example, you could even do
> UIAction { core:
> GlobalActionManager.getAction("akonadi_collection_create"); } to
> interface with your existing ActionManager approach.
I wouldn't like a singleton for the action manager because singletons
discourage modularity.
Thanks,
--
Stephen Kelly <stephen.kelly at kdab.com> | Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20121213/ba0a45ca/attachment.sig>
More information about the Development
mailing list