[patch] Undo selection - shortcut needed (or access to history list from plugins)

[akks]

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.

[stoecker]

Patches welcome.

[akks]

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)

[stoecker]

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.

[akks]

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)))

[akks]

patch for core to expose selectionHistory

[akks]

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.

[stoecker]

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).

[akks]

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.

[akks]

patch for core - adds getSelectionHistory to DataSet

[akks]

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).

[stoecker]

@bastiK:

Selection list in DataSet sounds good to me. Do you see any side effects?

[bastiK]

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

[akks]

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.

[bastiK]

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.

[akks]

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)

[akks]

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!)

[akks]

NullPointerException - patching patch one more)

[akks]

Patch is ready.

[akks]

ready core patch

[akks]

Removed two debugging output lines. Does this patch have a chance? ))

[akks]

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.

[bastiK]

In [4064/josm]:

applied #6250 (patch by akks) - move selection history to dataset

[anonymous]

Thank you) This week I will add UndoSelection action to Utilsplugin2.

[bastiK]

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

[akks]

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 (

[akks]

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)

[bastiK]

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.

[akks]

Thank you)