Bug 734251

Summary: Window manager, metacity, keeping windows on the visible portion of the screen
Product: Red Hat Enterprise Linux 6 Reporter: Scott Spurrier <spurrier>
Component: metacityAssignee: Owen Taylor <otaylor>
Status: CLOSED WONTFIX QA Contact: Desktop QE <desktop-qa-list>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.1CC: jwest
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-07-15 21:47:40 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 727267, 782183    

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 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

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 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 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.