Location of action limiting
For background on the question, see https://musescore.org/en/node/271987
So, for my GSoC project, i need to include action limiting. Currently, I am going to develop a simple list of possible actions that the user can select/deselect. However, I need a place for the user to goto to see this list. I was wondering where a good place to put it would be.
1. It's own menu bar item. This is excessive IMO because its not that big of a feature.
2. Within an existing menu bar item. I like this idea as it doesn't hide the feature. However, I am not sure where to put it. (maybe Tools?)
3. Within an existing popup window (like preference, but not specifically that). I feel this hides it too much, but if that is the desire, then its okay.
Let me know what you think.
P.S. This is easy to change later on, just wanted to ask early :)
Comments
I think putting anything related to this under the tools menu would hide it too much. I would put it prominently in the Help menu.
Since it is experimental feature and is not completed until the end of the coding period, I would put the UI staff under some special dev option or if it is more suitable, to the shortcut list with some hotkey, but don't put it to the main MuseScore UI.
IMHO, The UI is the last thing you can do within the last week of your work.
I agree with Anatoly, the UI is the least important thing right now.
I understand what you mean about "action limiting" because we have discussed it, but I think it needs to be explained more in order to get good feedback from others. So here's my 10-center version, maybe you can provide more info:
The purpose here is to provide a way for certain actions to be disabled in order to support the idea of a "beginner mode". Not just one such mode, actually, but kind of a way to present different configurations as we see fit, much as the "Workspace" mechanism currently allows us to do this for palettes. There are two primary use cases I want to see supported:
1) The ability to create a tutorial such that the user is limited to only being able to do "approved" things. So a tutorial on dynamics might only allow the commands for adding dynamics and hairpins and making adjustments via edit mode & Inspector. Still to be decided - what actually happens if user tries a disallowed action, like adding a chord symbol (maybe a dialog pops up?)
2) A handful of presets mode for, say K-6, or Choral Music, in which not only a limited selection of palette items are displayed, but also only a subset of shortcuts are valid, only a subset of toolbar icons display, etc. Basically, a scaled-down version of the UI for people to create simple scores in with less ability to shoot themselves in the foot.
Also, though, almost for free would come the idea of a read-only mode that often gets suggested, where a score could be opened and not allow the user to modify it accidentally (he could still presumably go out of his way to turn off the read-only mode).
To me, I don't know that we need an actual UI for this, at least not in the sense of the user having to go through an enormous list of actions picking and choosing which should be allowed. For #1, I see it more like a macro recording facility where the person creating the tutorial actually completes the steps and MuseScore tracks which commands were used, then that becomes the allowed set. For #2, I don't think we need to allow users to create their own beginner modes, we just need a way to do it ourselves. So it could just be a matter of expanding the current "Workspace" mechanism so that you can also just remove buttons from the toolbar (already partially supported in master I believe) but also go through the menus and shortcut lists and similar enable/disable commands. And/or add modes to shortcuts.xml. But if it's easier for now to create a new dialog for this, whatever, that's fine too.
In reply to I agree with Anatoly, the UI… by Marc Sabatella
I understand that UI is the last thing, mentioned that in my P.S.
1) This is spot on with the current idea.
2) A bit is added from the original idea in this one, but it all makes sense.
You mention a macro recording facility, but I've rarely seen a macro recorder without an editor. The only reason I want the list is not to have a large selection of unsorted actions that the user has to sift through, but as an editor if they messed up during the tutorial creation. I don't want either the creator nor the user to shoot themselves in the foot.
As for the second half of the last paragraph, I'm not too concerned with that right now, but it will be important later on. I'm not concerned if we want to let them make presets or only let us create them. Possibly only let very advanced users create them by changing an xml file somewhere.
Personally, I strongly disagree with solely a macro editor or solely a list editor, but I support a combination (it also makes debugging a lot easier, but that is not too much of my concern). To support that list, a UI will be needed. I would appreciate if you could list your opinions on using just the macros compared to combining the two, pros and cons. Thanks!
In reply to I understand that UI is the… by JoshuaBonn1
True, a macro facility benefits greatly from an editor. I would note though, that I am not really talking about a macro facility per se (even if it's a huge step in that direction), and for the more limited scope I am talking about, a GUI editor is less crucial. Especially given that the audience for this feature is probably very small. The people actually creating (as opposed to using) a tutorial would probably be OK with hand-editing an XML file, and to me, that's all the UI we need at first. It allows the functionality to be developed, and then if there is time and interest i beyond just a small handful of people, we can worry about more bells and whistles later. Like, if/when someone takes the idea and expands it into an actual macro recorder :-)