Tirsdag 11. desember 2012 09.25.37 skrev Alan Alpert: > On Tue, Dec 11, 2012 at 5:12 AM, Stephen Kelly <[email protected]> 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 > [email protected] > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
