[Development] QAction-like API for QML

[Frederik Gladhorn]

Tirsdag 11. desember 2012 09.25.37 skrev 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.

I agree, enabled seems sensible. And I'm personally in favor of dropping 
whatsThis since there was never enough uptake of it to justify it. It could be 
added later if there is a big demand for it. In most of the code I have seen 
there is something like tooltip = statustip = whatsthis = "Some text". If we 
just decide on one secondary text, could that be enough, or is there a need to 
discern status bar from tooltip?

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

The secondary text is much appreciated from and accessibility POV.
Actually all accessible objects tend to have some form of concise text (text 
in this case) and a more verbose description - usually called description.
Exposing that information may depend on where the action is used, but it 
should still be defined together with the text property.
Making this a dynamic property would mean it doesn't show up in the auto 
completion and is generally likely to be ignored. I would strongly favor 
having description (or whatever name is agreed on) as real property.

Another idea that floated around was the creation of an action collection - 
similar to what KDE has today. That can be done behind the scenes and even be 
added later. The idea is to have a list of all actions in one place. That's 
great for things such as configuring all shortcuts of an application in one 
place.

Greetings
Frederik

> 
> --
> Alan Alpert
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development