Pressing ESC while dragging a guide triggers an undo

[LucaDC]

These are the steps to reproduce:
 - open a new document;
 - drag a guide somewhere;
 - select the rectangle tool and draw a rectangle somewhere;
 - now with the rectangle tool still selected start dragging the guide clicking inside the origin circle (should not happen, should draw a new rectangle but see bug #1526701);
 - while still dragging the guide, press ESC.

What should happen: the dragging of the guide is canceled and the guide goes back to its original position.
What happens: the dragging of the guide is canceled, the guide _does not_ go back to its original position (i.e. it's just detached from the cursor in the current position) and the rectangle disappears!

I guess that the rectangle disappears because an undo is triggered to have the guide go back to its original position but as the operation is not yet completed, the undo acts on the previous one (the rectangle creation). I didn't look into the code so I may be wrong.

P.S.: the same happens also if you change tool before starting dragging the guide, e.g. the select tool; so there's no relation with bug #1526701. It just happened I noticed this because I wanted to draw a second rectangle starting from the guide origin, had the guide move instead of drawing so I pressed ESC to cancel the unwanted move but: a) the guide didn't go back and b) my first rectangle went away.

[LucaDC (lucadc)]

Inkscape rev.14536, Windows XP SP3.

[su_v (suv-lp)]

Reproduced with Inkscape 0.91+devel r14536 on OS X 10.7.5.

Based on tests with archived trunk builds:
- not reproduced with rev <= 14522,
- reproduced with rev >= 14527;
this regression is related to the changes in rev 14523 to switch guide anchors to SPKnots.

Setting importance to 'high' because of the risk of data loss (unexpected undo of last step done before canceling the not-intended dragging of a guide).

[su_v (suv-lp)]

On 2015-12-16 11:48 (+0100), LucaDC wrote:
> P.S.: the same happens also if you change tool before starting
> dragging the guide, e.g. the select tool;

Can't reproduce this part: dragging a guide within the select tool context is not cancel-able (not with earlier and current stable releases either, so never was). The only thing that 'Esc' in that context does while dragging a guide is deselect any current regular selection.

--
replaces (hidden) comment 3 to fix typo.

[Martin Owens (doctormo)]

This happens because SPKnot handles more events. Pressing ESC didn't do anything before. (so hopefully we'll get a feature out of the fix)

Looking into it now.

[LucaDC (lucadc)]

> Can't reproduce this part: dragging a guide within the select tool
> context is not cancel-able (not with earlier and current stable
> releases either, so never was). The only thing that 'Esc' in that
> context does while dragging a guide is deselect any current regular
> selection.

You have to pick the guide on its origin with the select tool. If you pick the guide anywhere else it works as you described.
 - have a guide in the document;
 - draw a rectangle;
 - press F1 (select tool);
 - pick a guide on its origin and drag it;
 - while dragging, press ESC: the guide detaches from the cursor and the rectangle is deleted.
I just tried this in the document I'm working on.

[LucaDC (lucadc)]

Thank you, Martin.
But please also consider that the behavior of ESC should be the same if you picked the guide in its origin or not. To reinforce this just note that when you start dragging the guide, the origin is moved under the cursor; hence picking the guide in its origin or not, always yelds the same result and users don't need to (so usually don't) pay attention to where they grab guides.

Actually, I can't think about any case where distinguishing the origin from the guide is really necessary.
I think that the origin shouldn't be pickable at all. It's only to be drawn as to know where it is, to see where the guide rotates around and for snapping.

[Martin Owens (doctormo)]

I pre-agree; there's no need for a difference. But if one is gong to have points like this, then we should either show them when the node tool is selected or not at all. I'm generally unhappy with the guide design to be honest. It's all over the place at the moment. (and very inconsistent with other tools)

[LucaDC (lucadc)]

Guides' origins should always be displayed because they're a snapping target and it's hard to snap to something you don't see.
I can express myself only about the UI result of guide design and, being a heavy user of guides, I'm pretty happy with it so, please, be very careful before introducing big changes because you could break use cases. I can't say anything about how it's coded.

[Liam P. White (liampwhite)]

Is this still possible?

[su_v (suv-lp)]

On 2016-01-16 17:20 (+0100), Liam P. White wrote:
> Is this still possible?

On OS X 10.7.5:
- reproduced with rev 14584
- not reproduced with rev 14593

AFAICT fixed with your recent commits (14592, 14593).