[Development] QAction-like API for QML

[Alan Alpert]

On Wed, Dec 12, 2012 at 12:44 AM, André Somers <andre at familiesomers.nl> wrote:
> Op 11-12-2012 21:59, Alan Alpert schreef:
>> On Tue, Dec 11, 2012 at 10:49 AM, Shawn Rutledge
>> <shawn.rutledge at digia.com> wrote:
>>> On Tue, Dec 11, 2012 at 09:48:22AM -0800, Alan Alpert wrote:
>>>> Why can't this be QML-only? For the set of controls exposed in
>>>> C++-only we have a C++-only Action API. When we add a set of controls
>>>> exposed in QML-only we can have a QML-only Action API. We don't
>>> Because it seems likely that the business logic of an application would
>>> be written in C++, so why not export the actions that the logic can
>>> support at the same time?
>> The way I see it, the actions are UI logic, not business logic, and
>> belong on the QML side of the divide (although they are right on the
>> edge).
> I disagree here. The core of the action - the abstraction of the action
> method itself and its availability in the current state - is business
> logic IMO. The same goes for any value the action may have: checked, or
> perhaps some other value. The action logically bundles state (the
> availability of an action) with the action itself.
>
> The decoration around it - the user visible strings, icons and whatnot -
> is indeed UI logic. That's why I think that perhaps we conceptually need
> something like a CoreAction and a UiAction. The UiAction would
> 'decorate' a CoreAction with the stuff that is needed to represent it in
> a UI. The implementation of the UiAction part would be different for QML
> and Widgets, I think.
>
> Actions are a very powerful piece of glue between business and UI logic
> if used this way.
>

Okay, I think this cuts to the heart of the disagreement. QML is
designed for the 'common codebase' scenario Stephen is talking about,
but this requires a very good split between UI logic and business
logic. The actual business logic that's true no matter the
representation can go in C++, and the UI logic which is dependent on
how it's presented (like on Widgets, with QtQuick, touchscreen etc)
has a different implementation per UI but sharing the business code.

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
}

CoreAction may not even need a QML API. QML users either implicitly
use one through UIAction, or explicitly use one from C++.
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.

Does this API solve the hybrid problems the previous one was having?
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.


--
Alan Alpert