Menu reorganization scheme!
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 Thanks for taking the time 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):
- 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 Thank you for the feedback! - 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 As a former Mac GUI by harbinger
I'm not sure I follow—"Instruments" is not a menu or a sub-menu, it's a command to open a dialog.
In reply to As a former Mac GUI 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 Another advantage to menus is 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 Somehow I forgot this—there by Isaac Weiss
That was one of mine Zack - as I recall noone responded to the idea at the time.
Here is the original post.......
https://musescore.org/en/node/71656
In reply to That was one of mine Zack - by ChurchOrganist
Strange—I could have sworn I had responded (just saying something like "I second the idea"), and I also thought it was in the issue tracker, but https://musescore.org/en/node/71656 is all I can find now. Anyway, I second the idea. ;-)
In reply to Somehow I forgot this—there 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 My impression, FWIW, is that by Marc Sabatella
Well, as ChurchOrganist said, PDF is the most commonly asked about, and LibreOffice treats it as a special case:
![lomenu.png]( "lomenu.png")
In reply to Well, as ChurchOrganist said, 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 LibreOffice provides it as a 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]( "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 I would like to see style and 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 I'm not sure what you mean - 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 You are right, scaling 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 Could be it wasn't the case by Marc Sabatella
Great! Thanks!
In reply to Great! Thanks! 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.
In reply to Just to add to the "Special by Miwarre
Valid points. I'd like to remind everyone that you can directly edit the plan at https://docs.google.com/document/d/1_10pPOHRiw4Hk-2HUVDvGV9Be425ATUuEDt…. So, feel free to suggest a place in the menus for "Image Capture". Perhaps under "Tools", or maybe "File"?
In reply to Valid points. I'd like to by Isaac Weiss
Done. Also added a couple of comments.
In reply to Done. Also added a couple of by Miwarre
Great! All updated.
In reply to Valid points. I'd like to by Isaac Weiss
Tools > Image Capture.
Not in File menu. It seems like a no-brainer.
Aren't there some standard menu guidelines that we should adhere to?
In reply to Tools > Image Capture. Not in by RexC
I was basing that on the fact that Image Capture essentially is an Export function.
In reply to I was basing that on the fact by Isaac Weiss
I personally would not think of it that way. Exporting usually refers to exporting the whole file in some nonnative format, and not just a picture of part of a page.
In reply to I personally would not think by RexC
well, 'Export Parts' is also just exporting parts of a score (pun intended)
In reply to well, 'Export Parts' is also by Jojo-Schmitz
Not to mention "Save Selection…" !
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.
In reply to I agree with most of the by RexC
Changes to a score style do not affect other scores at all, so yes, I think there may be confusion here.
In reply to Changes to a score style do by Marc Sabatella
OK, I see how it works. That takes care of that.
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.0.png")
![5.1.png]( "5.1.png")
In reply to As you may already know, 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 To me, this seems a step by Marc Sabatella
The real problem is Style > Text. Anything other than "Edit Text Styles" (plural s is a must!) is misleading. It's not about choosing a text style, it only allows you to edit them; and it's not about editing the text style, it's about editing the text styles.
In reply to The real problem is Style > 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 I don't understand the 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:
At least this distinction is already made in the dialogs' titles!
In reply to Two points. First, it could 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 I don't know what you mean by 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 I would claim that some 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 I would claim that some 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 Indeed Style > Text let you by frfancha
I don't think the word "Texts" can really be used that way.
In reply to As you may already know, 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 As I am not a native English by Miwarre
Except that all these texts likely/potentially are part of a score, so there's ambiguity again.
I don't see why "General..." and "Texts..." is bad
In reply to Except that all these texts 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 Except that all these texts by Isaac Weiss
Text styles are part of the Score's style, not a separate entity as Maurizio's idea implies
In reply to Except that all these texts 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 "Except that all these texts by Miwarre
Changing "Text..." to "Texts..." has been proposed, but at least Zack opposed to it
In reply to As I am not a native English by Miwarre
I find the proposition of Miwarre excellent (but as can be clearly seen from my posts I'm not a native speaker either)
In reply to As I am not a native English 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 As I am not a native English 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).
In reply to May I suggest more explicitly by Miwarre
Just a note that the actual titles of the dialogs (currently) are "MuseScore: Edit Style" and "MuseScore: Edit Text Styles."
In reply to Just a note that the actual by Isaac Weiss
With the dot?
In reply to With the dot? by Jojo-Schmitz
No dot—it just happened to be at the end of a sentence, and American English calls for the period to appear inside the quotation mark. ;-)
In reply to No dot—it just happened to be by Isaac Weiss
Lame excuse ;-)
In reply to Lame excuse ;-) by Jojo-Schmitz
Don't blame me, blame American English!
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
In reply to This may be another in the by RogerHallett
The stretch does work on a selection.
In reply to This may be another in the by RogerHallett
Indeed—what made you think it doesn't? (Also, this may be the wrong thread to ask about it—that's not really relevant to discussions of reorganizing the menus.)
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 Now that we're diving into by Isaac Weiss
What's wrong with General ? If you open this menu, you will see that Score has "Swing settings", nothing to do with Engraving.
In reply to What's wrong with General ? by [DELETED] 5
Ah, I missed that one. Never mind.
In reply to Now that we're diving into 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 No reason we couldn't move 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!
Well, here we go for MuseScore 3: #116761: Reorganize menus for logic and clarity
In reply to Well, here we go for 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 There's a cost to every menu by RexC
Indubitably! Not just because of the menus, either—don't forget real-time MIDI input, the smart layout and "autoplace," and everything else.
In reply to Well, here we go for 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?
In reply to I'm unsure whether to post by RexC
I think those are windows, not toolbars. (Notwithstanding that really good idea somebody had about the Play Panel...)
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.
In reply to You're right. Most of them by RexC
Easily on mine, too. I wouldn't worry about it.