Window management - Switching to windows placed on two work spaces causes the workspace to switch

[Saurabh Gupta]

1) Open any application or window on a workspace and move it more than 50% outside the screen's edge so that the remaining part resides on another adjacent workspace
2) Now try to switch to that application or window using alt-tab or window spread the application is brought to focus but the workspace now switches to that adjacent workspace mention in (1) . This workspace switch is not desired.

I have attached a video which demonstrates the problem.

I have narrowed this bug down to the "desktop wall" plugin. If I switch to "desktop cube" plugin using CCSM then the workspaces do not switch while switch to windows/applications which are placed as described in (1)

I am running Ubuntu 12.10 with latest updates. Quantal proposed sources are enabled but the bug is present even in compiz from default quantal sources.

Compiz version : 1:0.9.8.6-0ubuntu1

If any other information is needed I will try to provide it as soon as I can. Thanks.

-----------------------------
Desired solution:

- Do not switch viewport when selecting the window that is more than 50% in another viewport.

- Leave the window in its current position and focus it.

[Arthur Tan (artgtan)]

I followed Sam's steps to reproduce the bug in Precise and noticed that compiz will resize the window entirely in the new workspace.

When clicking on a launcher icon for an open window, Compiz should be aware where an open window is located - workspace 1, 2, 3, 4 - but it actively moves application windows to fit entirely in one workspace. Is this by design?

In other words, suppose you have a window spread over two workspaces. You click on its launcher icon. How does Compiz know which workspace to take you to? Should it be where the majority of the window is located? Or by some other criteria?

[Christopher Townsend (townsend)]

After some investigation, this is due to logic in the WallWindow::activate() function in the Wall plugin code. Disabling that function will keep the window and viewport as-is.

I believe Design wants the viewport switch from happening, but what isn't clear is what should happen to the window in this situation. I will need to follow up with Design on this point.

[PS Jenkins bot (ps-jenkins)]

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

[PS Jenkins bot (ps-jenkins)]

Fix committed into lp:compiz/0.9.10 at revision None, scheduled for release in compiz, milestone 0.9.10.2

