Re: Questions on undo/redo support?

Hi SS,

  The undo/redo support is really a java thing that you can support in your tool, but doesn't really make sense for the toolbar undo and redo buttons.  Those buttons are expected to undo and redo edits, not selections.  It also doesn't normally undo layer operations.  For instance you can't undo creating a new layer or removing one.  These kind of operations are easily reversed manually, and implementing them can lead to code that balloons into a huge subsystem that most users don't want anyway.  (Would anyone really want to undo saving a file?)

So, in the example you gave:

[1] Copy selected features to the destination layer.
[2] Clear the current selection.
[3] Delete the copied features from the source layer.

I would say that undo should remove the copied features from the destination layer, restore them to the source layer, but not attempt to restore the selection or remove the destination layer.  It should probably do this in one click of the undo.  There are other plugins that do this same sort of thing, but I can't find one offhand that implements undo.

If you are concerned about losing the selection, what I have done in the past is to implement a Save/Restore selection button.  I guess this would be based on FID in OJ.

Your concern about memory usage is a valid concern.  It seems like you should be able to simply move the features from one layer to the other without deleting and creating, but they probably have different schemas, so that won't work.  You can do it for the geometry, of course, but I'm not sure of the consequences of that.  I still remember the first time I tried to do a copy from one layer to another in code.  I ended up with two features sharing the same geometry.  A potentially useful, but scary concept.

regards,
Larry

On 9/27/07, Sunburned Surveyor <sunburned.surveyor@xxxxxxxxx> wrote:

I've been looking at the steps necessary to add undo/redo support to
the Super Select Tool. I had a question or two about memory usage that
someone who has worked with the undo/redo code may be able to help
with.

How is the memory usage of undo/redo handled in OpenJUMP. For example,
will I be hogging all sorts of memory if I implement an UndoableEdit
that stores information needed to perform the "undo/redo" operation in
memory, and then create a process where the user could potentially
create lots of instances of these UndoableEdits? Does OpenJUMP enforce
some type of limit on the number of supported undo/redo operations or
a memory limit to keep this from happening?

If not, perhaps the smart thing to do is create an UndoableEdit that
stores its data on-disk.

Does anyone have experience combining multiple UndoableEdits into a
single undo/redo operation? As an example, the "send to layer" button
in my Super Select Tool could perform up to three (2) separate
operations depending on how it is configured:

[1] Copy selected features to the destination layer.
[2] Clear the current selection.
[3] Delete the copied features from the source layer.

I don't really want the user to be required to click the undo button
three (3) times to undo what they did with a single click, do I? This
means I have to find a way to combine the three (3) separate actions
into a single UndoableEdit, correct?

Thanks,

The Sunburned Surveyor

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

-- 
http://amusingprogrammer.blogspot.com/
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel