> Basically all plugins implement mapFrameInitialized. Does this > method with two arguments still make sense, when your patch is > applied?
No, my plan was to get rid of it altogether so plugins can simply use Main.map or similar to get the MapFrame. Since it would never be destroyed there would be no need to listen to new map frames. (This is not in the patch yet). > Can you explain the reason for the change in more detail? To display the toolbar buttons, the items in the Windows menu and in the prefs → toolbar dialog they have to be actually present. I.e. they need to be created before they can be displayed and they will be removed if the dialog is destroyed. Without these changes the toolbar buttons/window menu items would become visible if a map frame is created (any layer opened) or destroyed (all layers closed). If found this to be rather uncommon and especially the need to have a map frame open in order to configure the toolbar properly sounded bad UI wise. So what I needed to do was to register the toggle dialogs early. While it would be possible to add an extra hook so that their menu entries can be created before there's an actual map frame I found it to be much easier to simply create the map frame on start and just never destroy it to keep the menu items valid. I found no deal-breaking disadvantages to this, there only appear to be minor bugs and the plugin API will change. > (Btw. it is difficult to read your patch because most of all the > formatting diffs.) Yeah, I know. That's Eclipse enforcing the project's style in files that were created before such rules existed. I'll upload a version without these changes later, but it won't be applicable to your copy. > What about the toggle buttons in the lower left? They could be hidden > by default, with an advanced option, to bring them back. No plans for them this far. _______________________________________________ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
