Created
April 24, 2018 21:16
-
-
Save JoshuaBonn1/38eb08f4ef85f0a8b753fecedede36db to your computer and use it in GitHub Desktop.
Action Limiting/Custom State Creation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Goal: | |
Add functionality to create new states by disabling different actions throughout the menu and toolbars. | |
Components: | |
Ability to disable actions | |
Ability to save states | |
Ability to access states | |
Ability to save/load states to/from preferences file | |
Further Discussion: | |
Ability to disable actions | |
Initial Thought: | |
By right clicking any toolbar item or other GUI button, the dropdown menu has the option to disable the item. | |
Concerns: | |
If this is an integrated feature (i.e. accessible outside of creating states), how does the feature persist? | |
Does a disabled item stay disabled on subsequent runs of MuseScore? | |
Does a disabled item stay disabled when the state changes? | |
Can an item be enabled in a state that usually has it disabled, or will that cause errors? | |
If this is just a feature specifically for creating states, does there need to be “state creation” mode? | |
Ability to save states | |
Initial Thought: | |
If it is an integrated feature, by going to some menu the state can be saved (possibly named). | |
If it is a “state creation” mode, then upon finishing the creation, the user would be prompted with saving the state. | |
Concerns: | |
These concerns can be fleshed out once I figure out how the code works for states. | |
Ability to access states | |
Initial Thought: | |
Some option in a menu would load a specific state upon selection. (only custom states?) | |
If the use case is a tutorial, then it could be loaded from a file. | |
Concerns: | |
As mentioned above, would the user be able to load only custom states? Or could they load the standard states? | |
I’m assuming most states are accessed by certain score interactions. Would custom states also be accessed that way? | |
What happens when the user performs an action that would change the state normally? Would it change to the state, stay on the custom state, or change to the state but on return it would go to the custom state? | |
Ability to save/load states to/from preferences file | |
Initial Thought: | |
All custom states would be saved and loaded similar to how the palettes are handled. | |
Concerns: | |
None that I can think of, pretty standard handling of custom items. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment