>> I find the idea of adding a new QCoreAction base class that is shared
>> between QML Action and QAction and only carries a small subset of properties
>> an unnecessary layer of abstraction. The idea of QAction is to have the
>> convenience of icons, text and shortcuts predefined for you in a shared
>> location. If you remove most of those properties, you anyway have to
>> redefine the shortcuts and icon every time you use them and quite frankly I
>> see no added benefit of this core action class that I cannot cover by simply
>> having a shared signal that my MenuItem connects to.
> Well, I disagree with that view of what an action represents. To me, the
> core of an action really is bundling a bit of state with a trigger for
> something to happen (I try to avoid the word 'action' here) in a
> convenient API. That piece of state includes at minimum if that action
> is available right now, and can also contain a value ('checked' is the
> value that QAction can currently carry, so basically a boolean). That by
> itself is already a very useful thing to have, as it provides a very
> nice and clean way to expose functions on an API, especially for code in
> a core layer of the application.
Action has clear semantics in Qt. It is a GUI concept to describe properties
that belong in a specific implementation of a UI. What you are proposing should
not be called CoreAction as it has nothing todo with QAction. You are proposing
a new concept to Qt. I still find it redundant since it is trivial to implement
yourself, but if your backend needs a signal that can be disabled I would
suggest that we introduce it as a different class called QTrigger and keep it
outside of this discussion.
If you have doubts that Action is a GUI concept, take a look at the properties:
autoRepeat, checkable, checked, enabled, font, icon, iconText,
iconVisibleInMenu, menuRole, priority, shortcut, shortcutContext, softKeyRole,
statusTip, text, toolTip, visible, whatsThis. How many of those belong in a
backend? How many can you reuse in both mobile and desktop UI's?
> You claim that you'd have to "redefine" the shortcuts and other GUI
> related properties every time you use the (core) action. Why so? Your
> GUI layer can simply get these core actions and re-expose them once,
> right? At the moment, you frequently see methods that are responsible
> for creating all the actions in the application. You'd have the same,
> only instead of having to manage multiple connections to keep track of
> state in the core and the action that represents that, you set a
> coreAction on the action and have that part taken care of. Then, you set
> the QAction you created on your toolbar, your menu and whatever else you
> fancy.
So you redeclare your Actions in your fronted and somehow associate them with
CoreAction?
QGuiAction openAction(Core::openCoreAction):
openAction.setShortcut();
openAction.setIcon()
openAction.setToolTip, setEtc…
Again, I gain nothing from this apart from having to declare all my actions
twice. Though if the concept is worth implementing we can alway add a
setTrigger function to QGuiAction in the future.
> The benefit is in the way that you bundle the relevant bit of state, a
> handle to an action and a value into one convenient abstraction. Instead
> of having to expose and connect to these separately to keep your GUI
> consistent with application state, you only need to reference a single
> object. And that single object can be used both in the widget world as
> well as in the QML world. At the same time, if you like.
>> What I would propose is that we keep the QAction exactly as it is and make
>> it possible to use it from QML as well as introduce a new slightly
>> simplified QML Action component as previously suggested. The only drawback
>> to this approach is that actions you declare in QML won't be immediately
>> usable from C++, but I don't see this as a big issue. You will either keep
>> everything in QML or have your business logic including your QActions
>> defined in in C++.
> As mentioned by others, this would mean that any C++ core that you write
> would *have* to pull in QtWidgets in order to be able to use actions.
> Even if you only have a QML gui. Not very attractive, if you ask me.
No it does not. QtWidgets is in a separate library. We will put the new C++
class in QtGui and expose it to QtQuick. This would then be just as available
to widgets as it is in QtQuick. But I am not a sure how much effort we should
use to make it usable in widgets. I would like it to be optimised for QtQuick.
QAction already works great for widgets. Making QQuick also support QAction
seems more important to existing users.
Jens
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
