Slurs/lines etc. - what difference does "edit mode" actually make?
The manual explains what edit mode is supposed to do for slurs/hairpins/other lines etc. - but from what I'm seeing all those things work even without entering edit mode - just selecting a single element then using TAB to select a particular grip handle allows you to make all the same modifications.
The only thing the command seems to do is automatically select the "end" grip handle, and change the text in the status bar to say "Edit mode". From a brief look through the code it doesn't seem any of the cursor key operations etc. are treated differently by such an element whether it's in edit mode or not either.
Is there a specific example of an operation that only works when such an element is in edit mode?
Comments
The fact that is works in "normal" mode is a fairly recent addition. (3.5-ish?)
The differences is what handle gets selected, on a single click it is the center one, the one that moves the entire slur, on double-clock it is the rightmost one, to make the slur shorter or longer, or tilt it
In reply to The differences is what… by Jojo-Schmitz
But as I said you can change which handle is selected with the tab key or mouse anyway, without actually going into "edit mode". And all the same operations seem to be available.
In reply to But as I said you can change… by Dylan Nicholson1
Yes, the difference is rather small
In reply to Yes, the difference is… by Jojo-Schmitz
Actually there is quite a difference after all - in Edit mode the only commands that work are those that apply to editing the current element, plus the File/Help/preferences commands. All other commands related to score manipulation/navigation/note input are disabled.
Interestingly even the clipboard operations don't work in edit mode despite being shown as enabled in the menu.
One interesting difference between text editing and line/grip element editing is that for the former "undo/redo" rolls up into a single action after you exit text editing mode, whereas that's not true for the latter.
In reply to Actually there is quite a… by Dylan Nicholson1
Some other observations:
a) undo for a line element exits edit mode (enabling all the other commands that were previously disabled)
b) edit mode is permitted for layout breaks, and that appears to be the only way to manipulate where they're shown on the score (not that this is particularly useful except perhaps to get them out of the way of your notation)
c) brackets are the only type of element with grip handles that explicitly require activating "edit mode" in order to manipulate them (but in MU4 currently this is not true, nor do I see any reason it should be)
d) Alt+Shift+E doesn't work when you click on a key/time signature in a score with multiple staves, despite it being available in the context menu. You have to use ctrl+click to ensure only the time/key signature in the current staff is selected, and moreover, for key signatures must be first instance - i.e. it can't be a key signature automatically shown on a subsequent system. But if I wanted to "nudge" a time/key signature left or right, I'd most likely want to do it across all staves surely...and it doesn't seem possible to modify the position of key signatures automatically shown on subsequent systems at all.
e) Clefs and measure numbers seem to be the only types of element that don't have edit mode at all. But it would seem just as useful to be able to reposition them with the cursor keys as other elements. Instrument names don't allow explicitly activating edit mode, but can still be repositioned with the cursor keys. Tuplets can only enter edit mode if they have a bracket showing - but you can still manipulate the grip handles without using edit mode, even with no bracket!
f) Edit mode for Coda symbols seems a bit unexpected, it goes into text editing mode instead.
In reply to Some other observations: a)… by Dylan Nicholson1
d) Double click time sig to drag just that staff sig around. Select a key sig to be able to drag it.
If you point is that keyboard evoked edit mode isn't very useful, or consistent, I agree.
In reply to d) Double click time sig to… by bobjp
It's extremely useful, but not super consistent. It seems you can use the keyboard to modify the x-offset all of all time/key signatures but only via the inspector (editing the offset x/y). Though I'm not sure how to switch focus to the inspector using the keyboard.
In reply to It's extremely useful, but… by Dylan Nicholson1
Select the key signature and hit FN+f8.
In reply to Select the key signature and… by bobjp
Er, nope, Fn+F8 on my keyboard activates the Windows screen projection options (for controlling how multiple displays work I guess, I don't have one to test with currently, never used).
F8 shows/hides the inspector but doesn't change the focus to it. I can't seem to find any way to use the keyboard to switch between various windows/dock-panels of MuseScore at all.
In reply to Er, nope, Fn+F8 on my… by Dylan Nicholson1
This is what I get. Looks like it is focused on the key signature to me. Though different keyboards do things differently , sometimes.
In reply to This is what I get. Looks… by bobjp
Well it looks like the focus is on the inspector (specifically the 'visible' label), which is a good thing, but are you saying you can get that to happen just using the keyboard if the focus had previously been on the score window? The only handling for "F8" in MuseScore that I can find looking through the code etc. is that by default it's mapped to "show/hide inspector", which does indeed make that window appear to disappear, but I'm not seeing it get the focus at all. Are you sure you haven't mapped Fn+F8 yourself? (though I certainly can't see any actions or indeed any code that would trigger setting the focus to the Inspector panel).
In reply to Well it looks like the focus… by Dylan Nicholson1
BTW there's a discussion about it here: https://musescore.org/en/node/299941
On further testing I discovered that the TAB key for elements that don't have grip handles (line-based elements) does in fact change the focus to the Inspector - but only if it's docked.
If it's undocked as per your screenshot it doesn't work and there appears to be no way of changing focus to it using the keyboard.
(In v4 at this stage not even that much works, you have to use F6 before using TAB to tab through all panels until you get to the "inspector", or properties panel as it's now called, but you still can't do so if it's undocked)
In reply to Well it looks like the focus… by Dylan Nicholson1
I created a new score and selected the key signature. Then I hit fn+f8. The result is in my picture. This is a completely stock MuseScore. I don't map or change anything. I don't hardly use any keyboard shortcuts.
I notice that my desktop keyboard doesn't have an fn key. I haven't check too many of my other computers. But on my main laptop, this is how fn+f8 works. No idea why. Or if it's the way it should work. Perhaps differences in various keyboards and computers explain some of the things you are finding.
In reply to I created a new score and… by bobjp
See https://musescore.org/en/handbook/3/inspector#displaying-inspector, this is supposed to happen on a Mac
In reply to I created a new score and… by bobjp
@bobjp And it's different if you press just F8 alone? What if it's docked? What happens if you press it (or fn+f8) a second time?
I can't see how what you describe is possible from the code. Fn+function key on most keyboards doesn't even send keystrokes that can be intercepted by applications.
In reply to And it's different if you… by Dylan Nicholson1
Nothing happens if I just push f8. The function keys do double duty. f8 key primary function is to fast forward audio in a music player. F11 keys turns off my speakers. In order to get actual f8 action, I have to hit FN+f8. This seems to be an internal OS feature independent of MuseScore.
Same thing happens docked or not.
In reply to Nothing happens if I just… by bobjp
On a Mac fn+F8 is starting the Inspector. On my Windows desktop and laptop it mutes/unmutes the speaker, and a plain F8 starts the Inspector
In reply to Nothing happens if I just… by bobjp
That's bizarre.
Just plain "F8" is mapped to an action that shows/hides the inspector but there's no code to set the focus to it, and it certainly doesn't for me. In fact as I said, when undocked, I can't find any way at all to set keyboard focus to the inspector window (if it's docked and the current selected element doesn't have grip handles then "Tab" works).
In reply to That's bizarre. Just plain … by Dylan Nicholson1
So right here we have three different keyboards doing three different things regardless of the code. Not surprising to me.
In reply to Er, nope, Fn+F8 on my… by Dylan Nicholson1
In MuseScore 3, Tab / Shift+Tab moves between all controls in the current window, and Tab usually goes straight to the Inspector. Except for a couple of particular cases like lines or barlines where instead it moves between handles. That's a regression introduced when the new behavior of lines not needing edit mode was introduced.
In MuseScore 4 the plan is for F6 to move from one section to the next t- not sure what these are called, but the things we'd call docked windows in MuseScore 3. Apparently it's still very much a work in progress though.
In reply to Actually there is quite a… by Dylan Nicholson1
I have to say that as a mouser, I'm not sure how productive it is to select something then switch to shortcuts to continue. I don't think I've ever used Edit Mode, as such. Just double click.
In reply to I have to say that as a… by bobjp
Good point about double-click, that does actually start edit mode for element types that support it though for key/time signatures in a multi-staff score, you need to use control-double click.
Double-click on instrument names is an exception - that brings up the score properties dialog.
For text-based elements that are already selected just single click is enough actually.
In reply to I have to say that as a… by bobjp
Double-click is edit mode. So yes, you've used it :-)
In reply to Actually there is quite a… by Dylan Nicholson1
It's worth noting that the relatively recent changes that soften the line between selecting a line and putting into edit mode were a partial implementation of one of @tantacrul's very first design specs. I know he's expressed thoughts about wishing the see the design implemented more fully. Definitely worth continue that conversation.
In reply to It's worth noting that the… by Marc Sabatella
Just found another difference - in Edit mode you can use Alt+arrows to make "micro adjustments", but not in non-edit mode, because Alt+cursor key has a different meaning (changing which element is selected).
In reply to It's worth noting that the… by Marc Sabatella
Not very related to this discussion but still ... I wonder why tuplets do not have the central handle so that you can move them more easily? (of course you can also modify X and Y properties in the Inspector)
In reply to Not very related to this… by hstanekovic
+1
I'm actually seriously looking into whether we need edit mode at all, for any type of element.
The main issue is that currently elements respond to dragging via the mouse very differently depending on whether they're in edit mode or not:
notes
- normal mode: dragging vertically adjusts pitch, CTRL prevents modification, ALT/SHIFT have no effect. Dragging horizontally adjusts leading space, note you must drag right first (the default and minimum is 0). CTRL/ALT/SHIFT have no effect.
- edit mode: dragging vertically/horizontally adjusts x/y offset. CTRL prevents vertical modification, ALT turns off auto-place, SHIFT prevents ANY modification (appears to be a bug, as SHIFT is first treated as preventing horizontal modification, but later treated as meaning modify leading space, which can only be modified horizontally!)
rests
- normal mode: for whole rests dragging does nothing, for others dragging vertically/horizontally adjusts x/y offset. CTRL prevents vert. mod., ALT turns off auto-place, SHIFT prevents horiz. mod.
- edit mode: for all rests (inc. whole), dragging vertically/horizontally adjusts x/y offset, CTRL prevents vert. mod., ALT turns off auto-place, SHIFT prevents ANY modification (same bug as for notes)
clefs
- normal mode: dragging pans the whole score around. CTRL doesn't affect dragging but does toggle selection. ALT/SHIFT have no effect.
- edit mode: not available
key signatures
- normal mode: dragging pans the whole score around. CTRL doesn't affect dragging but does toggle selection. ALT/SHIFT have no effect.
- edit mode: dragging vertically/horizontally adjusts x/y offset. CTRL prevents vert. mod., ALT turns off auto-place, SHIFT prevents horiz. mod.
time signatures/accidentals/articulations/ornaments/breaths&pauses/tremolo beams/fret diagrams...
- normal mode: dragging vertically/horizontally adjusts x/y offset. CTRL prevents vert. mod., ALT turns off auto-place, SHIFT prevents horiz. mod.
- edit mode: same as normal mode
beams
- normal mode: dragging only affects beam height/angle depending on grip selected. CTRL prevents any mod., ALT/SHIFT have no effect
- edit mode: same as normal mode except that ALT turns off auto-place
lines (with grip handles, incl. hairpins, slurs etc.)
- normal mode/edit mode: dragging vertically/horizontally adjusts x/y offset of whole item or individual grip handle if initially clicked on. CTRL prevents vert. mod., ALT turns off auto-place (, SHIFT prevents horiz. mod. Certain grip handles can never be dragged left/right (e.g. the one to control hairpin width) or up/down (e.g. the rightmost handle for a hairpin with "allow diagonal" off).
barlines
- normal/edit mode: dragging lower handle controls barline span. CTRL affects just current barline (vs all on staff), ALT/SHIFT have no effect
brackets
- normal mode: dragging pans the whole score around. CTRL doesn't affect dragging but does toggle selection. ALT/SHIFT have no effect.
- edit mode: dragging lower handle controls bracket span. CTRL prevents modification. ALT/SHIFT have no effect.
instrument names
- normal mode: dragging pans the whole score around. CTRL doesn't affect dragging but does toggle selection. ALT/SHIFT have no effect.
- edit mode: not available
text (including tempo, rehearsal marks, dynamics, repeat markers, fingerings, chord symbols etc. etc.)
- normal mode: dragging vertically/horizontally adjusts x/y offset. CTRL prevents vert. mod., ALT turns off auto-place, SHIFT prevents horiz. mod.
- edit mode: dragging changes what text is selected. CTRL/ALT/SHIFT have no effect (in MS Word these effect the "unit" of selection is, e.g. word/paragraph)
frames
- normal mode: dragging pans the whole score around. CTRL doesn't affect dragging but does toggle selection. ALT/SHIFT have no effect.
- edit mode: for text frames, dragging where there's text is used to select text, dragging outside this is as per normal mode. For horizontal/vertical frames, dragging stretches the height/width of the frame. CTRL prevents modification, ALT/SHIFT have no effect.
breaks
- normal mode: dragging pans the whole score around. CTRL doesn't affect dragging but does toggle selection. ALT turns off auto-place, SHIFT has no effect.
- edit mode: dragging vertically/horizontally adjusts x/y offset. CTRL prevents vert. mod., ALT has no effect, SHIFT prevents horiz. mod.
spacers
- normal/edit mode: vertical dragging adjusts the height of the spacer. CTRL prevents modification, ALT/SHIFT have no effect.
In principle virtually all this (with improvements) could be achieved by being smarter about what various keyboard modifiers mean rather than needing an explicit "edit" mode, which I believe would make things easier both for users AND simpler at a code level (meaning less bugs etc.!).
In reply to I'm actually seriously… by Dylan Nicholson1
Indeed, I believe @tantacrul was also working towards that goal. Although I'm not sure one would literally want to apply to all elements - even text?
I will say that personally I move elements horizontal vertical position probably about 10 times as often as I ever fiddle with handles for fine-tuning shape or changing anchors (e.g., correcting any errors in the range I originally selected when applying a line). So I do hope any changes made in this respect don't end up making this any more awkward than it already is (it's rather a pain currently that selecting a line doesn't immediately allow Ctrl+Up/Down).
In reply to Indeed, I believe @tantacrul… by Marc Sabatella
"Text edit mode" is obviously quite a special case, that's not going anywhere (I already did much of the work there to get it to where to needs to be, and I'd like to think it's an improvement over v3, e.g. undo works for bold/italic/underline when only part of the text is selected, and it now never tries to draw musical symbols in the wrong font/format, which did happen quite a bit previously).
At this stage I'm just trying to get everything else working in v4, but that did require writing a bunch of extra code to support edit mode for all elements. None of it's been merged yet, and I'm more than willing to discard it in favour of something more user- and developer friendly.
For instance the SHIFT+drag bug is still present in what I've done so far, because the code to restrain horizontal mode while SHIFT was done was already in place at one level, and the code for it to be interpreted as "changing leading space" was ported as is from v3.
One significant issue with edit mode in v4 especially is that there's no user feedback at all that you are in edit mode - not even the notation input toolbar icons are greyed out (they should logically be and their attached actions are unavailable, but that doesn't appear to be implemented). And there's nothing in the status bar like there was in v4.
So if we want to maintain "edit mode", there's still a lot of work to do in v4. The question is whether it would be better directed into discarding the need for it.
In reply to "Text edit mode" is… by Dylan Nicholson1
Good question. I don't have enough experience with MU4 builds or with the overall design documents and goals to say.