Modify

Opened 3 years ago

Last modified 14 months ago

#16530 new defect

Dual head monitor setup: menus and dialogs are on the wrong screen

Reported by: anonymous Owned by: team
Priority: normal Milestone:
Component: Core Version: latest
Keywords: template_report Cc: naoliv

Description

What steps will reproduce the problem?

  1. Open JOSM, download an area
  2. Move the JOSM main window to the second screen
  3. Click a main menu item or open a dialog

What is the expected result?

Menus and dialogs are displayed on the main window screen, except the user moved the dialog to a suitable position before (then remember this position, see bug #13939)

What happens instead?

Menus and dialogs are always shown on the first screen where the JOSM main window was before.

Please provide any additional information below. Attach a screenshot if possible.

see also bug #4925 for an X11 system. I'm on Windows 7.

Attachments (0)

Change History (9)

comment:1 Changed 3 years ago by Don-vip

Owner: changed from team to anonymous
Status: newneedinfo

Thanks for your report, however your ticket is incomplete and therefore not helpful in its current form.

Please add all needed information according to this list:

  • The required parts of the Status Report from your JOSM.
  • Describe what behaviour you expected.
  • Describe what did happen instead.
  • Describe if and how the issue is reproducible.
  • Add any relevant information like error messages or screenshots.

To ensure that all technical relevant information is contained, create new tickets by clicking in JOSMs Main Menu on Helpsource:trunk/resources/images/bug.svg Report Bug.


comment:2 Changed 3 years ago by Don-vip

Resolution: needinfo
Status: needinfoclosed

comment:3 Changed 2 years ago by anonymous

Resolution: needinfo
Status: closedreopened
Version: latest

Same here. When JOSM moved from the primary display, the newly opening UI elements (even the menu bar) still show up on the primary monitor instead of on that display where JOSM is.

JOSM 14760

OS Name:    Microsoft Windows 10 Pro
OS Version: 10.0.17763 N/A Build 17763

java version "1.8.0_201"
Java(TM) SE Runtime Environment (build 1.8.0_201-b09)
Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, mixed mode)

comment:4 Changed 2 years ago by anonymous

Owner: changed from anonymous to team
Status: reopenednew

comment:5 Changed 2 years ago by anonymous

Steps to reproduce:

  1. Get a second monitor, if you currently doesn't have
  2. Open JOSM. It will open on your primary display.
  3. Move JOSM entirely to the secondary monitor.
  4. Try using it. Almost every new UI element will be on your primary.

comment:6 Changed 16 months ago by johsin18

I use two screens with Windows 10, with the added complication that they have different scaling factors (200% on the primary HiDPI laptop screen, 100% on the secondary desktop screen). Under theses circumstances, JOSM dialogs (e.g. the history dialog) are spawned such that parts of the are outside of any screen. And even if the window is resized and dragged to the right position, that position is not remembered (at least not in a correctly).

==========

History...

Similar bugs have been filed multiple times
https://josm.openstreetmap.de/ticket/13939 (has a video showing the problem, still open)
https://josm.openstreetmap.de/ticket/13166 (closed as duplicate)
https://josm.openstreetmap.de/ticket/4925 (still open, for ages)

==========

Looking into the JOSM code...

WindowGeometry.getScreenInfo has a comment saying
/* default: something on screen 1 */
which probably means "primary screen" and would support that the bug still exists.

The Javadoc of WindowGeometry.centerOnScreen says "where main window is", but I don't think that's actually implemented.
It rather looks for a screen intersecting with new Point(0, 0), new Dimension(10, 10), which would be the primary screen.

All this code comes from an 8 year old commit ("better handling of dialogs for multiple screens")
https://github.com/openstreetmap/josm/commit/d72aa28f07ee6fb0d70895dfd9fb25a0176f5f26

==========

Contributing to the problem...

Java's Rectangle.intersect returns a result rectangle with negative dimensions instead of an empty rectangle as documented:
https://stackoverflow.com/questions/23848592/java-awt-rectangle-intersection

Varios unfixed bugs on Java side:
https://bugs.openjdk.java.net/browse/JDK-8229813
https://bugs.openjdk.java.net/browse/JDK-8222210

GraphicsConfiguration.getBounds returning inconsistent results for screens with different scaling, e.g.
(0,0)+(1600,900)
(3200,0)+(1920,1200)

==========

I hope I can come up with a portable fix for this mess...

comment:7 Changed 16 months ago by naoliv

Cc: naoliv added

comment:8 Changed 16 months ago by stoecker

I'd propose you try an java update first. Something above 11. I'm using JOSM for several years now on different OS (Windows and Linux) and JAVA versions and it works as expected on many systems for dual screen setups.

As JOSM does not calculate the position of menus (but only positions of windows/dialogs/...) as JAVA does this itself, there is little chance the bug is in JOSM code.

comment:9 Changed 14 months ago by johsin18

True, the menus are fine. But the dialogs are not, as described for the mixed-scaling setup. This includes that in certain setups, they open on the first screen while the main program is open on the second one (topic of this bug). Remembering those positions using getLocation/setLocation does not work, I have filed a JDK bug on that problem (tried with many Java versions >=11, including 15 EA):
https://bugs.openjdk.java.net/browse/JDK-8237924

Last edited 14 months ago by johsin18 (previous) (diff)

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The owner will remain team.
as The resolution will be set.
to The owner will be changed from team to the specified user.
The owner will change to anonymous
as duplicate The resolution will be set to duplicate.The specified ticket will be cross-referenced with this ticket
The owner will be changed from team to anonymous.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.