|Summary:||Window manager, metacity, keeping windows on the visible portion of the screen|
|Product:||Red Hat Enterprise Linux 6||Reporter:||Scott Spurrier <spurrier>|
|Component:||metacity||Assignee:||Owen Taylor <otaylor>|
|Status:||CLOSED WONTFIX||QA Contact:||Desktop QE <desktop-qa-list>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-07-15 21:47:40 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
|Bug Blocks:||782183, 727267|
Description Scott Spurrier 2011-08-29 21:36:22 UTC
For dual-monitor configurations with screens of different resolutions, we'd like the windows manager to keep windows on the visible portions of the screens. The windows manager can/will open new windows in the deadspace (non-visible) parts of the desktop if that is the only area available to it or if the application defaults to that location. The only way to get the window back onto the visible area is to use the "move" item in the pop-up menu from the applications icon on the gnome panel, which impedes workflow if you're using a cintiq as a secondary display.
Comment 3 RHEL Product and Program Management 2011-08-29 22:08:19 UTC
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. If you would like it considered as an exception in the current release, please ask your support representative.
Comment 4 Owen Taylor 2011-09-26 17:33:40 UTC
I'm a little unsure what's going on here. Metacity definitely has code that constrains window placement to monitors - it won't spontaneously place windows into "dead space" just because it is otherwise unoccupied. There may be some combination of application specifics that is causing problems here. Detailed specific reproduction instructions (even if I don't have access to the applications involved) would be useful in understanding this issue further. I'll do some testing this week to see if I can figure out any circumstances in which windows would be placed into dead space.
Comment 6 Owen Taylor 2011-09-26 19:40:24 UTC
Testing with metacity-2.28.0-20.el6.x86_64 (latest RHEL-6 metacity), two monitors +-------------+ +-----------------------+ | 800x600 | | 1280x1024 | | | | | +-------------+ | | | | dead space | | +-----------------------+ With a a terminal filling the left monitor and a maximized firefox filling the right monitor. If I launch a new window without specifying a position: $ gnome-terminal --geometry 5x5 It starts on the monitor where the pointer is, and if the pointer is in the dead space, it starts on the right-hand monitor. (I'm testing with an old X server without the changes to pointer behavior.) If a launch a new window specifying a position: # Geometry on the left monitor # Starts on the left monitor $ gnome-terminal --geometry 5x5+100+100 # Geometry partly on the left monitor. # Starts on the left monitor, pushed into the visible screen $ gnome-terminal --geometry 5x5+100+550 # Geometry in the dead space # Starts on the right monitor, with the specified y $ gnome-terminal --geometry 5x5+100+650 I see the same behaviors if I swap the two screens horizontally, and have the larger monitor on the left. So, I was never able to reproduce a problem with a window being placed into dead space, even when the program explicitly requested that position. Can we get Dreamworks to test if it matters what application is started? Does it happen with a small gnome-terminal window as described above? What is the value of the gconf key /apps/metacity/general/disable_workarounds ? Does it matter for the observed behavior? (I would expect not, but it does chnage the placement code a bit.)
Comment 9 RHEL Product and Program Management 2012-07-10 06:28:14 UTC
This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux.
Comment 10 RHEL Product and Program Management 2012-07-11 00:00:24 UTC
This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development. This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.