Compiz switcher Alt-Tab order is not predictable - should maintain LIFO ordering in application switcher

Bug #175874 reported by joehill
64
This bug affects 11 people
Affects Status Importance Assigned to Milestone
Unity
Fix Released
Medium
Sam Spilsbury
compiz (Ubuntu)
Fix Released
High
Jason Smith
Declined for Hardy by Paul Sladen
Natty
Fix Released
High
Jason Smith
unity (Ubuntu)
Fix Released
Undecided
Unassigned
Declined for Hardy by Paul Sladen
Natty
Fix Released
Undecided
Unassigned

Bug Description

Binary package hint: compiz-fusion-plugins-main

In compiz-fusion, the various Switchers have a strange way of keeping track of windows. Let's say I have ten windows open, numbered in order of which I've used most recently (1 being most recent).

Application switcher allows me to switch between the 2 most recently used windows (1 to 2 and back to 1) by simply pressing alt-tab and alt-tab again. After switching, it leaves all windows where they were except the one I've selected. To go to the one I used before these two, I press alt-tab-tab (1-2-3).

Shift switcher does something arbitrary that I haven't figured out yet. In most cases if I just do hyper-tab, it goes 1-2. But if I cycle through more than that, it goes 1-2-8 or 1-2-4. Then what was 1 may get pushed way to the back behind 10 and 7. Most annoying of all, it doesn't just bring the window to the front temporarily as application switcher does, but it permanently shuffles the windows on your desktop, so everything is out of order, especially if I cycle through more than one window. This makes it impossible to quickly switch between two or three windows I'm working actively with, instead bringing to the front things I haven't worked with in hours. Why not just use the same algorithm application switcher uses, keeping track of which windows have been used most recently and leaving all windows except the selected one where they were?

Revision history for this message
positivek (anonyhole) wrote :

I wholeheartedly agree with your report, joehill. The <Alt>+<Tab> behavior of changing windows within the MRU list of apps/windows should be expected. I experience this bug myself. I agree it makes Shift Switcher effectively unusable. Two comments:

 1 - I think sharing an "algorithm" with the other application/window switching mechanisms makes sense. But I believe the actual implementation of tracking or reporting the z-order should also be shared, factored out of _all_ of the mechanisms. Maybe each window manager takes care of this and provides it as a service to apps within? That way this wouldn't even be a Compiz plugin task (the plugin would do the work of graphics, but would get/set the ordering from a shared service).

 2 - Complicating the above comment (1), I believe Compiz's default plugin for "Application Switcher" and "Shift Switcher" allows the user to configure which sets of windows should be included in the switching list. Unfortunately, the implementation of this in Shift Switcher seems different from Application Switcher (which seems to be working correctly in this respect) and Shift Switcher is not behaving properly. This configurability, which I'm not sure if the older (non Compiz) Alt-Tab switching allows, means that the lists may be different across app-switching mechanisms, but the MRU and order-retention *should* be the same. Perhaps a shared implementation could be upgraded to support the Compiz plugins, but with default behavior doing what the old Alt-Tab switchers used to do?

FYI: I am not a Gnome, Compiz, or Linux system coder, but I have experience w/ app architecture and programming. Praise goes out to all those who actually do the fine work on Gnome, Compiz, Compiz plugins, and the rest! So, please take the above ideas with plentiful grains of salt.

Revision history for this message
positivek (anonyhole) wrote :

Does this bug also occur with the "Ring Switcher"?

Revision history for this message
hoganrobert (robert-roberthogan) wrote :

Agreed. Ring and shift switching are pretty unusable because of this bug.

Revision history for this message
myxiplx (myxiplx) wrote :

Yup, just noticed this myself after turning on shift switcher. Having just switched from Windows I was struggling to work out what was going on. Good to hear that the regular Ubuntu application switcher works ok, I'll go turn off the fancy graphics until this is solved.

Daniel T Chen (crimsun)
Changed in compiz-fusion-plugins-main:
importance: Undecided → Low
status: New → Confirmed
Revision history for this message
hotani (hotani) wrote :

I have switched back to using the plain ol boring app switcher because of this bug. Shift switcher looks cool but if it can't keep windows in their proper order, it is useless.

affects: compiz-fusion-plugins-main (Ubuntu) → compiz (Ubuntu)
Changed in compiz (Ubuntu):
importance: Low → Wishlist
status: Confirmed → Triaged
Revision history for this message
Paul Sladen (sladen) wrote :

