with multi-monitor setup arrows aren't displayed in drop-down menu

[goo@…]

Repository Root: http://josm.openstreetmap.de/svn
Build-Date: 2014-05-26 07:29:16
Last Changed Author: akks
Revision: 7182
Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
URL: http://josm.openstreetmap.de/svn/trunk
Last Changed Date: 2014-05-26 09:22:25 +0200 (Mon, 26 May 2014)
Last Changed Rev: 7182

Identification: JOSM/1.5 (7182 it) Linux Ubuntu 14.04 LTS
Memory Usage: 228 MB / 2672 MB (173 MB allocated, but free)
Java version: 1.7.0_55, Oracle Corporation, OpenJDK 64-Bit Server VM
Java package: openjdk-7-jre:amd64-7u55-2.4.7-1ubuntu1
VM arguments: [-Djosm.restart=true, -Djava.net.useSystemProxies=true]

When using a multi-monitor setup arrow keys aren't displayed in drop-down menu, thus not allowing the user to select items outside the visible part of a drop-down menu.

Reproduceable: always

[Don-vip]

Can you please attach a screenshot and tell us about your screen resolutions?

[goo@…]

In the first image, with a stacked multi-monitor configuration (but actually I have reproduced this with _any_ multi-monitor configuration with resolutions from 1920x2280 as shown here to 2970x2280), the drop-down menu lacks an entry to let the user select the hidden menu entries.
In the second image, with a single-monitor setup the drop-down menu has the arrow keys to let the user to scroll up/down, as expected.

Only starting josm with a single-monitor and switching to a multi-monitor configuration afterwards, let josm retain the arrow-keys in the drop-down menus.

I have reproduced this with Ubuntu 13.10 and 14.04.
As a side note, multi monitor setups are driven by standard RANDR protocol, as I am running plain Xorg with open drivers.

[stoecker]

NOTE: I changed the username to no be an e-mail address anymore, as there are constant delivery failures for that address.

[Don-vip]

looks like specific to KDE, I cannot reproduce on Windows.

[stoecker]

Reproducable here with a 1920x1200, but only with stacked setup, not side-by-side. It seems for the buttons the full screen height is used instead of the height of one single screen.

[stoecker]

Sorry, closing was an error :-)

[goo@…]

Replying to stoecker:

Reproducable here with a 1920x1200, but only with stacked setup, not side-by-side. It seems for the buttons the full screen height is used instead of the height of one single screen.

I found this reproduceable also with two side-by-side monitors with the right one [1050x1680] rotated by 90degrees and thus with a longer height then the left monitor [1920x1080]. On the left monitor josm application window exposes menus longer then the available screen height. After moving the application window to the right screen the menu is fully visibile thanks to the higher screen height.

Generally speaking it seems that josm adapts the menus height to the longer screen height available in the multi-monitor setup, forcing the user to use josm on the screen with the higher screen height or, in the case of a stacked setup, on the top most screen only to have fully visible menus.
To me this is suboptimal as I'm used to work on the main monitor at the bottom of the stacked setup. At least, menu height should be limited to the lower display height of the multi-monitor configuration, to let the user work with josm on whichever screen he prefers.

I've also reproduced this behavior with other window-managers (openbox, fvwm), so it doesn't seem to be KDE related.

[stoecker]

What about that: Use the buttons and change menu size according to window with and not screen width? Vincent, do you know where the relevant code is?

[Don-vip]

Somewhere in source:trunk/src/org/openstreetmap/josm/gui/MenuScroller.java​ I suppose. Screen height should be ok we just need to be sure to use current screen information :)

[skyper]

Well, #8881 looks similar with only on screen but a top panel (Gnome3).

[Don-vip]

In 7291/josm:

fix #10207 - fix menu scroller for multi monitors systems

[stoecker]

One note - I think the Geometry stuff should be in WindowGeometry class, as this already contains some workarounds for specific setups.

[Don-vip]

I agree with you but in this specific case, I didn't see how to make it fit in this class as it is unrelevant to Window(s)...

[stoecker]

There is already an "private static Rectangle getScreenInfo(Rectangle g)". Adding another static function getting the screen information or reusing an existing one instead of directly accessing the GraphicsConfiguration should be enough. Reason is to have all that at one place, so that necessary workarounds will catch all cases.

[Don-vip]

I got some regressions on laptops with lower resolutions than my main machine.

[Don-vip]

In 7346/josm:

fix #10207 - UI tuning in menu scroller: ignore JSeparator in scroll count

[goo@…]

Today I found out that submenus of menus longer than the actual screen height are hidden.
I get this on the "imagery" menu where I can't get to the items belonging to a submenu of imagery.

Reproduceable: always, either with a single monitor or a multi-monitor setup

josm-latest 7451

[anonymous]

Forgot to say that submenus of menus not exceeding the screen height are normally viewable.

[Don-vip]

I know see #10392 / #10397.