[Launchpad Janitor (janitor)]

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

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

  [ Chris Townsend ]
  * Work done by Sam Spilsbury: - Ensure that the frame region is always
    set as soon as the window is decorated. - Further ensure that the
    window decoration isn't needlessly reset if the window already had
    one. - Refactored XShape usage into a common function. - Added tests
    to verify the behaviour of shape set on initially creating a
    decorated window and also upon changing the input frame window
    shape. (LP: #1158267)
  * Alt-Tabbing or Launcher selecting a window that is over 50% in a
    different viewport should not switch the viewport nor change the
    placement of the window. The fix is to add an option to turn this
    behavior on or off. By default, the option is on, but Ubuntu is
    patched to turn it off to fix this bug. (LP: #1092323)

  [ Marco Trevisan (Treviño) ]
  * debian/patches/ubuntu-config.patch: remove grid custom keybindings
    for window management We handle these directly in unity. (LP:
    #992697)

  [ Ubuntu daily release ]
  * Automatic snapshot from revision 3789
 -- Ubuntu daily release <email address hidden> Fri, 20 Sep 2013 11:18:01 +0000

[Saurabh Gupta (bhaismachine)]

I reported this bug earlier and saw that a fix was committed. Today I did a clean install of Ubuntu 13.10 and the bug is still present.

Compiz version : 1:0.9.10+13.10.20131011-0ubuntu1

[Saurabh Gupta (bhaismachine)]

Sorry about changing the bug report status (I reverted it to original status again afterward). I realized that the fix was scheduled to be released in compiz 0.9.11 and Saucy is running compiz 0.9.10.

[Christopher Townsend (townsend)]

Hi Saurabh,

This was intended to be fixed in Saucy, but it is only partially fixed. You should notice that the window will no longer be completely moved to other viewport. I did have a fix that also made it not switch the viewport, but that caused a number of other regressions, so that part did not make it. Unfortunately, the time to fix this correctly was too short since it is going to be much more tricky to account for when to switch viewports vs. when to not switch viewports.

I plan on getting a proper fix for 14.04, but I doubt it can get backported to 13.10.

[Saurabh Gupta (bhaismachine)]

Hi Christopher,

Thanks for your detailed response and thanks for working on this bug. This bug isn't present in the desktop cube plugin so I might try to use it for a while though it's not quite as effect as desktop wall plugin. Is this bug the reason why workspaces have been disabled by default in 13.04 and 13.10 ?

[Christopher Townsend (townsend)]

Hi Saurabh,

> Is this bug the reason why workspaces have been disabled by default in 13.04 and 13.10 ?

No, it was a design decision to disable workspaces by default. I don't know the rationale behind the decision, so I can't speak for why this was done.

[Stephen M. Webb (bregma)]

Workspaces were disable by default in 13.04 because usage studies showed that many typical users found them unexpected and confusing, and that more advanced users who would benefit from workspaces would have no problem opening a configuration window to enable them (even if they had to grumble publicly and complain loudly first).

This bug is in fact a rare corner case, since few people regularly place their windows across workspaces. There are other issues that are more commonly encountered or have a more profound negative effect that demand our attention too.

[Christopher Townsend (townsend)]

I had to mark the 0.9.10.x branch as Won't Fix since we can't SRU this. I do have a proper fix for 0.9.11 so Trusty will have this complete fix.

[PS Jenkins bot (ps-jenkins)]

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

[Launchpad Janitor (janitor)]

This bug was fixed in the package compiz - 1:0.9.11+14.04.20140214-0ubuntu1

---------------
compiz (1:0.9.11+14.04.20140214-0ubuntu1) trusty; urgency=low

  [ Timo Jyrinki ]
  * Bump version to 0.9.11

  [ Marco Trevisan (Treviño) ]
  * debian/00_remove_decor_in_unity_session.py: add migration script
    to avoid to load the decor plugin on compiz startup when using unity.
  * debian/compiz-gnome.gconf-defaults: disable decor plugin on unity session

  [ Sebastien Bacher ]
  * debian/compiz-gnome.links: lists keybinding in unity-control-center
  * typo fix in the previous commit. (LP: #1271710)

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

  [ CI bot ]
  * Flush trunk to Ubuntu

  [ William Hua ]
  * Replace <Primary> with <Control> in CCSM. Fixes
    https://bugs.launchpad.net/compiz/+bug/1069121. (LP: #1069121)
  * Tweak support of key bindings of the form
    '<Modifier>Modifier_KeySym'. We tweak a bit the behaviour of key
    bindings such as '<Control>Shift_L' and '<Alt>Alt_R'. 1. We ignore
    the order of key pressing and releasing, so tapping
    '<Shift>Control_L' is the same as '<Control>Shift_L'. 2. We properly
    handle the double modifiers case, for example '<Control>Control_R'.
    3. We also parse key bindings with '<Primary>' being equivalent to
    '<Control>'.
  * Fix GSettings tests with extra slash.
  * Add an interface for plugins to provide non-option key actions that
    can be triggered.

  [ Eleni Maria Stea ]
  * It fixes the bug #1245886. In DecorScreen::handleEvent compiz
    shouldn't try to handle any events if there's no active window yet.
    (LP: #1245886)
  * Compiz static analysis shows that some compiz classes have virtual
    methods but not virtual destructors. Added the virtual destructors
    to get rid of warnings and potential memory leaks.
  * fixed cmake syntax errors.
  * CMake considered compiz a C++ project and couldn't find some
    dependencies like pthreads. Defined compiz as a C, CXX project to
    fix the issue.

  [ Povilas Kanapickas ]
  * Opacify: Properly initialize window drawing for new windows in
    Opacify plugin. (LP: #787814, part 2). (LP: #787814)
  * Opacify: Fix damage generation in the Opacify plugin. When setting
    opacity to some value, non-opacified windows need to be damaged
    regardless of opacity, whereas opacified windows need to be damaged
    only if opacity changes. Remove u...