Dynamic element text item: snapping/moving

[ChuckNr11]

In #927, the text behavior was adjusted so that the text snaps to the grid. This restores the behavior that existed prior to #365, except that we now have to hold down the Shift key to move the text. In principle, I think it is good that movement in grid increments is possible again.
However, this approach has a noteworthy downside. For example: suppose I want to move my text only upwards. If I start moving it with the mouse, it inevitably snaps to the nearest grid point to the left or right as well, depending on the text's starting position. This lateral movement can amount to half a grid unit, which I personally find quite annoying.
I believe there is a different—and, in my opinion, better—method for moving the text: instead of snapping to the grid, the text moves in grid-unit increments. I have tested and used this approach, and I find it much more pleasant to work with. There is no jumping in an unwanted direction. It also makes it possible to move the element back to its original position.
If desired, the requirement to hold down the Shift key could be removed; the "jumping" of the text—the very issue the Shift key was introduced to solve—does not occur with this method.

What do you think about this approach?

[itseogo]

I think the introduction of the Shift key is a good improvement; before that, if you wanted to move a symbol, you’d often end up moving the text by mistake. In my opinion, doing away with the Shift key isn’t worth it.

[ChuckNr11]

didn't you read:

the "jumping" of the text, the very issue the Shift key was introduced to solve, does not occur with this method.

You are right,

before that, if you wanted to move a symbol, you’d often end up moving the text by mistake

that is precisely why the Shift key was introduced. And that is exactly what does not happen with the variant I proposed.

[ispyisail]

Proposal: give texts their own, finer grid.

Devices and wires keep the main grid. Texts snap to a fraction of it, picked from a dropdown next to Show grid: Off, 1:1 (today's behaviour, the default), 1:2, 1:5, 1:10.

• At 1:5 the sideways jump you describe shrinks from half a grid step to a tenth.
• Texts on different devices still line up, because the text grid divides the main one.
• Holding Ctrl still places a text freely for a single move.
• Shift stays: it stops the text being grabbed when you meant to move the device.

Would 1:5 cover your case?

[ispyisail]

Built it: #1040. The dropdown sits next to Show grid, and also in Preferences › Grille + Clavier. In a test drag from x = −13.3, the sideways jump went from 3.3 at 1:1 to 0.7 at 1:5.

While testing, a short drag that snaps back turned out to break undo for later text moves. That is fixed separately in #1039.

@ChuckNr11, if you can build it, does 1:5 feel right?

[ChuckNr11]

I will test it and report back as soon as error #1045 is fixed.

[ispyisail]

good to go now

[ChuckNr11]

So, I finally had time to test it. Basically, the function seems to work.
Thanks for taking the time to develop this feature, but I think you misunderstood me. Perhaps I didn't express myself clearly; my idea is to move the text in gridsteps without using "snapToGrid". Your solution still relies on "SnapToGrid"—it just allows the moving grid to be made smaller.
I’ve attached a small patch showing how I envision it.

0001-test-moving-in-grid-steps.patch

[ispyisail]

From memory i've done an update and its been pushed. (so many PR i can't remember)