[Development] QAction-like API for QML

[Andre Somers]

Op 12-12-2012 18:35, Stephen Kelly schreef:
> On Wednesday, December 12, 2012 09:44:10 André Somers 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.
> Yes. I agree. The state-management parts of kontact actions is hundereds of
> lines of (shared) code.
>
>> The decoration around it - the user visible strings, icons and whatnot -
>> is indeed UI logic.
> Yes. That stuff is also not UI-specific - not tied to either QML or widgets.
There are commonalities, and perhaps they could be shared, but there are 
differences here. For instance, there are big differences in how one 
deals with images. In the widget world, a QIcon would be used, which 
itself is build from pixmaps. But in the QML world, you'd probably bind 
a URL property to an expression that checks the state (enabled, active, 
...) and returns the right image URL for that case.

Also, the types of strings you need are not quite the same. QAction now 
has these texts: text, iconText, statusTip, toolTip and whatsThis. That 
is five different strings. I don't think they would all be needed in the 
QML context?

Note that I think that binding a shortcut to an action is also a UI 
level concern. The only reason to have it on an action itself, instead 
of just connecting a QShortcut (or QML equivalent thereof) to the 
actions trigger() or toggle() slot, is that you often want to display 
the associated shortcut key on the menu item. At least, in the widget 
world you do.

André