Menu reorganization scheme!

• Aug 31, 2015 - 00:39

Note: This scheme is definitely subject to change. After the editing period for this post expires, future revisions to the plan will be here: https://docs.google.com/document/d/1_10pPOHRiw4Hk-2HUVDvGV9Be425ATUuEDt… You can comment either here or on the Google Doc.

I've dropped hints about this before; this is a complex scheme, but it's less complex than it could be—I gave up (for now) on merging Page Settings into the General Style window, and reorganizing the palettes, which were both goals I initially had in mind.

Some of these ideas were gathered from the forums—if you recognize something you initially suggested, feel free to comment and take credit. Others I generated entirely myself, based on looking closely at all of MuseScore's menus and pretending I were a new user, and in some cases looking at analogous menus in other applications.

This is a well-developed plan, but plans invariably change, especially when the person who first comes up with them is not in authority. ;-) I sincerely hope that this will be mostly recognized as being a set of good ideas, and some form of this reorganization will make its way into a future version of MuseScore, but I'm prepared for this draft to be modified a lot as feedback from fellow users and developers comes in.

Note that, knowing no code beyond some basic HTML, when the time comes I'll need someone else to submit the pull request.

Combine “Layout” and “Style” menus into “Format” menu

"Format" menu contents:

Page Settings…
General Style Options…
Text Styles…

Add/Remove Line Breaks…

Stretch >
- Increase Stretch
- Decrease Stretch
- Reset Stretch

Reset Shape and Position

Load Style…
Save Style…

  • "Add/Remove Line Breaks" brought over because historically something similar was in the General Style dialog, it is usually used in conjunction with the Stretch commands, and it is generally closely related to matters of formatting.
  • "Reset Beam Mode" removed because it doesn't really fit in, and it's on the Beam Properties palette where it needs to be anyway.
  • Stretch commands and Reset should be grayed out when nothing is selected.
  • Style dialogs themselves should be renamed, not just the menu commands to open them.

Move "Tools", "Voices" and "Workspaces" sub-menus out of "Edit" menu

1. "Tools" and "Voices"

Currently "Tools" is a well-hidden sub-menu of "Edit." I propose to bring it into the menu bar in its own right, just to the left of its close relative "Plugins." However, additionally, "Add/Remove Line Breaks" should be moved to the new "Format" menu (see Combine “Layout” and “Style” menus into “Format” menu above); "Respell Pitches" and "Transpose" should be brought into the "Tools" menu as well (see Dissolve "Notes" menu below); and "Edit" sub-menu "Voices" should move into "Tools".

"Tools" menu contents:

Transpose…

Explode
Implode
Voices >
- [no changes to sub-menu]

Fill With Slashes
Toggle Rhythmic Slash Notation

Respell Pitches
Resequence Rehearsal Marks

2. "Workspaces"

The "Workspaces" sub-menu is equally well-hidden, and quite simply taken care of: move it, exactly as it is, into the "View" menu. I suggest it be added above "Status Bar."

Dissolve "Notes" menu

Most of the contents of the "Notes" menu—especially those that include the word "Add"—would simply make a lot more sense as a sub-menu of "Add" (probably first, above the current four sub-menus):

"Add" > "Notes" sub-menu contents:

Add > Notes >
- Note Input
- Add Note >
--- [no changes to sub-menu]
- Add Interval >
--- [no changes to sub-menu]
- Tuplets >
--- [no changes to sub-menu]

"Respell Pitches" and "Transpose…" go to the new "Tools" menu, and that leaves only "Concert Pitch", which is redundant—it's already a button in the toolbar itself, and also in the General Style Options dialog.

  • I'm not totally convinced "Note Input" needs to be in the "Add" menu—there is the toolbar icon and the hotkey [N], after all. But to be on the safe side, I'm keeping it in for this first draft.

Unresolved issues and half-baked ideas

