Tuplets do not move with arrow keys when selected
It is true that for the most part tuples are situated appropriately by default, or if not, changing the above/below is often all that is needed. Nevertheless, it's been noticed that a bracketed tuple number, for example, doesn't jive well with slurs at times and doesn't seem to enact a change of auto-placement of slurs (which in a sense is a bug in itself). The point of mentioning this is, in the mean time, if this occurs, it would be appropriate to be able to utilize the arrow keys on the tuple to avoid collisions, yet the user can not do so as it currently is and must resort to mouse/direct inspector value changes. So in a sense, there are two separate issues here, repeating what was just said:
1) Tuples do not respond to X/Y co-ordinate changes via arrow keys.
2) There are potential clashes of tuples (especially when brackets showing) with slurs that will need (hopefully) to be updated with future improvements of the auto placement algorithms.
And as always: "good luck"
Comments
Most element types do not respond to the arrow keys. Rests, articulations, and text elements have been programmed to respond to the "pitch-up" and "pitch-down" commands, but these will only do so if exactly one element is selected. Otherwise, the command will get sent to all notes in the selection, but nothing else. As for the left and right arrow keys, text elements have been programmed to intercept the "prev-chord" and "next-chord" commands, but again, only if one element is selected. And it was probably a design decision not to have articulations intercept these two commands. It would be easy enough to make tuplets respond to up/down and also intercept left/right if desired, but why stop there? What other element types should handle these keys in the same way?
I am curious, though: What do you have against the inspector? It is the preferred method for setting any and all element property values, including X and Y offset.
You're right, most do not. Maybe they should all respond to positioning from the keyboard? The result wouldn't bother me, as currently arrows seem to do nothing rather than something, even for slurs and ties, and this might result in a gain of productivity if it were so.
[Aside]: In that sense, this is similar to my suggestion to allow "select next element" (ALT+L/R) to be executable while in Note-entry so that the user is 'aided' in not having to exit note-entry first before doing so rather than having ALT+L/R do absolutely nothing while in Note-Entry, although this isn't a necessary addition to the core functioning of the program, and most users would probably not utilize it, but it isn't illogical to do so.
To itch your curiosity, it is weird that [tab] doesn't directly go to inspector when the inspector is floating, so that's one thing that I have "against the inspector," as the tabbing order is varied depending on its floating property. More to the point, utilizing the arrows for position-manipulation is more efficient than tabbing over to a text box or moving a mouse and clicking into a text-box for performing a slight change of positioning to an element already selected after utilizing a keyboard to place the element. Unless I require a specific numerical [x.xxsp] value, it seems more intuititive to prefer a quick 'touch-up' without dealing with numerals in the inspector.
The norm for most element is to require double-click to place them in edit mode before they respond to the cursor keys. For tuplets, though, this allows editing the bracket, not the position of the number. It would probably be possible to add another handle for that. but I also know there is some work being done on redesigning how edit mode works in general.
In reply to The norm for most element is… by Marc Sabatella
Exactly, and therefore the user doesn't have a means of utilizing the keyboard for this activity (with a tuple) such as with the middle-node of a slur in edit mode. It really might not be a bad idea to allow general re-positioning of these elements without requiring a 'middle-node' in edit mode, also requiring tabbing if the user is keyboard-heavy, but allow something equivalent to what the mouse can do without ever entering into edit mode: i.e., provide similar activity to the mouse-drag equivalent like with how dynamics intercept the arrow keys from the above mentioned commands [pitch-up/down, prev-next].
Either way, looking forward to what the contributors provide.
I see no problem with modifying the code so that all elements can be nudged up or down, since the up and down keys currently have no effect on most element types. But since the left and right arrow keys are mapped to "prev-chord" and "next-chord", they already have an effect other than what is being suggested. We would need to determine which element types should be nudged left or right, and which element types should allow the command to do what it currently does.
For the up/down behavior, I propose this change 92ae774. As is currently the case, this will only work when exactly one element is selected. I think that it is important that if the selection contains notes and other element types, these commands are only given to the notes.
In reply to I see no problem with… by mattmcclinch
Right, like with bar lines and articulations (e.g. a staccato), a user can press left/right and the selector will go to the next note or rest, yet up/down on a staccato will move it vertically, and that shouldn't be changed at all.
This slightly raises an interrogation: why for instance should the user be able to press right when selecting a staccato and get to the next note, but then for instance select a slur and not be able to get to the next note on right or left but rather have nothing performed? Of course it makes sense to say that since there are two terminal points, there is some slight discrepancy as compared with a single-noded staccato, but still, it is a valid question. Not to say this needs to change at all, but it warrants some thought about what should do what.
The "next-chord" and "prev-chord" commands will only move the selection to the next or previous chord if the selected element is a note or a chord/rest, or if its parent is a note or a chord/rest or a segment. If the parent of the selected element is a measure or a system, the command does not do anything. It would make sense for these commands to either nudge the element left or right in these cases, or else find an appropriate chord/rest to select. ce72c28 takes the first approach.
As far as I understand it was never designed that arrow keys would move a tuplet so it is more a suggestion rather than a bug. But this definitely worth considering. However it would probably be better to do such a change so that arrow keys would act consistently across different element types so maybe this could be a part of some larger change regarding keyboard interaction, or at least regarding editing elements positions with a keyboard.
Right, that is basically what I have been trying to say all along, The changes that I have proposed here (92ae774 and ce72c28) consider the larger picture and aim to provide more consistency across different element types.
If I understand correctly, it should be "tuplet" rather than "tuple"?