Mmmm, 3 years. I guess we really should try to fix this if we're going to push compiz out to everyone by default for Ubuntu 11.04.

Changed in compiz (Ubuntu):
importance: Wishlist → High
Changed in compiz (Ubuntu Natty):
milestone: none → ubuntu-11.04
Revision history for this message
Sam Spilsbury (smspillaz) wrote : Re: [Compiz] [Bug 175874] Re: shift switcher should keep track of order like application switcher

On Sun, Jan 30, 2011 at 8:58 PM, Paul Sladen <email address hidden> wrote:
> Mmmm, 3 years.  I guess we really should try to fix this if we're going
> to push compiz out to everyone by default for Ubuntu 11.04.
>

Compiz has always been by default :)

> ** Changed in: compiz (Ubuntu)
>   Importance: Wishlist => High
>
> ** Also affects: compiz (Ubuntu Natty)
>   Importance: High
>       Status: Triaged
>
> ** Changed in: compiz (Ubuntu Natty)
>    Milestone: None => ubuntu-11.04
>
> --
> You received this bug notification because you are a member of compiz
> packagers, which is subscribed to compiz in ubuntu.
> https://bugs.launchpad.net/bugs/175874
>
> Title:
>  shift switcher should keep track of order like application switcher
>
> _______________________________________________
> Mailing list: https://launchpad.net/~compiz
> Post to     : <email address hidden>
> Unsubscribe : https://launchpad.net/~compiz
> More help   : https://help.launchpad.net/ListHelp
>

--
Sam Spilsbury

Revision history for this message
Travis Watkins (amaranth) wrote : Re: shift switcher should keep track of order like application switcher

And shift switcher is not enabled by default anyway.

Changed in compiz (Ubuntu Natty):
importance: High → Low
milestone: ubuntu-11.04 → none
Revision history for this message
myxiplx (myxiplx) wrote : Re: [Bug 175874] Re: shift switcher should keep track of order like application switcher

... and that's enough reason for wildly inconsistent behaviours to be
low priority??

The core UI has to be consistent, I find it incredible that this bug
can be unresolved for so long, and still dropped in priority after all
this time.

Very, very disappointing.

Sent from my iPhone

On 30 Jan 2011, at 17:41, Travis Watkins <email address hidden> wrote:

> And shift switcher is not enabled by default anyway.
>
> ** Changed in: compiz (Ubuntu Natty)
> Importance: High => Low
>
> ** Changed in: compiz (Ubuntu Natty)
> Milestone: ubuntu-11.04 => None
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/175874
>
> Title:
> shift switcher should keep track of order like application switcher
>
> Status in “compiz” package in Ubuntu:
> Triaged
> Status in “compiz” source package in Natty:
> Triaged
>
> Bug description:
> Binary package hint: compiz-fusion-plugins-main
>
> In compiz-fusion, the Shift Switcher has a strange way of keeping
> track of windows. Let's say I have ten windows open, numbered in
> order of which I've used most recently (1 being most recent).
>
> Application switcher allows me to switch between the 2 most recently
> used windows (1 to 2 and back to 1) by simply pressing alt-tab and
> alt-tab again. After switching, it leaves all windows where they were
> except the one I've selected. To go to the one I used before these
> two, I press alt-tab-tab (1-2-3).
>
> Shift switcher does something arbitrary that I haven't figured out
> yet. In most cases if I just do hyper-tab, it goes 1-2. But if I
> cycle through more than that, it goes 1-2-8 or 1-2-4. Then what was 1
> may get pushed way to the back behind 10 and 7. Most annoying of all,
> it doesn't just bring the window to the front temporarily as
> application switcher does, but it permanently shuffles the windows on
> your desktop, so everything is out of order, especially if I cycle
> through more than one window. This makes it impossible to quickly
> switch between two or three windows I'm working actively with, instead
> bringing to the front things I haven't worked with in hours. Why not
> just use the same algorithm application switcher uses, keeping track
> of which windows have been used most recently and leaving all windows
> except the selected one where they were?
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/175874/+subscribe

Revision history for this message
Paul Sladen (sladen) wrote : Re: shift switcher should keep track of order like application switcher

I was reading the various parts of the switcher code on the train today, and doing some testing with:

  for i in $(seq 12) ; do pango-view --font 'Ubuntu 200' --text $i & done

