GNOME Bugzilla – Bug 153219
dual monitor problems with menus
Last modified: 2018-02-10 03:40:17 UTC
"With any Gaim window on the 2nd monitor, menus pop up on the 1st monitor. I can't use the mouse to select menu items; I must use the keyboard." --sf bug #1031162 " When I open an IM conversation window on my hp omnibook 6100 operating in dual display mode (ATI driver), the im window opens on the secondary window (the laptop display) at the top left such that the title bar is off the top of the screen. I can't grab it to move it to the main panel, nor can I "alt-spacebar" to move it. Secondary display is running smaller than primary (1024x768 and 1200x1024 respectively). Strangely enough, when i start NetMeeting, the window pops down off the top and I can then move it." --sf bug #1021992 with user having windows XP SP1
I would say this may be related to gnome bugzilla bug #123796
Reassigning from multihead to win32 ... the Windows port doesn't do multihead in the sense of multiple separate screens. A lot of bugs like this have been fixed recently; I think the first thing to do would be to test with a recent version of GTK+ for win32.
I had one of our patch writters (Dave West) who had a dual head display available test this, the following is his report. Looks like the problems that those reporters have mentioned are gone. One that I noticed that was interesting is that when you do something that pops up a dialog, it pops up on display 1 instead of display 2 as I would expect. On closer inspection, it seems that at least on my setup (nVidia twinView) the desktop manager that controls the multi-monitor part of it can actually relocate the windows to the proper display. Might be helpful knowledge for twinview folk. That being said, I'm unsure what would happen in a situation to where there are multiple physical video adapters. But that's not what you asked me to test, so I'm done rambling. --dw
I'm seeing this on a Toshiba Protege 3490CT laptop that uses an S3 Savage IX video chipset. I'm running WinXP SP2 with GTK+ 2.4.14. I'm not actually using dual head, the laptop just has the ability.
This is certainly still an issue with 2.4.14. I've noticed that resizing the taskbar causes the offscreen windows to be relocated into the display area. It seems that the windows are being defaulted to be located at (0,0) when created which isn't necessarily on-screen if the Primary Monitor isn't in the top left corner. (0,0) is the top left of the Primary Monitor, not the virtual screen.
*** Bug 165659 has been marked as a duplicate of this bug. ***
Just an update. I bought this laptop used, and have never used dual head myself. I always thought clicking on the second monitor in the display settings would switch to the other monitor. But I finally clicked on it and found that "Extend my Windows desktop onto this monitor" was an option and it was checked. So I was wrong and it was enabled.
According to bug 165302, this also affects GIMP windows.
*** Bug 165302 has been marked as a duplicate of this bug. ***
Created attachment 38581 [details] [review] Patch to make windows that would be created offscreen appear on screen This is by no means an optimal solution, but it seems that it will work to prevent windows appearing offscreen when [0,0] (GDK coords) isn't a visible part of the workspace. A better solution (which would also address Bug #156246) would require retrieving rcWork (the work area rect) from the monitors and using it instead of the physical monitor rect. I welcome any feedback and suggestions.
I experience this issue as well with Gimp and Gaim/Pidgin on Windows. If the second monitor is positioned to the left or above the primary monitor new windows appear there. Being that my second monitor is a tv, this makes things a bit hard to read. Oddly with an earlier version of GTK+ it seemed that new windows always appeared on the second display, regardless of orientation, though now it behaves as above.
Patch applies cleanly. Reviewing it would take little time. (Working on http://mail.gnome.org/archives/gtk-devel-list/2007-March/msg00148.html)
> Reviewing it would take little time. Would it? Reviewing all the GTK+ apps that run on Windows and checking whether this change has any negative impact on their behaviour? Why isn't the same logic needed for other windowing backends?
The comment I posted was automatically generated, without taking the discussion into account. I was referring to the fact that the patch would be easy to look over and check for errors.
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue for it.