On 20 December 2012 11:51, André Somers <[email protected]> wrote: > Op 20-12-2012 11:40, Shawn Rutledge schreef: >> On 19 December 2012 09:13, André Somers <[email protected]> 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. _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
