First of all, I think I should to be more clear about what the "contexts" are supposed to mean. This is nowhere made explicit in ui-behaviour (nor is it really applied anywhere yet), BUT the intended use is the following:
A pair (name, context) specifies an action. So, actually, (name, context) is the real name of the action. The context is there so that:
1.) Potentially we can have a config shared across applications (respectively IJ plugins, e.g., Multiview Reconstruction and Trackmate are two "applications"). You might have common action names in both, e.g., "Delete Item" and it would be unnatural to name them "Delete Item/MVR" and "Delete Item/TM" just in case somebody else is out there...
2.) More important for the Mastodon use case: We have different views within the same application. Bdv and TrackScheme views both have a "Delete" action. Most probably for these actions its convenient to assign the same key stroke in the config. But actually they are two distinct actions "Delete/BDV" and "Delete/TS". In principle users might want to set different key strokes in Bdv and TrackScheme, or disable the action in one of them, etc.
The point is: We have a fixed set of actually existing actions. Each is specified by (name, context). In the visual editor, users can conveniently "group" actions by putting action name with several contexts, and assign the same key. But the actually existing set of actions should be reflected somehow.
Here are some ideas, but I haven't fully thought it through. But to get started:
[ ] Now you take a Map<String, String> commandDescriptions parameter, where the keys are the actions (names) available. It would be better to have (name, context) pairs as keys here to specify the available actions.
[ ] Then in the editor (most likely just do it after each edit): Make sure that all available actions are still present in the editor. If there was a name = "Delete", contexts = "Bdv, Ts" line, the user modified it by removing one of the contexts, leaving name = "Delete", contexts = "Bdv". Then you need to add an (empty?) name = "Delete", contexts = "Ts" line, so that we do not lose the "Delete/Ts" action.
[ ] When duplicating a line, copy the contexts from the duplicated line.
[ ] Possibly only allow to put contexts to an action name where the (name. context) pair exists. Other contexts added by the user could show up in red, as the unknown contexts do already now.
@tinevez
First of all, I think I should to be more clear about what the "contexts" are supposed to mean. This is nowhere made explicit in ui-behaviour (nor is it really applied anywhere yet), BUT the intended use is the following: A pair
(name, context)
specifies an action. So, actually,(name, context)
is the real name of the action. The context is there so that:1.) Potentially we can have a config shared across applications (respectively IJ plugins, e.g., Multiview Reconstruction and Trackmate are two "applications"). You might have common action names in both, e.g., "Delete Item" and it would be unnatural to name them "Delete Item/MVR" and "Delete Item/TM" just in case somebody else is out there... 2.) More important for the Mastodon use case: We have different views within the same application. Bdv and TrackScheme views both have a "Delete" action. Most probably for these actions its convenient to assign the same key stroke in the config. But actually they are two distinct actions "Delete/BDV" and "Delete/TS". In principle users might want to set different key strokes in Bdv and TrackScheme, or disable the action in one of them, etc.
The point is: We have a fixed set of actually existing actions. Each is specified by
(name, context)
. In the visual editor, users can conveniently "group" actions by putting action name with several contexts, and assign the same key. But the actually existing set of actions should be reflected somehow.Here are some ideas, but I haven't fully thought it through. But to get started:
Map<String, String> commandDescriptions
parameter, where the keys are the actions (names) available. It would be better to have(name, context)
pairs as keys here to specify the available actions.name = "Delete", contexts = "Bdv, Ts"
line, the user modified it by removing one of the contexts, leavingname = "Delete", contexts = "Bdv"
. Then you need to add an (empty?)name = "Delete", contexts = "Ts"
line, so that we do not lose the "Delete/Ts" action.(name. context)
pair exists. Other contexts added by the user could show up in red, as the unknown contexts do already now.