Reduce space in right-handside menus

[stoecker]

Currently the menus in the right side use a lot of space and it is sometimes hard to see the relevant content. I think howto fix this for a while now and I think I found a solution below.

Nearly all of these follow the structure of a data display and a button row below. Now the button row is not really necessary most of the time. So a great improvement would be, when this buttons are displayed only when needed.

Idea:

• Allow to separate the display part and the buttons in ToggleDialog.
• Find a possibility to activate the buttons only when needed (make configurable!)
  • Display when mouse is over the relevant menu section
  • Slightly expand the display, so the buttons find enough space for display

We could step-by step update the ToggleDialogs, so this new features needs not break plugins.

Comments?

[xeen]

hiding the buttons and only displaying them when hovering the dialog seems to be a bad idea in my opinion. Either I need the buttons when using the dialog, so they should be displayed or I don't need them in which case they shouldn't be displayed at all. Also I don't get the advantage of splitting a toggle dialog into two toggle dialogs with one containing the buttons and the other containing the content.

I have a few other suggestions: If a td contains only a few lines that don't change very often they should only be as high as required to display their content. Examples are the layer diag which for me only ever displays up to three lines of content (GPX+OSM+Satimg) and the map paint styles dialog.

Since we moved to Java 6 dragging could be introduced to replace up down buttons. Take the mappaint td as an example: It has 4 buttons: toggle, up, down and preferences. Toggling already works using the checkbox in front of each entry and could become even simpler by catching double clicks. Up/down may be replaced by dragging and the pref button could be replaced by an "additional mapstile" called "configure…" or similar.

The properties dialog could work without any buttons if it were an editable table like in the relation editor. I fear that this makes it less obvious though how to use it. We could however move the buttons to the right hand side (i.e. vertically) because all new monitors are wider than heigh.

Neither of suggestions will work for any td tough as they are very specific. Another thing that would save a few pixels is to get rid of all the insets and replace them with a small line between each dialog. It probably won't get much more than one additional line but it would make look JOSM cleaner :)

PS: cc'ing didn't work, i.e. I didn't receive an email. I stumbled across this bug by chance

[stoecker]

Replying to xeen:

hiding the buttons and only displaying them when hovering the dialog seems to be a bad idea in my opinion. Either I need the buttons when using the dialog, so they should be displayed or I don't need them in which case they shouldn't be displayed at all.

Well, that's the idea. When you work in the map, you don't need the buttons at all, so don't display them (in this mode only the informational part of the dialogs is really needed). When you hover the dialog you may need the buttons of this dialog, so enable them.

Also I don't get the advantage of splitting a toggle dialog into two toggle dialogs with one containing the buttons and the other containing the content.

Seems you misunderstood this. Not splitting the dialog into two, but splitting the internal layout according to its function into display and button-row, so we can handle button row design and placement in ToggleDialog. Currently the caller is complete in control and we cannot handle buttons different without touching everything. This is anyway needed for any changes we want to do with the buttons. Equal to left hand-side, where I once splitted buttons into toogle and mapmode buttons.

Since we moved to Java 6 dragging could be introduced to replace up down buttons. Take the mappaint td as an example: It has 4 buttons: toggle, up, down and preferences. Toggling already works using the checkbox in front of each entry and could become even simpler by catching double clicks. Up/down may be replaced by dragging and the pref button could be replaced by an "additional mapstile" called "configure…" or similar.

Reducing the number of buttons does not help, as even a single button needs the same space.

The properties dialog could work without any buttons if it were an editable table like in the relation editor. I fear that this makes it less obvious though how to use it.

This would be a drawback in user interface. Most people never find these "hidden" features.

We could however move the buttons to the right hand side (i.e. vertically) because all new monitors are wider than heigh.

This would be a solution, but very likely it will result in troubles in vertical size.

[xeen]

I see your point. However, these interfaces are hard and I don't know of any other software that uses it. We essentially add a no-work area to the map view because you don't control the cursor accurately enough and will hit the dialogs causing visual change, which will be distracting. Adding a delay so accidental moves don't cause any action are annoying when you want to use the buttons. Also what happens when you shoot for an item which then gets hidden under a button?

I'm not saying it won't work, just that there will be a lof of problems that need to be adressed/tuned before the solution becomes better than the one now (just hiding not so important diags).

A intermediate no brainer would be to reduce the button height. I guess the ones in the selection diag are only about 2/3 of the ones in other dialogs.

[stoecker]

In [4353/josm]:

see #6731 - introduce better layout function for ToggleDialogs, changed author and relation dialog

[stoecker]

I did the first step: separate the button row and the content (currently only for 2 dialogs). Looks much cleaner now :-)

Now we can experiment with better ways to display the elements.

[stoecker]

In [4354/josm]:

see #6731 - reduce space required for SideButtons, moved arrow creation into SideButton class

[stoecker]

In [4355/josm]:

see #6731 - add dynamic button visibility (needs dialog.dynamic.buttons=true)

[stoecker]

I implemented it in r4355 (disabled by default). Actually I find this quite useful. Much more available space without real drawbacks.

[xeen]

I'll try mapping with this enabled on a small screen the next few days and see how it'll turn out.

[bastiK]

Agree with xeen that the dynamic button visibility is quite unconventional. I didn't expect much, but now that I've tried it, it's actually quite useful. Not sure it should be enabled by default, though. (Maybe depending on screen height?)

I could imagine a tiny symbol at the right side of the button row, where you can collapse and expand the buttons for each dialog individually. Or configure dynamic button behavior from the right click menu of the buttons.

[simon04]

A thought on the Filter and Map Paint Styles toggle dialog (based on assumption):
After setting up filters/styles, most users will use these tds only to enable/disable filters/styles. If enabling/disabling could be performed in a (toolbar) menu using checkboxes, the tds could be hidden. Thus, some space could be saved.

[simon04]

#3645 (Photoshop like tab) seems related. I needed to checkout how that looks in action (cf. ​http://superneck.tumblr.com/post/3639857024/using-the-tab-key-to-toggle-the-photoshop).

[xeen]

bug: buttons shouldn't be shown when the dialog is minimized

[stoecker]

In [4366/josm]:

see #6731 - handle collapsed menu correctly

[stoecker]

Replying to bastiK:

Agree with xeen that the dynamic button visibility is quite unconventional. I didn't expect much, but now that I've tried it, it's actually quite useful. Not sure it should be enabled by default, though. (Maybe depending on screen height?)

I could imagine a tiny symbol at the right side of the button row, where you can collapse and expand the buttons for each dialog individually. Or configure dynamic button behavior from the right click menu of the buttons.

A per dialog changing of this behaviour sounds like a good idea to me.

[vsandre]

The mouse movement into the toggle window reduces the visible space of the table and it is not possible to select something from the lower lines. Please consider showing the button in front of other toggle windows at the bottom of the current window. So the table space do not have be resized.

[stoecker]

The mouse movement into the toggle window reduces the visible space of the table and it is not possible to select something from the lower lines

There is no difference to select lower lines. The dialog is a scroll pane like it would be if the buttons are displayed all the time. But I agree, that it is very strange to reorient selection tasks after the buttons appear.

I also thought already about showing the buttons below the current window, thought I have no idea yet how to do this.