Metacity window placement

21.10.2010 17:13

The other day I was trying to solve my problems with window placement on a multi-monitor Desktop by using separate X screens for each monitor. That did not end well so I reverted back to the usual Xinerama mode, which is as far as I know the default mode on all distributions out there and is therefore much better tested in applications.

This time I turned to the desktop environment, actually its window manager Metacity, to see if something can be done there.

What I found is that all misplaced windows were placed by code that gets triggered by a workaround. The code I'm talking about is src/code/place.c around line 686:

  if (meta_prefs_get_disable_workarounds ())
    {
	...
    }
  else
    {
      /* workarounds enabled */
      
      if ((window->size_hints.flags & PPosition) ||
          (window->size_hints.flags & USPosition))
        {
          meta_topic (META_DEBUG_PLACEMENT,
                      "Not placing window with PPosition or USPosition set\n");
          avoid_being_obscured_as_second_modal_dialog (window, fgeom, &x, &y);
          goto done_no_constraints;
        }
    }

The interesting points here are that:

  1. Workaround is enabled by default (and can be disabled by setting /apps/metacity/general/disable_workarounds gconf key).
  2. If workaround is enabled and an application wants to place a window itself (which Mozilla applications want to), Metacity disregards that request. It then skips most of the smart placing code (for example code that makes sure that windows get grouped on the same monitor) and basically just places the window on the first free spot. Which is usually on the wrong monitor.

So, disabling the workaround actually solves the problem!

The documentation says that workarounds are enabled by default for a good reason and that some applications misbehave and want to place windows all over the place. So far the only side effect I've seen is that applications that hide in the tray (XChat, Rhythmbox) don't remember the position of their windows when reopened (which contradicts a bit my understanding of the code above).

Also I'm not sure why the rest of the constraining logic is simply skipped. If I see some terrible side effects of disabled workarounds I'll probably look into it. But so far I don't see much point in creating a patch. Metacity is kind of forgotten right now while all developers are working on the next best thing (called Mutter, not really usable last time I tried). My trivial patch that fixes title bar for gVIM still hasn't been applied upstream.

Posted by Tomaž | Categories: Code

Comments

Thanks man! Just what I was looking for. I'm using Ubuntu 12.04, but because I couldn't get used to Unity, I fell back to Classic gnome (no effects). No effects because Compiz slows my 3D accel. Metacity performs better. Except the window placement. But that's now solved. :-)

Posted by Joost

I know this is an old post but I am having the same issue. I think what is happening is that with a multi monitor setup and having the mouse active in the secondary display instead of the primary display when switching workspaces, the windows get rearranged. If there was a script or something to quickly set the mouse in the main display before switching workspaces and then restoring the mouse's current position that would solve the issue. As of right now I can confirm that switching workspaces with the mouse on the primary display does not rearrange any tiled windows but then again I am using X-Tile in addition to using this method. I am running Mate on Arch Linux.

Posted by Chad

Chad, that sounds like different issue to me.

It might be related to the same code I mention above (I don't remember details anymore) but I didn't have any issues with workspace switching or windows getting rearranged. What I was talking about is initial placement of newly opened windows.

Posted by Tomaž

Add a new comment


(No HTML tags allowed. Separate paragraphs with a blank line.)