Half-baked ideas may not be practical, and are therefore excluded from the above plan (which prides itself on being pretty much fully baked).

  • The "Instruments" dialog, currently under the "Edit" menu, is not well placed, but it's not clear where else to put it. It used to be under the "Add" menu, and there have been cases of users asking how to add instruments and saying that the first place they looked was the "Add" menu, but it was moved for very logical reasons. Suggestions are welcome.
  • I believe "Page View" and "Continuous View" really ought to be under some menu somewhere, but, again, it's not clear where to put them. They claim to be "View"-related, but as they're undo-able commands they can't really fit in with that menu. Half-baked idea: perhaps a name change to "Page Format" and "Continuous Format" and placement under the "Format" menu? Suggestions welcome!
  • Certain dialogs accessible from the "View" menu seem like they deserve to be somewhere else, but where? Suggestions welcome! Half-baked idea (actually, pretty well baked): should the Start Center be moved to the File menu?)
  • Half-baked idea: make "Add" into "Add/Delete" and merge "Edit -> Measure" and "Edit -> Instruments" appropriately.

    ---------------------------------------------------------------

    All right, that's it. Let the comments begin!


Comments

Thanks for taking the time to put this together!

I like many of these ideas. In particular:

- Moving "Edit / Tools" to top level seems like a no-brainer at this point. I buried it in Edit whern I first added it because had only two tools, but as it grows, it makes more sense to make it top level. I'd say it just hit that point by 2.0, hopefully we add a few more for 2.1 and then it makes even more sense.

- Moving "Workspaces" to "View" definitely makes more intuituive sense to me than Edit, and so does moving Preferences for that matter, but I guess it makes sense to see how other applications on various OS's do this.

- Moving "Notes" I am ambivalent about. I never use anything from this menu but Tuplets / Other, but if one did, making it harder to access seems a step backwards, as does separating out the "add" entires from the rest. I don't see the advantage of this one.

- Combing the layout and style menus does seem a good idea in principle, as it is not always obvious which one to look at for any given thing you want to do. I suspect this is the area where getting the details right may take more discussion.

- One advantage to having a menu item for things like Concert Pitch even though they are duplicated elsewhere is that menu items are easily accessible to keyboard-only (eg, blind) users. Not saying this means *everything* has to be in a menu, but we shouldn't remove things without serious thought.

- I think "Instruments" is a bit of a no-win situation. Put it under "Add" and people can't figure out how to delete or rearrange instruments. Put it under "Edit and they can't figure out how to add them. But hmm, speaking of half-baked ideas: why is "Add" a separate menu anyhow? Adding is a form of editing, after all. Maybe that is what you were getting at in your last item?

- I don't really care much about having Page / Continuous in a menu, but keybaord shrotcuts would be nice.

- I guess I can see "Start Center" being in "File", but "View" makes at least as much sense to me.

In reply to by Marc Sabatella

Thank you for the feedback!

