Many operation create undo entries although nothing was really done about gtkradiant HOT 6 CLOSED

Hmm... cannot verify this.

I loaded a map into the editor, clicked int the XY View, but the map name (with full path) in the main window's title area does not add an asteric ("*"), denoting you need to save due to changes.

Hitting Ctrl+Z will not really let you test if "internally" a new undo event was added. The poster may have been looking into the source code?

from gtkradiant.

I verified this with 1.4/1.6, try these steps:

• Start with a fresh map
• Create a brush, de-select
• single-click somewhere in 2d view
• press CTRL-Z for undo

Expected: undo last brush creation operation

Result: brush is still there, press CTRL-Z again, now it's removed

from gtkradiant.

Verified your steps. Creepy.

from gtkradiant.

This applies to various other operations too, e.g. x-axis flipping without selection creates an undo entry.

Basically, many operations working on selection do not check whether there's really something to work on but simply create an undo entry an operate on an empty selection.

In c411c8a I introduced Select_HasSelection() which can be used to check this before performing the action.

from gtkradiant.

This introduces function is nice, but has a shortcoming: there are operations which do not strictly depend on "is there a selection at all", but require e.g. exactly two brushes selected.

Others may fail for various reasons other reasons and bail out in the middle.

Still, those functions are surrounded by Undo_Start/Undo_End .

I guess the right fix would be to detect Undo_End whether there was actually a real modification done and discard the entry if not

from gtkradiant.

Closing this one as it's too generic anyway. I've fixed some of the undo bugs, need separate issue for remaining bugs.

from gtkradiant.