[Development] QAction-like API for QML

[Alan Alpert]

On Tue, Dec 11, 2012 at 5:12 AM, Stephen Kelly <stephen.kelly at kdab.com> wrote:
>
> Hi Alan,
>
> Thanks for your initiative in pointing out what is still missing in
> QtQml/QtQuick.
>
> On Monday, December 10, 2012 19:39:36 Alan Alpert wrote:
>> Note that it has no-where near as many properties as QAction. toolTip
>> and whatsThis for example are very desktop centric so not needed
>> anymore.
>
> I think it's a mistake to assume that a new action API is not going to be
> useful on the desktop. I think it does need to be useful there. Additionally,
> a new action API should be useful in a hybrid QML2/Widget application, so
> please make that part of the design of the new API.

I agree it should be useful on desktop, my point was more about
whether we need to support the exact same style of UI as QWidgets.
Remember that QWidgets are done because they're already pretty damn
good at what they do. It's just that style of UI is falling out of
favor now. I don't see "What's this" becoming popular again in the
near future. Now this does strongly suggest that there's a place for a
hybrid QML2/Widget application and so I agree there should be some
plan for interoperability. But since that's not going to be QAction*,
and widgets won't stop using QAction*, the interoperability layer will
have to be above this new API and QAction* as an extra bridge. So
anything widget specific can be exposed in that bridge, it doesn't
have to be supported in the basic QML API.

> So, I think that the properties you don't include (toolTip, whatsThis,
> statusTip) *are* necessary. You also should consider accessibility in this new
> design.

The discussion so far has convinced me that Action should have an
enabled boolean (which the delegate might use to toggle visibility as
well) and a secondaryText string (which could be used as a tooltip on
desktops). whatsThis still seems too widget specific to me, did you
use that in Kontact Touch? Same with statusTip. Note that it would be
trivially easy to implement a desktop component set that used
secondaryText as the tooltop, whatsThis and statusTip. It would also
be easy enough to add those dynamically, like Shawn suggested, and
then your component set uses separate whatsThis and statusTip when
those properties are available on the Action.

As for accessibility, I believe that needs to be handled when writing
the menu delegates. At least that's what I get from reading
http://qt-project.org/wiki/Qt_Accessibility .

--
Alan Alpert