it appears that the very act of Alt-Tabbing is changing the stack ordering, by causing each window to be momentarily raised. A simple test that reflect this is to Alt-Tab-Tab-Tab-Tab-Tab and then Shift-Tab an equal number of times back to the original window. This should cause no change to the stack ordering, but what is actually happening is that all of the windows that have been "touched" will now be moved to the top of the Alt-Tab list, in the reverse order.

Changed in compiz (Ubuntu Natty):
importance: Low → High
Revision history for this message
Paul Sladen (sladen) wrote :

I'm bumping this up to High again; it breaks 25 years of predictable (LIFO) stack operation using Alt-tab across all major competitor operating systems, and all previous Ubuntu releases.

(If it gets set to Medium/Low again, I will accept that judgment and not change it further).

summary: - shift switcher should keep track of order like application switcher
+ Compiz switcher Alt-Tab order is not predictable - should maintain LIFO
+ ordering in application switcher
Paul Sladen (sladen)
description: updated
David Barth (dbarth)
tags: added: compiz-0.9 unity
tags: added: dids-top-ten
Jason Smith (jassmith)
Changed in compiz (Ubuntu Natty):
status: Triaged → Fix Committed
assignee: nobody → Jason Smith (jassmith)
Revision history for this message
Sam Spilsbury (smspillaz) wrote : Re: [Compiz] [Bug 175874] Re: Compiz switcher Alt-Tab order is not predictable - should maintain LIFO ordering in application switcher

We've got something like:

http://git.compiz.org/compiz/core/commit/?id=f77723432c639a659716db95b4b2cd0995574498
in compiz git now - this adds an option to disable focusing the window
each time it is highlighted (which reverses the active order) - by the
next upload I'll do something about allowing us to show that the
windows are active without them really being active.

On Sat, Mar 12, 2011 at 1:29 AM, Jason Smith <email address hidden> wrote:
> ** Changed in: compiz (Ubuntu Natty)
>       Status: Triaged => Fix Committed
>
> ** Changed in: compiz (Ubuntu Natty)
>     Assignee: (unassigned) => Jason Smith (jassmith)
>
> --
> You received this bug notification because you are a member of compiz
> packagers, which is subscribed to compiz in ubuntu.
> https://bugs.launchpad.net/bugs/175874
>
> Title:
>  Compiz switcher Alt-Tab order is not predictable - should maintain
>  LIFO ordering in application switcher
>
> _______________________________________________
> Mailing list: https://launchpad.net/~compiz
> Post to     : <email address hidden>
> Unsubscribe : https://launchpad.net/~compiz
> More help   : https://help.launchpad.net/ListHelp
>

--
Sam Spilsbury

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package compiz - 1:0.9.4git20110322-0ubuntu1

