[josm-dev] implementing a windows menu (bug #59)

Paul Hartmann phaaurlt at googlemail.com
Sat Aug 27 13:53:06 BST 2011


On 08/27/2011 01:03 PM, Stefan Breunig wrote:
>> 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.

Still seems to me like an ad hoc change that is not really needed. You
could add proxy actions that are disabled when the mapframe is null.

I like the idea that you can close all layers and memory footprint drops
down to the level after fresh start. There has been some work to get rid
of memory leaks and carefully unregister listeners and so on. This is
probably still possible with your approach, but it complicates things.

Paul



More information about the josm-dev mailing list