Store and restore selection with undo state

[jajajaneeneenee]

Vespucci Version

20.1.0 Beta5

Download source

Google Play Store

Device (Manufacturer and Model)

Samsung A33

Android Version

14

Behaviour/Symptoms

This is quite high on my list of small problems in Vespucci that occur on pretty much every one of my mapping days (a small but annoying problem that has existed for quite a long time – it is not specific in 20.1.0 Beta5):

If you select a node to join it to another (already existing) node using the JOIN/MERGE tool and then press UNDO, the wrong node is selected – not the one selected at the beginning, but the one to which the selected node was joined.

This happens to me a lot in the typical case where the selected node is not connected to the node you wanted to connect it to, but to another node that is too close to it (and the zoom level was not high enough). Then you just want to press UNDO, zoom in closer, and then connect the node to the one you want. Now you have to first select the correct node again ...

Here are some screenshots of a simplified example (only with 2 nodes):

Expected Behaviour

The node selected at the beginning should be selected again after the UNDO of the JOIN.

[simonpoole]

The information which object is selected is not stored with the undo information so can't be recreated. As changing this (in any form) would require a state file format change, this will require a major version release to change (if it actually makes sense overall).

[jajajaneeneenee]

Really? That doesn't sound good ... I really thought this was a small thing.

And basically: I don't think it's correct to assign the label "Enhancement" here, it's clearly an undo error and therefore a bug. And really not a good user experience. And what did you mean with "if it actually makes sense overall"? Why shouldn't it make sense to correct this?

Note: if I connect a node to (the middle of) a way and undo this, then the previously selected node is also selected – purely from a user perspective (of course the most important perspective), this should also be the case when connecting to another node and undoing ...

And this case happens to me really often that a node is connected to the wrong node (or several) when the zoom level is too low ... And it's really annoying that you then have to select the correct node again.

[simonpoole]

"if it actually makes sense overall"? Why shouldn't it make sense to correct this?

Because there are situations in which you wouldn't want to restore the stored selection, for example essentially all cases where you are undoing selectively.

[jajajaneeneenee]

OK, I understand ... I thought you mean only this particular case. But you have probably already thought further about a general change in the undo architecture.

After many years of using Vespucci intensively, this case with the join-unjoin, where the previous selected node should be retained, particularly catches my eye.

Because now an undo does not just undo the last step (join), but an undo join PLUS a "select another node than before" takes place (purely from the user's perspective), which is very strange.

So something happens that from the user's perspective would otherwise be 2 steps that I would have to do (e.g. if I undo the movement of a node + then select another node). So this feels very much like a bug. Then it would be almost better if nothing was selected after the undo.

Otherwise, I can't think of any case where preserving or restoring the selection in undo steps would be important to me. (But maybe there are others.) Therefore, I wonder whether this really needs to be recorded in the undo history. Or whether a simpler, pragmatic solution might make sense here.

I would even go so far as to consider this join-unjoin case as a special case and code a workaround for it, if that is easier than changing the entire undo architecture. And maybe even only if the last step is undone, i.e. pressing the undo button after a failed join with a node other than the desired one (due to insufficient zoom).

Another general thought on this join problem and the GUI:

It would of course be even better if these "wrong connections" due to insufficient zoom could be prevented or minimized, e.g. by displaying a temporarily enlarged view with the connection points in question, where you could precisely select the desired node - or all or a selection. But that might be too complicated ...

Or if this type of connecting two (or more) nodes would be possible, which I used very often in JOSM for precise and controlled node connection - there with the shortcut M for "Merge nodes":

• Select the first node (or multiple nodes)
• At the end select the target node (then you have a multiselect of 2 or more nodes)
• Then select "Merge nodes" => All selected nodes are merged with the target node

(A feature request issue would probably be necessary here, I know. If you think it would have a chance to be realized, I could create one.)