(patch needs rework) Dialog menu

[anonymous]

Move toggle buttons for layer, object property, etc. dialogs to a new top level menu called "Dialogs" (same as in Gimp). They are not used very often and we can use the space for other things.

[ramack]

I don't know how useful this actually is - what do you need the space for? But just for the fun of it here is a hacked version of josm: ​http://n.ethz.ch/~rmack/josm/ticket59.jar and a patch
​http://n.ethz.ch/~rmack/josm/ticket59_dialogs_menu.patch for all of those who want to see how it could look.

[stoecker]

Ticket #4390 has been marked as a duplicate of this ticket.

[stoecker]

Ticket #5875 has been marked as a duplicate of this ticket.

[vsandre]

Are there any plans to introduce this?

[bastiK]

i'd say we aren't opposed to the idea

[skyper]

Replying to bastiK:

i'd say we aren't opposed to the idea

I think it would be nice to be able to configure the left panel, or maybe even a window/box somewhere.

• I do not know all shortcuts but some
• I do not use all toggle buttons because I do not need some action and I do never close some.

Few toggle buttons I use quite often, but maybe I would just learn the shortcuts, if the buttons would disapear.

[anonymous]

Replying to skyper:

I think it would be nice to be able to configure the left panel, or maybe even a window/box somewhere.

This is one of the advantages of a separate menu. Because you still able to reach all sidebar elements but with an additional click. Elements of high priority could be send to the tool bar and will be reached within on click, too.

[bastiK]

Nice "screenshot". Also, the lower left corner isn't exactly the best place for buttons that toggle dialogs to the right. Removing these toggle buttons completely would maybe be a too radical step, but this panel could be moved somewhere else, so the distinction between mapmode (select, add, zoom, ...) and dialog toggle is more clear to a new user. (The thin line, that separates the 2 types of buttons is sometimes not noticed.) Any suggestions how this could look like?

[vsandre]

Replying to bastiK:

Any suggestions how this could look like?

This Windows menu is very common in other software products (especially painting programs).

If you want to see some buttons add them to the tool bar.
If you want this buttons on the right of the toolbar add a variable space element (see firefox).

[vsandre]

Replying to xeen

Nice Patch!!! Please remove the toggle buttons from the left, too.

[stoecker]

Two suggestions:

• Allow to configure the display of buttons in left menu (defaults to true)
• When I do a right click into the title line of a ToggleDialog it would be nice when a popup with the toggle dialog selection appears. This would reduce (for advanced users only) the distance between dialog and dialog enable/disable.

If you want this buttons on the right of the toolbar add a variable space element (see firefox).

We have no variable spacer for now and I don't find it in your patch.

Could you modify the patch in a way, that the permanent MapFrame initialisation is not required (i.e. by turning of ToolBar support for now). I think this should be done step-by-step and not too many changes at once. Or do you already have a solution which does not required the MapView init?

[xeen]

• Allow to configure the display of buttons in left menu (defaults to true)

good idea

• When I do a right click into the title line of a ToggleDialog it would be nice when a popup with the toggle dialog selection appears. This would reduce (for advanced users only) the distance between dialog and dialog enable/disable.

I don’t get it. Do you mean the window manager dependend context menu with e.g. move, close, maximize, minimize?

We have no variable spacer for now and I don't find it in your patch.

Yep, didn't include it, although I believe it’s useful outside of the scope of this bug, too. It can be implemented independently of this, though.

I think this should be done step-by-step and not too many changes at once.
Or do you already have a solution which does not required the MapView init?

I have been busy lately, so I could not work on it as much as I’d like. Also, since I still believe initializing the MapView right away makes many things simpler and there were no concrete concerns apart from that stuff might break I decided I won’t work around the issue. My current plan is to move MapView initialization, fix all issues I find and update the plugins if necessary. I’ll add the menu/toolbarbuttons when the former is commited to the main branch and has stabilized.

[stoecker]

Replying to xeen:

• When I do a right click into the title line of a ToggleDialog it would be nice when a popup with the toggle dialog selection appears. This would reduce (for advanced users only) the distance between dialog and dialog enable/disable.

I don’t get it. Do you mean the window manager dependend context menu with e.g. move, close, maximize, minimize?

No. The title lines of the toggle dialogs in right hand menu. A right-click-popup could show a menu, which contains all toggle-dialogs.

I think this should be done step-by-step and not too many changes at once.
Or do you already have a solution which does not required the MapView init?

I have been busy lately, so I could not work on it as much as I’d like. Also, since I still believe initializing the MapView right away makes many things simpler and there were no concrete concerns apart from that stuff might break I decided I won’t work around the issue. My current plan is to move MapView initialization, fix all issues I find and update the plugins if necessary. I’ll add the menu/toolbarbuttons when the former is commited to the main branch and has stabilized.

Is still don't see a reason for such a radical change. It should be possible to have a JosmAction, which is disabled when no MapFrame is active (like many other actions are, e.g. like UploadAction).

[xeen]

It should be possible to have a JosmAction, which is disabled when no MapFrame is active (like many other actions are, e.g. like UploadAction).

It’s about (un)registering those actions. Without map frame JOSM doesn’t even know they exist. So in order to not move the map frame init the following needs to be done:

• move toggle dialog creation somewhere earlier
• update toggle dialogs so they don’t assume the map frame/map view is there on creation
• implement map frame destroyed/created listener for all toggle dialogs

Especially the last point is a deal breaker for me, since it complicates the code for no good reason. Looking at what the map frame class does, it’s pretty much: toggle dialogs + map view + left hand toolbar + some utility features. If the dialogs are moved “up” not much remains and the left hand toolbar should probably be handled the same way as the top toolbar to make moving items between them saner to implement.

Long story short, why not ditch MapFrame altogether?

[simon04]

I am looking forward to seeing the Windows menu to go live :). Unfortunately, there hasn't been an update for 2 weeks.

Is there a way to help the development? Is there a consensus concerning MapFrame?

[stoecker]

Can't we implement this step-by-step leaving the critical parts to the end? I hate to waste already spend efforts.

[stoecker]

In [4590/josm]:

see #59 - patch by xeen - apply parts of the new Windows menu stuff

[akks]

By the way, doesn`t we need another menu for all available MapModes?