Encapsulating commands as 'actions' #380
Replies: 11 comments 8 replies
-
|
Very bad code example, but something like... // defining the application
auto copyAction = my_app.defineAction("Copy");
copyAction->bind_short_cut("ctrl-C");
my_menu.add_action("Edit/Copy", copyAction);
// elsewhere
myWidget->subscribe_to_action(copyAction, [=]() {myWidget->copy_to_clipboard();} |
Beta Was this translation helpful? Give feedback.
-
|
You can also automate things like dimming menu items if the currently focused item does not accept the action. You can also have global actions as well, that don't need a focused element to be triggered (eg: quit). |
Beta Was this translation helpful? Give feedback.
-
|
I think this can be done using the new model API (just implemented recently). There can be an app model that elements can subscribe too. It's a generic/modern c++ twist to the 'event-bus' or 'signal slots'. There's an example with lots of comments. |
Beta Was this translation helpful? Give feedback.
-
|
I'll have a look |
Beta Was this translation helpful? Give feedback.
-
|
The model is a nice way to decouple state from the UI code, but it doesn't solve the problem of widget implementors having to reimplement code to handle commands, nor of making sure seperate command triggers carry out the same actions. For example, I'm currently writing a complex element that needs to take cut/copy/paste commands. To do that, I have to re-implement all the key handling found in text.cpp, with all the associated problems of code duplication. Actions allow seperate UI types to behave uniformly and allow for richer behaviour. |
Beta Was this translation helpful? Give feedback.
-
Sure, I get your point. But it's just a matter of protocol. Say we have a generic app_model that is used as a starting point where such cut/copy/paste commands are available as a starting point, and probably some more such as quit, etc. Then, we can use this as a common hook into elements, including |
Beta Was this translation helpful? Give feedback.
-
|
I'd argue that the model and commands are different things. The model represents the state of the application to the UI, so is a set of nouns. Commands are the verbs of the system which can operate on different things. Some of those verbs may affect state (eg: "paste in the element that has focus") some of those verbs may only affect the interface (eg: "hide window"). They are different catogories and need different abstractions. |
Beta Was this translation helpful? Give feedback.
-
|
Take note too that the philosophy behind |
Beta Was this translation helpful? Give feedback.
-
|
It's a grey area as to what is a framework and what is a library. Modern C++ can do away with alot of the bloat from Qt as most of it has been brought into the core language. But even the simplest UI library needs to handle user interaction. The 'paste' command could be triggered by a range of user interactions, for example 'cmd-V', it can also be triggered by clicking on a menu item. An element that wants to recieve the paste action shouldn't care or be in control of how the paste command was triggered. Some commands could even be triggered by other commands executing. Having a way to abstract commands decouples an element from the implementation of the command, which makes it much more flexible. Having to inherit from 'paste_reciever' and implement a virtual is alot of pain, as would having to call 'is_pasted_key' inside key. All of the above is alot more pain that a subscription to the 'paste' command. |
Beta Was this translation helpful? Give feedback.
-
I'd argue that that is incorrect (or at least incomplete). The Model represents the underlying data (state) and the logic that operates on that data (actions) at a high level, and decoupled from the UI view. The clipboard, for example, can be part of the model and so is the logic (actions) that operate on the clipboard such as cut/copy and paste. |
Beta Was this translation helpful? Give feedback.
-
|
What about 'select all', that's doesn't affect application state, but is still a command that affects the UI? |
Beta Was this translation helpful? Give feedback.
-
|
Sure, the paste buffer could be part of the application state, but it still needs to be operated on. |
Beta Was this translation helpful? Give feedback.
-
It affects the selection, the type of which is application-specific, but can be abstracted out. For example, in a recent project I worked on, the selection is a sub-range of items in a list.
Exactly, and the operation is the business logic. |
Beta Was this translation helpful? Give feedback.
-
|
And chunks of the business logic can be encapsulated out from each individual element via commands. |
Beta Was this translation helpful? Give feedback.
-
This is all a matter of design, can you agree? The model is already an abstraction and encapsulation that can handle what you call "commands". I see no reason to add another abstraction. State cannot exist alone without the business logic surrounding it. I'd even argue that there can exist a purely functional stateless model (e.g. one that is based purely on functions). |
Beta Was this translation helpful? Give feedback.
-
|
I think you are conflating two logically different elements of a user interface. What you see, which is mostly represntation of application state, and what you do to it. So how does one write an element that wants to respond to a cut/copy/paste/select all commands when it has focus, whether that command is triggered via a menu item or keyboard short cut. Similarly for all other command? Currently I have do do that in |
Beta Was this translation helpful? Give feedback.
-
I don't think so. There's the MVC and also the MVP design patterns in GUI design (Model-View-Controller, and Model-View-Presenter, respectively). I've worked on both designs, but I lean towards MVP. In both design patterns, IMO, the Model is the central abstraction. Commands? Nada. The closest is perhaps the implementation of the controller in the MVC design, like the event bus or the signal/slot. But that is not a key player and does not exist in MVP. Those are simply implementation aspects.
If you are willing to move towards a more constructive and productive discussion, instead of pushing me to accept other UI toolkit design, I can present and discuss various ways. |
Beta Was this translation helpful? Give feedback.
-
|
Appologies for pushing to hard. How do you think one should go about encapsulating that kind of behaviour so that a developer does not have to reimplement ctrl-C/V/X for each element they create while also responding to the menu comands that do the equivalent? Similarly for other common interactions, eg: find, find/replace, delete and so on? |
Beta Was this translation helpful? Give feedback.
-
Those are splendid questions. And you are right in thinking that these should be implemented once. I'll share some ideas later... BTW, if you want real-time discussions, I suggest continuing over discord channel to flesh out details. |
Beta Was this translation helpful? Give feedback.
-
Many toolkits encapsulate commands that can be triggered by multiple means as 'actions'. For example the ‘copy’ command can be triggered by 'ctrl-C’ or by choosing the ‘copy’ item from a menu. Currently implementors of a new element have to recreate all the copy/paste etc.. logic, as well as dealing with menus. If commands were encapsulated as actions, elements simply subscribe to an action. An action can be triggered by a menu, a keyboard shortcut or even another element. When an element has focus and an action is triggered, the focused element receives notification of the action via a signal/slot, virtual or callback mechanism. Custom actions can also be defined and subscribed to by application and element developers.
Beta Was this translation helpful? Give feedback.
All reactions