Disable automatic placement of single element when dragged
The new automatic placement of dynamics, hairpins ... is really great, a very important progress. After some practical use I think, one little change would be necessary. There ever will be a small rest of some elements those placement must nevertheless been changed. In this case you must first change the property 'automatic' to false, before you can work. This is uncomfortable and definitely not intuitive.
The property should be changed automatically, when the element is dragged to its new position. This makes work much easier, if you want to change the position, it does not make any difference, if not.
The implementation is simple, just one line of code, without any sideeffects.:
dragelement.cpp, ln. 120:
Element* e = _score->getSelectedElement();
// add this command
if (e) {
if(e->type() == Element::Type::BREATH ||
e->type() == Element::Type::TIE ||
e->type() == Element::Type::ARTICULATION ||
e->type() == Element::Type::DYNAMIC ||
e->type() == Element::Type::TUPLET ||
e->type() == Element::Type::TEMPO_TEXT ||
e->type() == Element::Type::STAFF_TEXT ||
e->type() == Element::Type::REHEARSAL_MARK ||
e->type() == Element::Type::VOLTA ||
e->type() == Element::Type::HAIRPIN ||
e->type() == Element::Type::OTTAVA ||
e->type() == Element::Type::PEDAL ||
e->type() == Element::Type::TRILL ||
e->type() == Element::Type::TEXTLINE ||
e->type() == Element::Type::LYRICSLINE ||
e->type() == Element::Type::SLUR ||
e->type() == Element::Type::TRILL)
e->setAutoplace(false);
//
if (_score->playNote()) {
mscore->play(e);
_score->setPlayNote(false);
}
QLineF anchor = e->dragAnchor();
if (!anchor.isNull())
setDropAnchor(anchor);
else
setDropTarget(0); // this also resets dropAnchor
}
_score->update();
}
Comments
Or disable the 'dragability' when automatic placement is set.
Also the 'reset to default' for that automatic Placement as well as ticking it needs to reset the x and y offsets to 0, or make them take effect again when unticking
And there's more elements to consider, measure numbers, title, composer, lyricist, etc
Simpler fix:
if (!e->userOff().isNull()) e->setAutoplace(false);
Re: Comment #3
- I'd prefer to allow dragging.
- Offset values should remain when automatic placement is checked, and be applied once more when it's unchecked.
- There are indeed more elements to consider, especially text elements, but the specific ones you mention are protected from the rest of the score by a vertical frame.
Additionally: Seems like that checkbox should be above the offset boxes, rather than below.
- OK to me
- Yes, that'd be better, I'm just unsure how to achive this
- That's not much of a protection (and doesn't apply to measure numbers)
And yes, the check box makes more sense above the offsets
My easier solution does get all elements that can get dragged, also no need to maintain a (hopefully growing) list of auto-placement-aware elements. It is lacking the restore offsets though, and won't play nicly along with it, I'm afraid.
Seems under the covers the offsets do get reset to 0 when Auto Placement gets ticked, they just don't get updated in the GUI. You see them set to 0 when deselecting and selecting the element again. Strange though that their reset to default button remains active.
Then I guess just get the numbers to update when the box is checked?
OK, see https://github.com/musescore/MuseScore/pull/2775
Werner changed it differently in ceba634, as yet without changes to Inspector, which is a bit of a different issue.
Fixed in branch master, commit 6ba852d027
fix #120641, part 2: Move Autoplace checkbox to above the offsets.
Fixed in branch master, commit ebd1f20d7f
Merge pull request #2775 from Jojo-Schmitz/autoplacement
fix #120641, part 2: Move Autoplace checkbox to above the offsets.
there is still an issue left: draging disabled the autoplace, and sets the x and y offset, as it should, reset to default on autoplace restest to autplace, as it should, but leaves the offests as per the drag, not sure whether that is OK, but when you again uncheck autoplace, the offsets don't take effect, which looks wrong to me. Unselect and select again and those Offsets are 0 so, so we have a display problem in inspector here, and/or a functionality problem, not sure
Another thing, maybe worth a separate issue but maybe not - shoudln't this also apply to moving using the keyboard? I almost never drag anything; I usually nudge.
It should indeed
Speaking of "worth a separate issue," this has been fixed. The numbers in the Inspector are something else.
Automatically closed -- issue fixed for 2 weeks with no activity.
I created the separate issues at #122401: Automatically turn off automatic placement when adjusting element's position via keyboard and #122406: Offset values in Inspector don't reset when automatic placement is turned on, or apply when automatic placement is turned off.