Op 12-12-2012 18:35, Stephen Kelly schreef: > On Wednesday, December 12, 2012 09:44:10 André Somers wrote: >> Op 11-12-2012 21:59, Alan Alpert schreef: >>> On Tue, Dec 11, 2012 at 10:49 AM, Shawn Rutledge >>> >>> <[email protected]> wrote: >>>> On Tue, Dec 11, 2012 at 09:48:22AM -0800, Alan Alpert wrote: >>>>> Why can't this be QML-only? 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. We don't >>>> Because it seems likely that the business logic of an application would >>>> be written in C++, so why not export the actions that the logic can >>>> support at the same time? >>> The way I see it, the actions are UI logic, not business logic, and >>> belong on the QML side of the divide (although they are right on the >>> edge). >> I disagree here. The core of the action - the abstraction of the action >> method itself and its availability in the current state - is business >> logic IMO. The same goes for any value the action may have: checked, or >> perhaps some other value. The action logically bundles state (the >> availability of an action) with the action itself. > Yes. I agree. The state-management parts of kontact actions is hundereds of > lines of (shared) code. > >> The decoration around it - the user visible strings, icons and whatnot - >> is indeed UI logic. > Yes. That stuff is also not UI-specific - not tied to either QML or widgets. There are commonalities, and perhaps they could be shared, but there are differences here. For instance, there are big differences in how one deals with images. In the widget world, a QIcon would be used, which itself is build from pixmaps. But in the QML world, you'd probably bind a URL property to an expression that checks the state (enabled, active, ...) and returns the right image URL for that case.
Also, the types of strings you need are not quite the same. QAction now has these texts: text, iconText, statusTip, toolTip and whatsThis. That is five different strings. I don't think they would all be needed in the QML context? Note that I think that binding a shortcut to an action is also a UI level concern. The only reason to have it on an action itself, instead of just connecting a QShortcut (or QML equivalent thereof) to the actions trigger() or toggle() slot, is that you often want to display the associated shortcut key on the menu item. At least, in the widget world you do. André _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
