Opened 14 years ago
Closed 14 years ago
#6535 closed enhancement (fixed)
Enhancement [patch] Allow plugins to modify default name formatter
Reported by: | Don-vip | Owned by: | team |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Core | Version: | latest |
Keywords: | Cc: |
Description (last modified by )
I want to create a plugin that changes some relations name format (add extra info in brackets at the end of the relation type, like the one added on boundaries with admin_level).
It seems currently not possible without patching JOSM (josm.gui.DefaultNameFormatter):
Change the prototype of getRelationTypeName() from private to protected- Allow JOSM to dynamically instantiate a DefaultNameFormatter sub-class, specified by a plugin or by the user in the preferences. For that, it it possible to modify the getInstance() method.
Please find attached a patch proposal.
Attachments (2)
Change History (9)
by , 14 years ago
comment:1 by , 14 years ago
comment:2 by , 14 years ago
It would be better, yes, but I don't know the JOSM code well enough to modify the patch. Do you have an example of similar factory accessible to plugins ?
comment:3 by , 14 years ago
Something like UploadAction.registerUploadHook? It is used by cadastre-fr, openstreetbugs and reverter plugin. In your case you could just return null whenever you are not interested in formatting the primitive. In would ask all registered Formatters and finally use DefaultNameFormatter as fall back.
comment:4 by , 14 years ago
I have implemented something based on upload hooks in DefaultNameFormatter. It's much better, safer, and allow several plugins to implement format changes :) And there is no need to change methods prototypes :)
comment:5 by , 14 years ago
Description: | modified (diff) |
---|
I recently accepted a patch that does it the same way, but now that I think about it:
Wouldn't it be better to simply register a NameFormatterFactory at Plugin start? When the plugin is removed by the user, there would be no traces left. With the current patch, the preference entry remains and it searches each time for a class that is no longer available.
Another option would be a plugin deinstallation procedure, but this is more error prone, of course.