Master Palette and Symbols
This Feature Request is in two parts. It was prompted by a discussion on graphic control of symbols and objects (wherein I was led to make some erroneous assumptions for reasons explained therein). As a result of more experimentation and a closer examination of how the Master Palette works, I would like to request that some thought be given to its structure and function. In my view, as presently constituted the Master Palette needlessly duplicates access to a great number of elements, and at the same time contains elements/objects of different classes which do not behave in the same manner.
In comparing the content of the Master Palette to that of the Main (F9) Palette, I have found that all of the categories except Symbols exist by default in the Advanced workspace of the Main Palette. This would be understandable if, in fact, those categories contained additional elements not contained in the same categories in the Main Palette, but for the most part they do not. There is a very small number of 'extras' within those categories in the Master, and they are such things as extreme and rarely-needed dynamic marks (pppppp, for instance), but most of the categories house the identical content already found in the Main.
That said, the obvious question is, 'Why does MuseScore need a separate Master Palette at all?' Surely all the extra coding required to produce it as a separate entity could have been avoided by simply adding the ONE unique Master category--'Symbols'--to the Advanced Workspace list for the Main Palette.
The second objection to the way the Master Palette is structured is that it contains two classes of elements which behave differently: those which act upon the score and affect playback and notation (in essence, everything except 'Symbols'), and those which are simply graphic objects that do not act on the score in any way other than visually (everything in the 'Symbols' category). This combination of different classes of elements within one database strikes me as questionable, and for the user, it is less than intuitive. I consider myself a fairly experienced user, but this dichotomy of logical organisation only became apparent to me upon close examination after my intuitive assumptions were called (thankfully) into question.
So, Part One of this feature request is to re-evaluate the necessity of maintaining the Master Palette at all, and consider re-vamping it as a sort of 'Insert Special Symbols' palette which would contain only elements not needed for most ordinary use-cases, and not available elsewhere in the program.
As an alternative, the 'Symbols' category could simply be added to the Advanced Workspace in the Main Palette, and the Master Palette could be done-away with entirely. Or, although I don't like this one much because it would bury Symbols one layer deeper, a third built-in workspace could be created--'All Elements', similar to 'All Instruments' in the Instrument list workspace--and Symbols could appear in the Main Palette list only when that workspace is selected.
Part Two of this feature request will likely make the code crew's blood run a bit colder than usual, but I think it is important.
In that modern scorewriters support such things as playback and automatic transposition (whether for clef changes, time-signature changes, or concert-pitch vs. transposing instrument notation), it strikes me as important that any symbol MuseScore offers which can be placed upon a score should be more than just an image object. It must be an active element that affects the score in the same way as all the current elements in the Main Palette already do. So when I choose the 19th-century C-clef or one of the Petrucci clefs (images currently available), dropping that clef onto my score should do more than just look good. It should cause the notation which follows it to be transposed clef-wise to match. At present, if I need to use one of those archaic clefs for a historical edition, I must place the modern equivalent on the score first, make that invisible, and then position the historical clef on top of it.
I do not know how difficult it would be to enable active behaviour for all of the symbols currently in the MuseScore repertoire, but I think the need is there to consider it. Given that MuseScore already supports active behaviour for two hundred and fourteen Bagpipe embellishments (and although I love the bagpipes and dream of playing them one day, these are not elements required by the average MuseScore user on a daily basis!) it seems logical to think about doing the same for all the rest of the relatively arcane symbols the program offers.