- My rationale for dissolving "Notes" is pretty simple: with "Transpose" and "Respell Pitches" going to the "Tools" menu (by the way, I do remember that moving "Transpose" was initially your idea), even if you don't decide that three different places to toggle concert pitch is too many, a supermajority of what's left has the word "Add" in it. However, you raise a good point that burying something deeper in the menus than it already is is not a positive change. So, our first revision (from https://docs.google.com/document/d/1_10pPOHRiw4Hk-2HUVDvGV9Be425ATUuEDt…, where anybody can very easily make a "pull request" by just starting to type):

“Add” menu contents:

Notes >
- [no changes to sub-menu]
Intervals >
- [no changes to sub-menu]
Tuplets >
- [no changes to sub-menu]

Measures >
- [no changes to sub-menu]
Frames >
- [no changes to sub-menu]
Text >
- [no changes to sub-menu]
Lines
- [no changes to sub-menu]

"Respell Pitches" and "Transpose…" go to the new "Tools" menu, and that leaves only "Concert Pitch", which is doubly redundant—it's already a button in the toolbar itself, and also in the General Style Options dialog—and “Note Input”, which is also not needed—there is the toolbar icon and the hotkey [N], after all.

 

- I'm pretty confident about the details of "Format," actually. If it gets changed, it will be because we found something else to add there. (Half-baked: Instruments dialog?)

- The only thing easier for a keyboard user than a menu item is a shortcut, and one can be assigned for "Concert Pitch." Should there be one by default? [Alt]+[C]/[Opt]+[C] seems reasonable.

- The idea of moving "Start Center" to "File" came out a pre-2.0 discussion (your comment here: https://musescore.org/en/node/42046#comment-239921), and it makes sense to me because comparable things in other applications, like LibreOffice's "Startcenter" [sic], are usually in the "File" menu.

In reply to by Isaac Weiss

As a former Mac GUI programmer, keep in mind: there's nothing wrong with redundant menu entries. I know you want to keep clutter to a minimum, but a decision has to be made: do you want to make it look nice, or keep the functionality intuitive?

If you have different menus for Instruments and Editing, and you want the user to be able to edit the Instrument designation (including adding or replacing), but you don't know which menu is the more intuitive (which one the user is likely to choose for this modification), there's nothing wrong with putting an "Instruments" submenu under the Edit menu, and a "Modify" submenu under the Instruments menu. That way it's available to everyone easily.

Personally, in my own programs, I try to avoid menus in favor of buttons. They're so 90s, and the only advantage to them is they're compact, and can hide functions away till needed. But as screen sizes get bigger, I'm finding that people would rather have buttons and icons available at a single click, rather than searching thru menus for functions.
But that's me.... ;-)

In reply to by harbinger

Another advantage to menus is they have a very well-defined, well-understood, and effective organization when it comes to keyboard navigation, a very important accessibility concern. It's not that buttons cannot be made accessible, but it doens't come (almost) for free, especially if you want any sort of logical organization to the navigation (eg, one set of related buttons you can navigate between, but an easy/obvious way to jump directly to the next set of related buttons, or jump directly to any given set. While you can make this happen, it takes effort, and the results aren't as easily discoverable as a menu for a blind user or anyone else wishing to use keyboard navigation. For me, a quick keyboard persual of what's in the menus is the first thing I usually do when jumping into a new program, and this is far more efficent than hovering my mouse over a bunch of buttons one by one to read the tooltips (assuming the button labels are cryptic icons, which they usually are in any program that uses lots of them).

Also, "the only advantage to them is they're compact, and can hide functions away till needed" is actually huge. Some people use big screen, but many of use prefer small laptops. An interface needs to work equally well on an 11" or 13" screen as a 21" or 23" screen. Even with large displays, I'd rather have as much of the display dedicated to the score itself, so the hiding of functions until needed is extremely important, otherwise why bother with the larger monitor.

So to me, there is no getting around the desire for good and reasonable complete menu structure. It can certainly be augmented by a well-chosen and well-organized set of toolbars to present the most common functions - ideally, customizable to just show the toolbars you want, and add/remove specific commands. And if there is a feeling that the existing toolbarsare lacking in some way, that's a discussion worth having as well. But it shouldn't take away from the desire to optimize the menu layout.

In reply to by Marc Sabatella

Thank you, thank you, thank you. I hate plowing through random piles of inscrutable icons that cover the workspace.

A bit off subject, but once you get the menu set in stone, please don't succumb to the trendy hamburger menu. It's just one more click that's required to get to anything, and menus are used a lot in Musescore. For music score programs, utility must trump trendiness.

Somehow I forgot this—there was an idea floated to add a dedicated "Export PDF" command to the "Edit" menu (again, I can't find the original discussion). This has been added to the Google Doc.

In reply to by Isaac Weiss

My impression, FWIW, is that the issue with people not finding Export isn't specific to PDF. It's really just a matter of people who become accustomed to the non-standard way 1.3 had you use "Save As" to export to PDF, MIDI, MusicXML, or audio - they were expecting 2.0 to have that same quirk. So I'm not really sure an Export to PDF makes sense as a "top" level item within the File menu. Perhaps an "Export" submenu, with "PDF", "MIDI", "MusicXML", "MP3", and "Other", which all serve just to open the Export menu pre-populated with the corresponding file type selected. Mostly, though, I expect the issue to go away on its own, as fewer and fewer people will be just moving from 1.3, and for people no already expecting to find this in the "Save As" dialog, the existing "Export" menu item is perfectly standard and clear.

In reply to by Isaac Weiss

LibreOffice provides it as a special because there is almost nothing else anyone ever wants to export a text document to, but in the case of MuseScore, MIDI, MusicXML, and audio formats are definitely very commonly asked about as well - probably about equally as often as PDF, really. I'm not really *opposed* to the idea, but I don't really relish the idea of a menu reorg designed to make things simpler and more logical also ending up tacking on various special cases like this. Which is to say, I'd rather a more general improvement that also handles the equally-common cases of MIDI, MusicXML, and audio.

In reply to by Marc Sabatella

Well, I guess it's not that important. However, I just noticed that Preview (OS X's image processing app) also has "Export…" (for a variety of formats including PDF) and right next to it a shortcut to "Export as PDF…".:
previewmenu.png
So, at the least, we can say that it would not be a highly nonstandard thing to have under the File menu.

I would like to see style and layout combined, and would like to see page settings added to style for saving purposes. I often write arrangements and then generate the parts for the different musicians in my orchestra, I have to load the style and then change the page layout (specifically scaling) separately for each piece. As it's more or less part of the "style" for my parts printouts, I wouldn't mind seeing it in there.

In reply to by amilardovic

I'm not sure what you mean - page layout *is* saved as part of the style. And in any case, you don't need to load styles individually for each part. While the style will default to the same as the score (except for a couple of details that are set more appropriately, like turning off concert pitch, or resetting the staff size to the default), you can spoecify a style file to be used for all parts in Edit / Preferences / Score.

In reply to by Marc Sabatella

You are right, scaling *is*... ;-) It wasn't always the case, though, was it? I seem to recall having to manually go into Layout > Page Settings each time to change it... unless I erred (which is quite possible) and didn't save the scaling when I saved the style... Thanks for the quick response!

In reply to by amilardovic

Could be it wasn't the case at some time in the past, but it's been this way at least as long as 2.0 has been out. There is nothing special you need to do, though - when you save a style, the page settings are saved as part of it. So it's doubtful you erred - there is nothing you could have forogtten to do.

The option to specify a default style for parts in Preferences is definitely new for 2.0.

In reply to by amilardovic

Actually, page settings being part of the style is the main reason I want to incorporate the respective dialogs. But the details of what that would look like are so complicated, I gave up on it for now. Perhaps that will be a separate endeavor, after the initial menu reorganization is finished.

Just to add to the "Special Cases Dept.", it's me or there is no menu command for the "Image Capture" tool bar button?

I totally agree with Marc above that menus should be as complete as possible -- in addition of being as well organized as possible, of course -- and anything which is in the tool bars should also be in the menu, as tool bar can be hidden and often are. I for instance keep always hidden the "Concert Pitch" and the "Image Capture" bars, having rarely need for them (I would also hide the "File Operations" tool bar, for which there are well-known short cuts, should it not unexpectedly include also the zoom drop list!).

So, please, do not move the "Concert Pitch" toggle command out of the menu.

I agree with most of the ideas.

I agree that Layout and Styles should be merged. After all, what do styles affect if not layout or format?

I think there may be a general confusion between layout and style. (It's possible the confusion is mine.) This may be a problem with the program organization, in that I often find that in order to modify a single score I have to modify styles, which unfortunately modifies other scores as well. Or if it's not a program limitation, then maybe the the menu system could be more helpful.

The View menu has too many entries. Since many of those are toolbars, I suggest a Toolbar sub menu, i.e.
View > Toolbars > (Master Pallet, Play Panel, etc.)

There is one caveat, however. It's important not to do this too many times. It's best to get this very right and then leave it that way. Each time you change the interface, you render all books and tutorials obsolete. Worse yet, you could have multiple versions to support simultaneously.

As you may already know, LibreOffice version 5.1 was released last week, featuring reorganized and in some cases renamed menus. (Example screenshot attached.) That reminded me to return to this topic again, and one specific change in LibreOffice 5.1 prompted a new idea.

Currently under MuseScore’s Style menu, there are these two options: “General…” and “Text…”. This never seemed quite right to me. In MuseScore 1, these were called “Edit General Style…” and “Edit Text Style…”, which was closer, but also not quite right.

One of LibreOffice 5.1’s changes is the addition of a Styles menu to Writer. This allows you to change selected text from one style to another. In MuseScore, Style > Text… seems very much like it would be the same thing, but it is not at all—that facility can only be accessed through the Inspector. Instead, Style > Text… allows you to edit the various text styles.

Note that that is styles, plural. Unlike Style > General…, which dialog is all about editing the parameters of a single style, Style > Text… offers identical parameters to define dozens of separate text styles.

So, how about this:

Style > Edit General Style…
and
Style > Edit Text Styles…

Down the road, perhaps, we could even add the Inspector’s text style-switching functionality to the menus as well. But I would recommend implementing just this one change before that, perhaps even for MuseScore 2.0.3.

As this is a very similar minor change to #97131: Rename Edit > Measure > "Join Measures" to "Join Selected Measures", and "Split Measure" to "Split Measure Before Selected Note", I’m prepared to set up this pull request myself, but before that I’d like to see if anyone follows my line of thinking. Thoughts?

EDIT: I forgot the screenshots. Here you go (LibreOffice's "Insert" menu from 5.0 and then 5.1):
5.0.png 5.1.png

In reply to by Isaac Weiss

To me, this seems a step backwards. We already fixed the menu items to not be so unnecessarily verbose, why go back to that? Once you open the Style menu, *of course* selecting General means you want to edit the General style. Do we need to include verbs and repeat the name of the main menu everywhere in the UI? Eg, "Edit / Edit Preferences", or "File / Open File" or "Add / Add Measures" or "View / View Master Palette"?

In reply to by Isaac Weiss

I don't understand the distinction you are making. What is the problem you are trying to solve? The style spmen allows ypu to make change to style settings. Of course there are multiple settings, it wouldn't be very interesting if there were only a single ypu can make. "style" is the word for the group of settings you can make. What's confusing about that?

In reply to by Marc Sabatella

Two points. First, it could very well be about something other than changing style settings. See LibreOffice's Style menu linked to at the bottom. (It's basically the same as the text style setting in MuseScore's Inspector.)

Second, there is a distinction between multiple settings (General Style) and multiple settings for multiple styles (Text Styles). You may notice that all the settings for a text style fit in the Text Styles dialog at once, and you can edit multiple different styles (each with the exact same settings) by choosing on the left. Contrastingly, the sidebar on the left of the General Style dialog doesn't allow you to access the same options for multiple styles, it lets you access more and more options for the single, score-wide, General Style.

To put it another way:

General.png Text.png

At least this distinction is already made in the dialogs' titles!

Attachment Size
Style menu.png 44.3 KB

In reply to by Isaac Weiss

I don't know what you mean by the first point. You are proposing a change the wording of the style menu, but say it could be about something other than changing style settings. What else does could it be about? That'as all our style menu does. Change the style settings, save them, and load them. I don't see what some other unrelated program's style menu has to do with ours.

I get that tehcnically speaking, there isn't just one text style, but a group of them. What I don't get is what difference this makes.

Let me put it another way.

With "Split Measure", there was a problem that needed fixing. That command did something that the name of the command did not make clear - it required to to first select a note to use as a split point. Since there was no dialog that came up, there was no opportunity to be informed as to how the command worked, so basically unless you happened to guess that was how it worked, you needed the manual.

I would claim that no one who see a menu itself called "Style / Text..." would have the slighted doubt that this option is going to bring up a dialog that allows him to set text style options. The fact that tehcnically speaking there happen to be more than text style would not come as an unpleasant surprise. The user need not know before invoking that menu that it happens to be orgnized in this way - he sees by the "..." a dialog will come up, so he is comforted he will soon learn more about what he can do here. So again, I ask: what is the *problem* that you think needs to be solved?

In reply to by Marc Sabatella

I would claim that some people seeing a menu called Style > Text… would expect it to allow them to change the selected text to use a different style. Ultimately, I think it would be nice if it was possible to do that through the menus. I envision a future system where perhaps Style >Text would lead to a submenu similar to the current dropdown menu in the Inspector. But first, a minor change to lay the groundwork, that could be helpful anyway, i.e., adding the specific word "edit" and the plural "s".

In reply to by Isaac Weiss

Has anyone expressed such a confusion>? I can't recall it.

I still think the current wording is an improvement over the too-verbose previous one, so until there is a real problem, or a totally new menu with new items that makes the current ones ambiguous, I see no reaosn to force dozens of translators to revisit this again with the only payoff being that the menus return to their former overly verbose state.

In reply to by Isaac Weiss

Indeed Style > Text let you think you will change the style of the selected text (as in the inspector).
Naming the menu option Style > Texts would remove this ambiguity, making clear it is to edit the style of "all" texts without making a long menu entry (just one letter more)

In reply to by Isaac Weiss

As I am not a native English speaker, I'll leave out any comment on English style (pun not intended!).

To me this suggestion by ZackTheCarshark makes a lot of sense, regardless of the language in which it is worded. Assuming a translation into my own mother tongue, the current menu item texts (in particular "Style | Text...") are misleading or, at least, non-leading, in the sense that I have no idea what they lead to (well, I would have no idea, shouldn't I have used MS for years and now automatically assuming what each menu item does, without even reading the labels any more...).

Assuming I know nothing about MS, "Style | Text..." does mean for me that that menu item leads to a way to change the styling of the (currently selected?) text and would puzzle me to see it enabled when no text is selected.

The strategies to circumvent this may different from language to language, but for this specific case, if verbosity is bad, terseness does not seem to me any better.

The ambiguity of this item casts a shadow of ambiguity also on the other item ("Style | General..."), which in itself might be clear enough.

Purely as an example, re-translating into English what would seem to me sufficiently clear and not too verbose in my own language, the strings would come out as "Style | Score style..." and "Style | Text styles...", definitely with a plural in the second one.

I'll leave to the native speakers to tell if this makes sense in English; it definitely would in Italian (which is not a language totally unrelated to English, mind, so linguistic discrepancies should not be huge...).

In reply to by Jojo-Schmitz

Except that all these texts likely/potentially are part of a score, so there's ambiguity again.

I can't quite see what you mean. Could you clarify that, please? I think Maurizio has had one of the best ideas yet.

"Texts" might emphasize that style changes affect more than one piece of text, but it doesn't really help with the point that that single menu item defines not a single style, but a couple dozen styles, and you have to go somewhere else to switch between them. And I am very uncomfortable with it on syntactical grounds.

In reply to by Jojo-Schmitz

"Except that all these texts likely/potentially are part of a score": indeed! As well as a good deal of the score style settings are applied to texts (header, footer, measure numbers, lyrics, etc.).

Nevertheless, "Impostazioni partitura" and "Stili di testo" ("=> Score settings" and "Text styles" or "Textual styles") would convey to my mind a rather clear picture of what each menu item does and, equally important, what it does not do.

Then, if my English translations above are not adequate, I am sure the English native speakers can arrive at a better wording.

"I don't see why "General..." and "Texts..." is bad": the fact is that currently it is not "Texts...", but "Text..." and it is totally unclear which text is referred to.

In reply to by Miwarre

"Style / Score style" and "Style / Text styles" works for me in English, although I share the concern that text styles really are part of the score as well so it could potentially be confusing.

"Texts" is a word in English, but I agree that it is somehow awkward here.

I also appreciate the comment made elsewhere that if we were to add a Style menu to the context (right click) menu for empty parts of the score, the wording should make sense there too, so a little more verbosity is not a bad thing.

In reply to by Miwarre

May I suggest more explicitly that we (at least try to) disentangle the question of the (intended vs. perceived) meaning of the menu item labels from the English-specific questions?

Textual elements belong to score too, true. As well as characters belong to paragraphs and paragraphs belong to pages; still, in the style menu of a word processor, seeing a "Character" item, a "Paragraph" item and a "Page" item, nobody would perceive that the first refers to characters NOT belonging to any paragraph, and the second to paragraphs NOT belonging to any page!

The opposite is also true: many of the score settings apply to textual elements and nobody finds strange that a menu item separate from the "Text" item deals with texts too!

If "Texts" is awkward in English, the burden is on the English native speakers to find something better for the English version! The current "Text" is too generic, I am afraid.

Would "Text(ual?) Styles" be too verbose (and the plural would not be awkward here, I presume)? After all, that same menu already include "Load Style..." and "Save Style..." and nobody seems to object.
_________________

As an aside, the English localization is the starting point for each other localization. I believe this to be an additional reason for it being as expressive as possible, in order to guide the other localizations (should I do it, I would translate the second menu item with "Stili di testo" no matter the English original! But this is just me; and Italian is much more lenient toward verbosity than English is).

This may be another in the 'half-baked' basket, but the ability to select, say, 3 bars and compress them would help significantly in making the score more workable in some cases. This would mean over-riding the default spacing, but sometimes it is desirable. I know I can scale the pages to fit more bars per system, but I don't want to apply this to the whole score - just a couple of bars. Sometimes this is necessary to avoid just one bar per system or having one system by itself on the last page (worse if it ends up on an odd page).
I would see it working something like the Stretch and Compress { } operation, except that if you selected three bars, it would compress the lot as many times as you clicked the { key. (viz instead of working a bar at a time it worked on the whole selection.)
Just a thought.
Regards - and thanks for your dedication to sorting through these posts.
R

Now that we're diving into 3.0, the time has come to get more serious about this. Some further thoughts on changing "General…" and "Text…"

What about replacing the word "General" with "Engraving"? So it would be something like:

Format > Edit Engraving Style...
Format > Edit Text Styles...
-------------
Format > Save Style Sheet…
Format > Load Style Sheet...

In reply to by Isaac Weiss

No reason we couldn't move that into a third dialog, though. Or maybe break it down even further. This also crosses back into the idea of combining the Layout / Page Settings dialog into the Style menu somehow. Changes of that magnitude would have been out of the question for a 2.0.x, I think, but thinking forward and stepping back to see the big picture, I could imagine something like this:

Style
-----
Style > Score Preferences
Style > Playback
Style > Page Layout
Style > Engraving
Style > Text
Style > Advanced

(I still don't see the point of taking up space in the menu with the word "edit" over and over again).

"Score Preferences" would allow you to set score-specific preferences for things that are otherwise set globally in Edit / Preferences. In particular, the settings in the Canvas & Score tabs all seem like they might be something you'd want to set per-score. Especially Scroll page (Horizontally/Vertically), Style for part, and Default zoom.

"Playback" would contain the current swing settings, but maybe also score-specific settings for the play repeats option (including the new proposed "Performance mode" version where we skip repeats by taking the *last* volta in all cases, maybe some Play Panel settings, etc.

"Page Layout" would be the current page settings dialogm, but maybe also the current contents of the first three tabs of Style / General (General, Page, and Header, Footer, Numbers).

"Engraving" would be the rest of Style / General.

"Text" would be as is.

"Advanced" would be score-specific versions of the advanced settings we every once in a while discuss giving control over for power users - more fine-tuning of various defaults that currently can't be set via style settings and that feel like they'd clutter the Engraving dialog too much. Or maybe it's just another tab in the Engraving dialog.

In reply to by Marc Sabatella

So, that wouldn't really work the concept of a "Format" menu containing page settings, score and text style options, stretch, and line breaks. But if "Playback" was merged into the Play Panel, over under the View menu... everything else would then be consistent.

Keep the brainstorming going!

In reply to by Isaac Weiss

There's a cost to every menu reorganization. Does this mean that someone has to write, and we have to buy, "Mastering MuseScore: Make beautiful sheet music with MuseScore 3" and "Mastering MuseScore: Make beautiful sheet music with MuseScore 4", etc.?

In reply to by Isaac Weiss

I'm unsure whether to post here or there, but there's a comment that got missed, so I'm going to repeat it.

The View menu has too many entries. Since many of those are toolbars, I suggest a Toolbar sub menu, i.e.
View > Toolbars > (Master Pallet, Play Panel, etc.)
That seems to be fairly standard or at least common among other programs. It also has the advantage that it makes it reasonably easy to toggle wanted or unwanted elements of the interface.

And while we're at it, aren't there rather standard guidelines that should be adhered to? I'm thinking of the (Gnu?) Human Interface Guidelines as an example. For conformity with other programs, there are rules on where the Export menu entry goes, what you put in the View menu, etc. I know there is a problem with choosing the appropriate standard for a multi-platform program, but still there needs to be some sort of standard rationale. However well thought out this appears to be, it does seem to be a bit ad hoc. Has this been considered?

You're right. Most of them are. But if vertical menu space is an object, they could still be consolidated if we had a collective name for them. On the other hand, they all fit easily on my main computer monitor.

Do you still have an unanswered question? Please log in first to post your question.