[Development] Integrating QAction and the upcoming QML Action (was QAction-like API for QML)

[Alan Alpert]

Summary of the topic so far:

Existing and future Applications have a need for managing actions in
C++, and these need to be the same actions as QML is dealing with. How
do we implement this?

Here are the four options I recall being suggested so far,

A) QQuickAction is added to create the QML API, properties match
QAction where possible and all property access goes through the
meta-object system to make the type 'meta-isomorphic'

B) QAction is moved to Gui and is used to create the QML API.

C) QGuiAction is added to Gui and is used to create the QML API and
the bridge with QActions.

D) QCoreAction is added to Core or Gui and has even less
functionality, QQuickAction and QAction/QGuiAction build on top of
that to fill out their API.

Are there other options we can consider?

My favorite of those is C), but there is the unresolved question of
how to make an effective bridge given that we can no longer make
QAction inherit from QGuiAction.

On Tue, Dec 18, 2012 at 5:11 AM, Olivier Goffart <olivier at woboq.com> wrote:
> On Tuesday 18 December 2012 13:33:59 Robin Burchell wrote:
>> On Tue, Dec 18, 2012 at 12:55 PM, Stephen Kelly <stephen.kelly at kdab.com>
> wrote:
>> >> The details of the split
>> >> was just following Andre's suggestion. text/secondaryText might fit
>> >> into CoreAction, icon will not.
>> >
>> > Why not? Because QML doesn't do QIcons? The reason for that is not clear
>> > either to me.
>>
>> I don't think there's any reason it couldn't. A QIcon is a QPixmap,
>> after all, and QIcon lives in QtGui, so there's no dependency issue
>> either.

It's already in Gui? Good, then it's just the Widget* properties that
are preventing the move (and I'm not saying that's an insurmountable
obstacle).

--
Alan Alpert