[josm-dev] Reusing conflict panels for conflation plugin

[Paul Hartmann]

Josh Doe wrote:
> I'm back to working on a UI for performing conflation as I've
> mentioned on this list before. Right now I've got a series of tabs,
> the first allows the user to freeze/restore two selections ("Mine" and
> "Theirs"), the next configures the matching options, and the third
> presents the results.
> 
> The results are the most important, and what I'm thinking about doing
> is having a table which shows the matched pairs, including the
> distance between them, and then below that table reusing the TagMerger
> panel. The user can select any row (matched pair) in the list, and the
> tags will then be shown to be merged below. Some enhancements could
> include a popup/context menu to allow applying the same operation to a
> selection of pairs, with options like "My Tags, My Geometry", "My
> Tags, Their Geometry", "Their Tags, My Geometry", and "Their Tags,
> Their Geometry".
> 
> Is reusing the TagMerger panel good practice? I think the only thing I
> don't like is the "local dataset"/"server dataset" labels, but if
> that's the only issue it's not worth maintaining a nearly identical
> copy.
> 
> Two reasons why I don't want to use the existing conflict dialogs is
> because sometimes I'll be merging disparate primitive types (e.g. a
> node with a way), and also the current system is not suitable for
> rapidly moving through hundreds of conflicts.
> 
> Any suggestions are appreciated.

When in doubt, just copy & paste. The code can still be refactored and unified later.
For small changes, like the text label, you can send us a patch that adds:

protected String getLocalDatasetText() {
   return tr("local dataset");
}

then, override this method in your plugin. (But within reason, the code shouldn't get too cluttered.)

There hasn't been much development related to conflicts lately. So if you can help to add batch resolution of conflicts, I'm probably not the only one who would be very grateful.

Paul