[Development] QAction-like API for QML

[Shawn Rutledge]

On 20 December 2012 11:51, André Somers <andre at familiesomers.nl> wrote:
> Op 20-12-2012 11:40, Shawn Rutledge schreef:
>> On 19 December 2012 09:13, André Somers <andre at familiesomers.nl> wrote:
>>> 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.
>> Do you have some compelling, concrete examples of what you would use
>> it for?  I agree with Alan and Jens, there's no point in adding
>> clutter to Core unless it's really so useful that other things besides
>> the new action class need to be based upon it.
> Yes. I have been in a very real situation in a company where there was a
> very strict policy of *not* being allowed to use GUI libs from inside
> the core libraries. It resulted in a lot of hard to maintain, bridge
> code where being able to use a non-gui action from the core would have
> been quite simple. And yes, you can argue that that policy is wrong and
> misguided, but the fact of the matter is that it exists in real places
> where Qt is used. And frankly, I agree with the gist of it: it makes no
> sense to introduce GUI concepts into core libraries of an application.
> Icons, shortcuts and whatnot don't have a legitimate place there. But
> the idea of a QCoreAction/QTrigger or whatever you want to call it makes
> perfect sense for the API interface of a core library with a GUI
> library. At least, it does to me.

So ultimately at that company all the abstract actions you would have
wanted to create would still have to be converted into gui-oriented
actions anyway, right?  How would you avoid writing code to bridge or
augment them into actions which can be realized in the gui?  Or did
you have completely non-gui use cases?  Anyway maybe at such
companies, the non-gui action class would tend to have other
properties which we cannot predict in advance.