---------------
compiz (1:0.9.4git20110322-0ubuntu1) natty; urgency=low

  * New upstream bug fix snapshot:
    - Application windows can sometimes fail to display and will
      mask regions of the screen (LP: #709461)
    - Compiz switcher Alt-Tab order is not predictable - should
      maintain LIFO ordering in application switcher (LP: #175874)
    - after compiz crashed, gnome-panel isn't mapped again (LP: #711378)
    - invisible windows border problem (LP: #710271)
    - Compiz thinks you are clicking in an edge window when you
      are not (LP: #734250)
    - Add test case for invisible window regressions (LP: #736876)
    - often can't alt-click-dnd to move the focussed dialog (LP: #711911)
    - When windows open for the first time they should not hide (LP: #723878)
    - Unity Grid is broken for multi-monitor setups (LP: #709221)
    - Pixmaps trashed during animations when window is unmapped (LP: #733331)
    - Windows have blank decorations when rapidly closing and
      reopening (LP: #733328)
    - Unity is not restored on unity/compiz crash: compiz doesn't register
      properly with gnome-session (LP: #716462)
  * remove the patch taken from upstream
  * refresh u-w-d patch with latest upstream work
  * debian/compiz-core.install:
    - image move to the final destination
  * debian/patches/100_bump_core.h.patch:
    - bump for ABI breakage
  * debian/compiz-decorator:
    - use gtk-window-decorator and not unity-window-decorator as it's really
      crashy for now (will probably redo an upload tomorrow with a fixed
      decorator)
 -- Didier Roche <email address hidden> Tue, 22 Mar 2011 21:45:34 +0100

Changed in compiz (Ubuntu Natty):
status: Fix Committed → Fix Released
Revision history for this message
David Barth (dbarth) wrote :

Just for the record, since we merged in a new fix this week.

Changed in unity:
assignee: nobody → Sam "SmSpillaz" Spilsbury (smspillaz)
importance: Undecided → Medium
milestone: none → 3.8.2
status: New → Fix Committed
Changed in unity:
status: Fix Committed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (5.9 KiB)

This bug was fixed in the package unity - 3.8.2-0ubuntu1

---------------
unity (3.8.2-0ubuntu1) natty; urgency=low

  * New upstream release.
    - compiz crashed with SIGSEGV in std::_List_node_base::_M_hook()
      (LP: #711916)
    - New window tracking system breaks in the case where windows try to
      restack relative to destroyed windows that were never mapped
      (LP: #723014)
    - does not display icons until hovered (LP: #726033)
    - Unity Launcher has black spaces where icons should be (LP: #729353)
    - compiz crashed with SIGSEGV in sigc::internal::signal_emit0<void,
      sigc::nil>::emit() (LP: #729715)
    - compiz crashed with SIGSEGV in SimpleLauncherIcon::OnIconThemeChanged()
      (LP: #741652)
    - compiz crashed with SIGSEGV in free() (LP: #738864)
    - compiz crashed with SIGSEGV in g_closure_invoke() (LP: #741674)
    - compiz crashed with SIGSEGV in free() (LP: #742300)
    - Unity can't get touch the touch initialization signals from GEIS
      (LP: #742555)
    - Windows that reparent away from the root before they are mapped can
      cause other windows to become invisible (and compiz to crash)
      (LP: #743011)
    - compiz crashed with SIGSEGV in gdk_cairo_set_source_pixbuf()
      (LP: #744231)
    - [dash] Keyboard navigation not implemented as specified (LP: #608132)
    - xterms broken in unity (LP: #692463)
    - Unity opens application menu on Alt+F10 shortcut (LP: #722674)
    - First four items in Dash begin "Find" "Find" "Find" "Find" (LP: #729002)
    - Increase the size of the top left Launcher reveal area from 1px to a
      slightly larger triangle that comes out of the top left corner
      (LP: #736034)
    - Add a test case for invisible windows regressions (LP: #736876)
    - Re-sync with xquerytree to avoid stacking order issues (LP: #740465)
    - Keyboard navigation: quicklist not opening for Trash launcher item
      (LP: #741793)
    - Wrong window moves (LP: #741656)
    - compiz crashed with SIGSEGV in
      SimpleLauncherIcon::ActivateLauncherIcon() (LP: #742110)
    - Combo in the search bar did not disappear after the places was closed
      (LP: #742712)
    - Expo doesn't quit reliably when using keynav or shortcut (LP: #744196)
    - Make the BFB icon turn blue when an application goes urgent
      (LP: #744973)
    - Launcher - increase "launcher reveal %" for 'Fade and slide' launcher
      reveal transition to 65% (LP: #745602)
    - Arrows do not fade out with rest of launcher durring DND (LP: #746811)
    - Don't create windows over the launcher (LP: #688816)
    - Launcher - Indicate which application is currently focused with a
      glowing Launcher icon (LP: #676604)
    - Unity Grid is broken for multi-monitor setups (LP: #709221)
    - dynamic quicklists are not working (LP: #729074)
    - When windows open for the first time they should not hide the launcher
      (LP: #723878)
    - it is still possible to quit unity from the panel (LP: #733725)
    - Selection does not fit small icons in Unity Dash (LP: #735746)
    - Unmounting media gives no error when failed (LP: #737633)
    - ATI/fglrx workaround patch (LP: #740298)
    - "Files & Folders" tooltip say...

Read more...

Changed in unity (Ubuntu Natty):
status: New → Fix Released
Changed in unity:
milestone: 3.8.2 → 3.8.4
status: Fix Released → Fix Committed
Revision history for this message
Ingo Gerth (igerth) wrote :

Great job with fixing this bug dating back to 2007. Isn't it the same with bugs as with killing good whiskey? The older the better.

Changed in unity:
status: Fix Committed → Fix Released
Revision history for this message
MestreLion (mestrelion) wrote :

This bug also affects Maverick... any change the fix can be cherry-picked to it?

Revision history for this message
Steve White (stevan-white) wrote :

This bug or something like it is still present in Ubuntu 12.10, using the shift-switcher anyway.

Say have two windows above other windows, and want to bring a third on top of those two.
Invoke the switcher, bring the third window to the top.
But the previously-top two windows are no longer directly below the new top window -- other windows are between them.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.