[Development] QAction-like API for QML

[Stephen Kelly]

On Tuesday, December 11, 2012 09:48:22 you wrote:
> On Tue, Dec 11, 2012 at 6:07 AM, Stephen Kelly <stephen.kelly at kdab.com> 
wrote:
> > For comparison, you could look at what we did with QML1 based
> > kdepim-mobile.
> Great, thanks! It's always good to see how this can is handled in real
> applications. I just hope that we can make it 10x easier to write
> something like this in QML2 ;) .

Yes, agreed.

> 
> > ...
> > The actions are represented as strings. The mapping from string to action
> > is> 
> > via KActionCollection:
> >  http://api.kde.org/4.x-api/kdelibs-
> > 
> > apidocs/kdeui/html/classKActionCollection.html
> > 
> > This is necessary because an Action element with an id is not available in
> > a global scope, but a string can be used to access the actual action via
> > an exported object (with setContextProperty). You can't really expect
> > people to make sure that particular elements are accessible through their
> > QML element id. That might work for 'small/toy' applications or apps, but
> > not for large ones.
> 
> Perhaps then we just need to make item access easier, like with the
> proposed QML singleton API? 

I'm not certain that makes things easier. Do you mean using 
qmlRegisterSingletonType ?

> What if you had your ActionLists as QML
> singletons, or on a QML singleton, would that make it easier?

I'm not sure why it would?

> You'd be
> able to access it anywhere in your application with something like
> ActionCollection.home_menu.synchronize_all_items.

We also need to access it in C++.

Something I didn't point out before was that Kontact Touch is not a case of 
'hybrid application', but a case of 'shared codebase for multiple applications 
targetting different uis'. 

We have widget based KMail and QML based KMail Touch. They share 80-90% of the 
same codebase. They share the same action trigger handling, because the 
trigger handling can be complex. Also the state of the actions (is the 'delete 
this email' action enabled/visible based on whether we have selected an email 
or a folder for example) is managed in C++ and is shared between both 
application UI implementations. That is done in the StandardActionManager:

 http://quickgit.kde.org/?p=kdepimlibs.git&a=blob&f=akonadi%2Fstandardactionmanager.cpp

Creating these things in C++ in the 'shared codebase' use-case needs to be 
possible with the new API. Creating things in QML code often just doesn't cut 
it. 

Actions are not always 'UI logic' as you wrote somewhere, but they do get 
triggered by UI events. Sending an email is not a 'UI task' like 'cut text' 
is.

> If you had globally accessible ids and ActionGroups with an enabled
> property, would you still need the categories?

I can't say for certain. It's two years since I wrote that stuff :). But I do 
think it's something that needs to be considered as part of a design for new 
Action API.

> Would bindings on the
> enabled state suffice? something like enabled: { ["mainView",
> "composeView", "subComposeView"].contains(ApplicationState.currentView);}
> ?
> 
> > Another point is that some actions are 'standard', and may have a common
> > handling among many applications. In NoteActions.qml you'll see
> > ApplicationGeneralActions {} used. That defines the quit and configure
> 
> > actions, the about dialog etc:
> If there's a common Actions API, this is something that the platform
> components sets can provide. Including their common
> icon/string/secondaryText and such.

Perhaps, but they shouldn't be provided as QML elements in QML files. Doing 
that could lock out the 'common codebase' and 'hybrid application' scenarios, 
right?

> 
> > ...
> > 
> > So, in summary, I think your proposal needs more work. I think the
> > use-cases of hybrid applications, the use-cases of multiple applications
> > with some common stuff, and the use-cases of large applications need to
> > be satisfied by any new 'action API'.
> 
> There is always a conflict between "done" and "released". If we want
> to get an Action API into 5.1 so that QtQuick Controls can use it,
> then we need to start small.

Then aim for 5.2 and do it right instead :).

> This means that all these usecases should
> be considered future tasks and not in the initial implementation. 

What is in the initial implementation indeed does not need to be complete. 

The design, intentions, scope of use, reasons for the API and planned 
extensions should be though.

> That
> doesn't mean we can't think about it and discuss it, we'd like the
> design to be future proof, but we also can't let those discussions
> prevent getting something out for the key usecase of QtQuick Controls
> applications.

I'm not sure I agree. 

> 
> > We also need to find out whether we can come up with something which
> > QtWidgets users can migrate to (the QWidget* in the QAction API is quite
> > niche, and not necessarily ideal API anyway). Possibly even investigating
> > whether QAction can be implemented in terms of a new QGuiAction (?) API
> > should be done. This can't be QML-only. There needs to be C++ backing
> > too.
> 
> Why can't this be QML-only?

Because it locks out 'common codebase' and 'hybrid application' scenarios as 
far as I can tell.

We were able to share the action code between kmail and kmail touch because it 
was based on QAction.

> 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.

You really need to consider cross-overs as part of this design.

> We don't
> currently have a C++ UI something which QtWidget users can migrate to,
> we'd need to consider that first before trying to make this new API
> fit in with whatever that would be.

Yes, exactly :). That's what you need to consider. Now, not later.

> 
> I agree there should be a migration path for existing QAction users,
> and that we should support hybrid applications. But there are other
> ways to support those use cases than adding a C++ API for the new
> Actions. My initial thought is something like a QActionBridge which
> can take a QAction or a QML Action to start with and then generates
> the other on the fly. It's not pretty, but it's a lot easier than
> abstracting out a QGuiAction and still allows you to get a reference
> to the other type if you need the interoperability.

I'm not so sure about that. Can you say what is so hard about it?

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/20121212/a449ee83/attachment.sig>