[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