Grid placed window overlaps the adjacent viewport

Confirmed. Though I think this may be a duplicate...

Attached a screenshot showing the window overlapping the next workspace by 2 pixels, excluding shadow.

This bug seems to apply to "put left" too. Because if you have a window on the left AND right then the left one overlaps the right one by a few pixels. Probably the same bug; miscalculated width of the grid-placed windows.

A while ago I had a look at fixing this bug. And I partially succeeded but it still felt broken due to bug 925867. I think that one needs to be fixed first.

The other reason I couldn't propose a fix for this bug was because of the much more severe problem of bug 910698.

still same problem here with dualview setup. when using the "put right" thing on the left monitor the windows reaches to the other (right) monitor for some pixels.

uptodate 12.04 with compiz-plugins-main_0.9.7.0~bzr19-0ubuntu2_amd64.deb

http://dl.dropbox.com/u/55796070/out.ogv

This bug still exists in precise and I *think* it may be what's responsible for some weird behaviour I've been experiencing (see video).
There also seems to be another bug in there too (where the grid isn't triggered when it should be ).

This is 100% a grid problem as windows not placed using the grid plugin don't behave like this when their icons are clicked on from another workspace. It also only appears to apply to the right grid on the right hand workspace, but don't quote me on that, although I can't repeat it by putting left on the left workspace.

Same problem here. When grid function is used (aka Aero Snap) right window on second viewport from first row overlaps on first one. This cause some wierd behavior when using Unity switcher (window is moved to first viewport).

Probably already been thought of, but can't bugs like this be fixed by changing the way compiz deals with workspaces.

Metacity under Gnome Fallback (which I use on my netbook as an alternative to Unity 2D), keeps workspaces totally separate. If things are moved to one side and sent over the edge they don't overlap another workspace. It's like each desktop is exactly that, it's own desktop as opposed to the sort of "flowing" model compiz has. Even more so when the window list is set to just show the current workspace's windows.

Couldn't compiz be made to do this, I can see it fixing a lot of problems. I can't see any case where having windows cross workspaces could be practical, actually quite to the contrary as shown by bugs like this. It's not even practical to use it as a tool for moving windows workspace to workspace as the title bar has to be dragged and that's always stuck on one workspace anyway. Expo/switcher and keyboard shortcuts are a lot more practical and convenient (for me at least).

Just an idea... probably over simplifying this a lot here, don't know the slightest thing about the backend of things :P Sorry...

This bug has been bothering me quite a bit, and I'm interested in taking a look at it, although I have never developed for Compiz or Unity before. Can anyone with experience tell me the process with which they would go about fixing this? I'm guessing I would set up a VM with Ubuntu 12.04, compile and install compiz/unity from source. Any tips on debugging compiz in general?

One side effect of this bug (at least, I assume this bug is the cause) is that when using alt-tab on a viewport which has a window from an adjacent workspace intruding 2px into it, selecting the unwanted window causes that window to fully move onto the current viewport.

My hardware setup is a single monitor plugged into an X220 laptop, with the laptop screen disabled (but the monitor is higher resolution than the laptop screen). I'm not sure if this qualifies as "horizontal virtual desktop size" of two or more.

Screenshots of this affecting "put left" are included in bug 1038533.

Still affected by this on Ubuntu 12.10.
compiz-plugins-main: 1:0.9.8.4-0ubuntu3

I just checked out, built, and installed the grid plugin from the compiz project via the directions on http://wiki.compiz.org/Plugins/Grid and it seems to be fixed on my machine now. Not sure how the dependencies are determined in Ubuntu, but any reason we don't just update compiz-plugin-main dependencies to grab a newer version of Grid?

Sorry quick update on repro: It does not repro with nautilus for me, but firefox for instance DOES show the described bug behavior of "Put Right" showing 2px on the adjacent viewport.

Justyn Butler wrote:
> One side effect of this bug (at least, I assume this bug is the cause)
> is that when using alt-tab on a viewport which has a window from an
> adjacent workspace intruding 2px into it, selecting the unwanted
> window causes that window to fully move onto the current viewport.

Yup. Scale (Super-W) does that for me too.

I run GNOME Classic (on precise), and the slight overlap is enough that
gnome-panel registers the window as existing on both workspaces. Unity
doesn't do that, for some reason.

My setup is a single display at 1920x1080.

Don't know if this changes anything, but I felt I should add that under Xubuntu 12.10 this bug also occurs -
the CompizConfig Settings Manager extends too far right when placed with Put Left, and extends off the right side of the screen when placed with Put Right.

Photos of both bugs:
http://i.imgur.com/qWs8nh.jpg
http://i.imgur.com/pt6Dlh.png

Running Xubuntu 12.10 with a single workspace.

The bug also affects me on Ubuntu 12.04. If I semi-maximize a window to the right half of the screen, 2 pixels of the window will show on the workspace to the right of it. Just like Justyn Butler describes, Alt + Tab on the workspace to the right shows the window and if selected moves the window to that workspace.

This bug is reproducible when dragging the window to the right so it snaps to the right half. This behavior doesn't always occur when using keyboard shortcuts. If I press Ctrl + Super + Up (maximization) and then Ctrl + Super + Right, the window will only run over to the right workspace by 1px (this also removes the Alt + Tab problem!). Pressing Ctrl + Super + Right after Ctrl + Super + Left or Ctrl + Super + Down the window runs over by 2px again.

Windows from all programs (nautilus, firefox, terminal) seem to be affected by this,

I noticed that the degree to which the overlap is present on the next workspace is based on the width of the window borders listed in the user's theme. I edited the metacity-theme-1.xml file for my theme to resolve this problem. Simply go to the section of the file listing <frame_geometry name="frame_geometry_normal" ... > and underneath that, set left_width and right_width to 0 (set bottom_height to zero for visual consistency). This gets rid of the overhang, but I think the shadow is still present in the adjacent workspace. Setting the width to anything other than zero leads to an overhang that is twice that width on the next workspace.

Thanks for #13!

Going to http://wiki.compiz.org/Plugins/Grid and following the build instructions not only fixed the problem, but I also have the 1/3.1/4,1/5 Horizontal Splits again! Thank you so much!

One thing I notices was that I got a compile error

fatal error: boost/function.hpp: No such file or directory
compilation terminated.

Which was fixed by installing the libboost-dev package.

Thanks so much!

Hmmm, I cannot reproduce this @ the moment...

I can still reproduce this in 13.10. The edge of the window is still visible on the next workspace. If you "put right" a window and move to the next workspace it's still visible in the alt+tab switcher. It doesn't behave like this 100% of the times now when I'm testing this, more like 50%, I'm not sure if it has something to do with what window is focused when you switch workspace. Although it's clear that this issue still exists.

Fix committed into lp:compiz at revision None, scheduled for release in compiz, milestone 0.9.10.0

Fix Released in Compiz Compiz 0.9.10.0.

This bug was fixed in the package compiz - 1:0.9.10+13.10.20130822-0ubuntu1

---------------
compiz (1:0.9.10+13.10.20130822-0ubuntu1) saucy; urgency=low

  [ Sam Spilsbury ]
  * Bump version to 0.9.10

  [ Łukasz 'sil2100' Zemczak ]
  * Remove debian/patches/unity_support_test.patch:
    - Running the support test from compiz has bad side effects, from now
      on we run it from Xsession.d
  * Automatic snapshot from revision 3644

  [ Iven Hsu ]
  * Opacify: Only dim the windows above the active window.(LP:
    #1189374). (LP: #1189374)
  * KWD: Fix compile errors with KDE 4.11. The KWin developers made
    kdecorationbridge.h private. See:
    http://lists.freedesktop.org/archives/compiz/2013-March/003479.html
    (LP: #1193792). (LP: #1193792)

  [ Nikolay Martynov ]
  * When static switcher is enabled and has an option to show
    application icon turned on the icons are expected to be ~1/3 of a
    thumbnail (48px). Instead they are displayed in 512px size and
    completely cover everything. This change addresses this issue. See
    LP #1173914. (LP: #1173914, #1186426)

  [ BryanFRitt ]
  * Fixed the non-working Annotate 'Clear' Button. Moved this option's
    CCSM position upwards to keep the button shortcuts together. (LP:
    #1202907). (LP: #1202907)

  [ Mehrdad Afshari ]
  * Added "move window to previous monitor" feature to compiz Put
    plugin. (LP: #1178581)

  [ Hu Kang ]
  * gtk-window-decorator: destroy action menu when any of the (close,
    min, max) buttons on the title bar is pressed. (LP: #1101648)
  * Remove redundant src/logmessage/include/core/logmessage.h (LP:
    #1067246). (LP: #1067246)

  [ Steve Langasek ]
  * Fix for bug #763148 (with added test cases): when the desktop is
    resized, windows should stay on their original workspace. (LP:
    #763148)

  [ Brandon Schaefer ]
  * Unrevert 3728, fix failing tests. Change the behaviour of
    undecorating windows. Previously when a window was undecorated, we
    would shift it back to an appropriate position according to its
    gravity member. That behaviour was problematic because in the
    StaticGravity case the window has to just stay in the same place.
    But then if you had a window with StaticGravity which then did get a
    decoration and later removed it, it would be placed as though it was
    decorated and appear to be in the wrong place. The correct behaviour
    is to place all windows as though they have decorations, and then
    when decorations are removed, to move the window back to the corner
    as indicated in its gravity and then expand its size to cover the
    obscured regions no longer hidden because the decorations went away.
    (LP: #1165343).   1. Completely remove decorOffsetMove and other
    related code from      decor.cpp. Put the logic to handle the
    window->input () - window->border ()      placement offset inside of
    setWindowFrameExtents instead. Now the window      will always be
    offset from its original non-decorated position to the new
         decorated position, rather than having to guess between
    decoration sizes.   2. Make saveGeometry and restoreGeometry work
    relative to window->border ()      a...