Reorganize workspace

• Nov 20, 2018 - 17:22
Reported version
3.0
Priority
P1 - High
Type
Ergonomical (UX)
Frequency
Once
Severity
S5 - Suggestion
Reproducibility
Always
Status
active
Regression
No
Workaround
No
Project

When the workspace expansion (GSoC project of Joshua Bonn) facility was merged, it necessitated some changes to how we do certain things (eg, make changes to the default palettes), and also added some capabilities that I think we should start taking advantage of. I am creating this issue to raise awareness and also start some discussion of possibilities.

The "high" priority portion of this is regarding the workspace files. Regarding the palettes - the code in menus.cpp is no longer (very) relevant. The advanced and basic workspaces are now read in like any other workspace, so we need to make sure these files reflect the intended reality (changes to menus.cpp made recently aren't reflected in the actual workspaces).

Going forward, when we want to change one or both of these palettes, we need to get in the habit of editing the workspace files. I'd like to change these to plain XML files in GitHub that are then archived into .workspace files at build time. Unfortunately, this means we need to make changes in two places if we want to add a palette element to both. Some day we could look at possibilities of refactoring this.

But also, a workspace now includes the possibility of defining the menus and toolbars as well. So the Basic workspace could skip things like the double and triplet augmentation dots on the toolbar or View / Selection Filter etc. Maybe we leave the Basic workspace alone but also add a new "Beginner" workspace that is really stripped down, which was actually kind of the original idea. This is less high priority but still something to think about.

BTW, for more background on the changes, see also #276668: missing entry "Swing" in Palette "text" and in particular my comment https://musescore.org/en/node/276668#comment-870110, and the PR for the workspace expansion, https://github.com/musescore/MuseScore/pull/3729 (which also links to the blog posts leading to the PR).


Comments

So, I was looking into refactoring out menus.cpp handling of palettes and I noticed a couple things.
1. It is used by workspace.cpp if the given workspace couldn't be read. This could easily be changed to read Basic or Advanced instead. If those don't exist, something is really wrong.
2. It is used by Master Palette.

To refactor master palette, I would assume there would need to be A) a unique read function to load the master palette from xml, B) an xml file, C) a place to put said xml file. Is this what's desired?

Second point first - I think the master palette should stay hard-coded, that's what makes it master. Given that, I think it doesn't matter much to me what is used if a workspace can't be read.