Re: [JPP-Devel] 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 [EMAIL PROTECTED] 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/vse012070mrt/direct/01/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net 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/vse012070mrt/direct/01/___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Questions on undo/redo support?
Larry, Thank you for your excellent explanation of undo/redo. This makes a lot more sense to me now. Basically we only want to support undo/redo for edit operations that change features and their geometries. Larry wrote: 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. Actually, I stole some code from the PasteItemsPlugIn that deals with this very issue. In summary, my tool will clone selected features when the Send to Destination Layer button is clicked and will send these clones to the destination layer. The clones will not contain references to the original feature geometry. The cloned features will also contain copies of whatever attributes have matching names and datatypes between the FeatureSchema objects of the layers involved. This logic comes from the conform method of the PasteSelectedItems tool. The user will have the option to send only Feature geometries and also whether or not to remove the selected Feature being sent from the source layers. Thanks for the help. Landon On 9/28/07, Stefan Steiniger [EMAIL PROTECTED] wrote: 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. ah yes.. i remember that you found this bug as well in my replicate function. So editing geometries become a bit funny stefan regards, Larry On 9/27/07, *Sunburned Surveyor* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 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/vse012070mrt/direct/01/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net mailto:Jump-pilot-devel@lists.sourceforge.net 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/vse012070mrt/direct/01/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Jump-pilot-devel mailing list
Re: [JPP-Devel] Questions on undo/redo support?
When cloning features there is a clone(deep) method that also clones the geometry Paul - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] Questions on undo/redo support?
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/vse012070mrt/direct/01/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
