GUI usability: incorrect position/layout of selector lists of comboboxes in the popup dialogs when Editting an attribute

[verdy_p]

When editing an attribute value, we can double-click on it from the attribute pane (for example in the value field of a "name" attribute).

This opens a popup dialog which is always centered on screen.

But if we attempt to enter anything in one of the two edit fields of the combo boxes, the selector list popups, but its height is maximized so that it can be as high as the full screen height.

This list is displayed above the edit field which is vertically near the center of the screen, but the selector list which is about the height of the screen is then positioned so that the highest part of it now gets OUT OF SCREEN (above the visible part).

The problem manifests when the list of values if large (for example when editing the value of a "name" tag).

This makes the selector unusable as we can't see the actual value to select (and notably not the first entries in the list which contain bold values used in the current selection of edited objects ).

The only workaround is to open the edit popup dialog (that always appear centered vertically) then manually moving the popup down to the bottom of the screen before editing the fields in the combos.

This workaround is still bad, not easy. It would be safer to either :

• limit the height of the selector so that it won't go out of screen (when the dialog is centered vertically, this maximum height is only about HALF the screen height); or
• allow the selector to appear on top of the editable field of the combo, only if no other value is possible than those being edited), or
• shift the selector list horizontally so that it won't hide the editable field of the combo.

I tend to prefer the first solution which is more natural, even if this limits the height of the selector list (but this list is still scrollable vertically).
Note that the selector list of the comobo may appear below or above the edit field of the combo, depending on its vertical position : which position to use will depend only on the vertical position of the edit field relative to the vertical middle of the screen.

So here are my two requests about this:

1. BUG/DEFECT: Can you adjust this maximum height of the selector list in these editable combo boxes to make them usable in the existing popup dialogs ? -- This is the 1st priority.

2. RFE: Also, couldn't these popup dialogs be avoided by editing attributes (key or value) directly within the "Attributes" pane (on the right of the map) -- This is a second priority.

[anonymous]

Note: for the 2nd request (RFE) you may also look at Ticket #5038.

But please correct the 1st request (BUG/DEFECT) to make sure that the scrollable selector list of an editable combobox will appear in the highest available space (either above or below the edit field), and that they will never go outside the screen...

If the full list can be shown (without scrolling) below the edit field, the list should preferably be below it rather than above. Otherwise you'll choose the above or below position depending on which available space is the highest.

If the combobox is not editable but just selectionable, the scollable selector list may appear on top of the view field and may extend to the full visible screen height.

[Don-vip]

In 5429/josm:

fix #7917 - Control the number of items displayed at once in all comboboxes (20 by default, configurable with gui.combobox.maximum-row-count)

[verdy_p]

Isn't there a way to limit the height of all popups (menus, combolists) according to the available screen height ? Automatically adding a vertical scrollbar when needed ?

Note : the menu for the imagery is easily too high to fit on screen, it should be vertically scollable (just like the Windows Start menus, for example the menu for the Control Panel which is autoscrollable by just hovering the top or bottom of the list).

This should not require any configuration.

[verdy_p]

Note: the default of 20 lines you have set is too high, notably for this bug, where the combobox uses an edit fild that is roughly in the vertical middle of the screen: when you'll open the list, that list will be above or below that middle line, and you cannot expect to display 20 lines in the height of half the screen height. A typical full screen displays about 30 lines, so the default should not exceed 15 lines.

Once again, I just request that when opening the list of a combobox, you compute the available heights above and below the edit field, then use the biggest of those to determine how many lines can fit: you count the number of rows to fill in the box; if these rows fit all in the available space below the edit field, size the listbox to disaply them all and position the list box velow the edit field. Otherwise if the rows all fit above, size and position the list box above the edit field. Otherwise size the listbox to fit the max lines that can be displayed above or below and position the list box accordingly, and enable the list box vertical scrollbar.

Note that this bug also concerns popup menus (notably the lenu for the imagery: they don't fit all vertically, even though they are normally all displayed below the menu bar. But there's already some code that allows the popup menu to move up if it does not fit below the menu bar, meaning that the available screen height below the menu bar is already computed; but still, when the popup menu cannot fit below, it will just be positioned starting at the top of screen, even if it covers the menu (a bad idea in my opinon because the popup menu should not cover the parent menu bar item), but the maximum height of the popup menu is not reduced to fit on the screen, so the bottom of the menu is not visible (and it's impossible to view that part of the menu, simply because the popup menu cannot scroll vertically).

Consider refectoring the way popup menus are also sized and positioned: their behavior should be exactly like comboboxes, the difference being that there's no edit field like in comboxes but it is replaced by the parent menu bar item. The code for handling this sizing and positioning should be similar, taking into account the max screen height and the position and height of the parent field, that the popup menu (or popup list of a combobox) should avoid to cover, choosing the best space above or below that parent field, and in both cases vertical scrolling should be enabled if all does not fit in the largest space above or below the parent field.

Your current "solution" based on a configuration option simply does not work. In fact there's absolutely NO need for any configuration quirk like the one you added, which is complete non-sense. The GUI can be much smarter for popup menus and popup lists of comboboxes for correctly position and size them with a vertical scrolling GUI (preferably not a scrollbar; vertical scrollbars are ugly, even if they work and they take additional horizontal space; I much prefer the behavior with a small top or bottom element added to replace the missing elements, which will "autoscroll" when just hovering it with the mouse, like in the "Start>Control Panel" menu of Windows, not like the "Start Menu>All programs" menu which uses a vertical scrollbar).

Note also that a popup list could also be displayed on the left or right of the parent menu item, if there's enough available space to the left of right of the parent item to fit the list width (and here also, this requires you first know the uncapped list width and height accordingto the list content prior to determining where to display it, and how to cap the size to fit in the screen).

So please REOPEN THIS BUG : it is definitely NOT fixed.

[Don-vip]

Replying to verdy_p@…:

Your current "solution" ... which is complete non-sense.

So please REOPEN THIS BUG

Please lower your tone, this won't make the things go faster.

[Don-vip]

In 5450/josm:

fix #7917 - Control the number of items displayed at once in all comboboxes (replaced configurable method with a dynamic method based on screen height and look and feel)