#6250 closed enhancement (fixed)
[patch] Undo selection - shortcut needed (or access to history list from plugins)
Reported by: | akks | Owned by: | team |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | Core | Version: | latest |
Keywords: | undo selection | Cc: | a.dezhin@…, bastiK |
Description
Discussion on OSM Russia forum shows that there are people interested in Restore selection shortcut (including me).
We know about selection history drop-down list, but shortcut is also needed.
There is no access to this history for plugins (SelectionListDialog.SelectionListModel.history). Maintaining this history is rather CPU and memory- demanding, so we wanted to use the same object.
Can someone from core developers help us?
Some other plugins can reuse last selections and save resources too!
I can use Main.main.undoRedo to select newly added entities, but this is another action.
One more proposal - selecting entities from buffer.
Planned key for Undo selection - Shift-Z.
Attachments (6)
Change History (34)
comment:1 by , 14 years ago
Version: | → latest |
---|
comment:2 by , 14 years ago
Cc: | added |
---|
comment:3 by , 14 years ago
comment:4 by , 14 years ago
Errr.. Patch for core that uses static Main.main.selectionHistory as SelectionListModel.history and exposes it for all users?
Not too radical to accept?
Or just Shift-Z implementation to insert into core, tight linked with SelectionListDialog? (Do not know, how to implement correctly)
comment:5 by , 14 years ago
JOSM has a "expose interfaces when necessary" concept instead of a "designed API". So yes, designing plugin interfaces on-the-fly is a acceptable way to go.
Advantage: Easy to program and maintain, low developer requirements.
Disadvantage: Unstable API forcing plugin updates.
So please design a proper way to access the data (not simply making it public) and supply a patch for this.
comment:6 by , 14 years ago
Can I take Main.main.undoRedo as a good example? (something like singleton)
Or I could add it as getCurrentDataSet().getSelectionHistory(). Is it better? (not not know main conceptions of JOSM construction)
Of course I do not want to expose history of Swing model of certain dialog to plugins)))
by , 14 years ago
Attachment: | selectionHistory.patch added |
---|
patch for core to expose selectionHistory
comment:7 by , 14 years ago
Please review this minimal patch to make save selection history available for all (and apply it to core in some form).
I have also found some strange behaviour - when entities are deleted, they remain present in selection history lists!
I tried to avoid this in Utilsplugin2 addition, but not from 'selection'-triangle-button-menu. It it a feature?
I am implementing cyclic selection of history lists by Shift-Z using patched core.
comment:8 by , 14 years ago
Summary: | Undo selection - shortcut needed (or access to history list from plugins) → [patch] Undo selection - shortcut needed (or access to history list from plugins) |
---|
comment:9 by , 14 years ago
Two issues:
- Better provide an Interface like getSelectionHistory() and if required add...(). Public variables usually require redesigns later. There is no need to involve Main class.
- Cleanup your patches, so nothing remains, which is not wanted (your changes to build.xml).
comment:10 by , 14 years ago
Different dialogs and actions are rather hard to link together.
Are there any good examples of interface usage in JOSM code? I saw only listeners, which are not suitable here, I think.
Projection proj, UndoRedoHandler undoRedo, Preferences pref, OsmValidator validator are still in Main.
Main question - getSelectionHistory() of what class? DataSet maybe?
I sent build.xml intentionally, as a missing simple way to run compiled josm (for NetBeans). Of course I can remove it.
by , 14 years ago
Attachment: | undoSelection_v2.patch added |
---|
patch for core - adds getSelectionHistory to DataSet
comment:11 by , 14 years ago
Please look at new patch, where selectionHistory is moved to DataSet class and is taken from it in SelectionListModel.
build.xml excluded (please include runjosm.xml or something equivalent later - test is not enough)
Most of the changed lines are newly added @Override annotations (Netbeans advice).
UtilsPlugin2 with cyclic UndoSelection is ready and waiting for core changes to be commited (depends on newly added methods).
follow-up: 13 comment:12 by , 14 years ago
Cc: | added |
---|
@bastiK:
Selection list in DataSet sounds good to me. Do you see any side effects?
comment:13 by , 14 years ago
Replying to stoecker:
@bastiK:
Selection list in DataSet sounds good to me. Do you see any side effects?
Sounds good.
- Please provide patches without cosmetic changes, this includes indentation, @Override and the like. If you are using Eclipse, better turn off Save Actions while hacking JOSM.
- the update has to go in editLayerChanged() and not in dataChanged()
- clearSelectionHistory() should move to the DataSet
follow-up: 15 comment:14 by , 14 years ago
You can edit http://josm.openstreetmap.de/wiki/DevelopersGuide/StyleGuide to avoid patches with many-many @Overrides)
Searching other plugins for dependencies.. (moved all clearSelectionHistory methods to DataSet).
Almost ready.
comment:15 by , 14 years ago
Replying to akks:
You can edit http://josm.openstreetmap.de/wiki/DevelopersGuide/StyleGuide to avoid patches with many-many @Overrides)
True, this is from Java 5 times, where interface implementations did not have this annotation.
Searching other plugins for dependencies.. (moved all clearSelectionHistory methods to DataSet).
Almost ready.
Another thing: You should test, what happens if you close selection list dialog, restart JOSM and never open this dialog. I suspect, that selection history will not work then. DataSet has to "take over" completely and the dialog would merely read this list.
comment:16 by , 14 years ago
Here is the patch (and build.xml patch if you consider it - really convenient feature)
If dialog is not created, no selection history is available. But there are no exceptions)
by , 14 years ago
Attachment: | undoSelection_v3.patch added |
---|
by , 14 years ago
Attachment: | undoSelection_v3.2.patch added |
---|
by , 14 years ago
Attachment: | runjosm.patch added |
---|
comment:17 by , 14 years ago
Now one can disable selection history and save processor resources.
If I put part of SelectionListModel closer to DataSet as separate listener, it will maintain history continuously.
This needs much bigger kernel change also and can cause many other potential bugs (messing with at least 4 listeners!)
(we cannot just move setJOSMSelection() and functions calling it to other class, because it also maintains 'selection' - copied collection and two listener methods call it)
So if we need better architecture, you can improve it yourself. I do not want to ruin half of Josm after spending hours)
comment:21 by , 14 years ago
Err.. Can you include current version of the patch?
If no, please give me some advice on implementing listeners (SelectionChangedListener, LayerChangedListener interfaces) in other classes then SelectionListDialog.SelectionListModel.
comment:24 by , 14 years ago
akks: Please take care when committing plugin code, see http://josm.openstreetmap.de/ticket/6201#comment:4 - the same applies for utilsplugin2.
In addition, we have to make sure, that users of "tested" JOSM don't get the new version of the plugin, because it would be incompatible. For this, the Mainversion in build.xml is set to 4064. But please make sure, that the last binary of utilsplugin2 has correct plugin version number in Manifest. If in doubt, just check in the sources and let us update the binary.
Cheers, bastiK
comment:25 by , 14 years ago
OK, I will change version and check it on old josm before committing. Jar and sources will be commited separately.
In fact, I have just noticed, that my last commit (select modified ways/nodes) does not have two source files at all - only jar and png-s (
comment:26 by , 14 years ago
check-in completed.
All of versions gets the correct version of plugin, except 3695 - it install old version and then asks to update If user agree, he gets newest version of the plugin (with MainVersion 4064 in manifest) and one no-working button.
3795, 4011 , 4064 work with their different plugin versions correctly (cleaned JOSM settings folder before running jar and installing Utilsplugin2)
comment:27 by , 14 years ago
Seems to be all right, even 3695 work for me - may be a temporary problem. You can add yourself to the list of authors, if you like.
Patches welcome.