Do

Docky does not preserve window stack (z?) order when switching apps by clicking on app icon

Bug #326661 reported by Jonathan Austin on 2009-02-07
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Do
Wishlist
Jason Smith

Bug Description

Using rev 943, Docky doesn't remember the order that windows were stacked in when I switch applications...

For example. Compose email in Claws mail (compose window is on top of main window)
Switch to Firefox (fullscreen) to find some info for the email
Switch back to claws by clicking on the claws icon in the dock
--> Main window is focused, sometimes on top, not the compose window.

This is sad as I then have to use a more tedious method to find my compose window again (eg right click on docky or use compiz's scale plugin...)

I've just tested this a few times to be sure and the problem seems to be that the main window is focused, which sometimes causes the compose window to end up behind.

If I, for example, go Claws Compose --> Firefox-->Claws (main window gets focused, compose still on top) {do nothing} --> Firefox --> Claws again then the compose window certainly and reliably gets lost behind the main window.

Alex Launi (alexlauni) wrote :

We just commited a feature which lets you use your mouse wheel to change windows, that should basically fix your problem.

Changed in do:
assignee: nobody → alexlauni
importance: Undecided → Wishlist
milestone: none → 0.8.1
status: New → Fix Committed
Massimo Tisi (massimotisi) wrote :

The wheel feature is very useful but it does not fix the problem.

When clicking on a docky icon the windows of the group should appear in the same order the user left them. Especially the top window should remain the same, to allow the quick switch between windows in different groups.

Jonathan Austin (mailforwho) wrote :

I think Massimo is right, the scroll is awesome but it doesn't really fix what is rather counter intuitive behavior.

This is especially relevant when programs have dialogues that need to be attended to but don't necessarily get forced to the top - you wonder why your app is hanging before realising that there is a dialogue somewhere that got lost from on top when you switched apps.

Jason Smith (jassmith) wrote :

Re-opening as this is a real problem. However I am removing the 0.8.1 milestone since it is highly unlikely this will get fixed in time for that.

Changed in do:
assignee: alexlauni → jassmith
milestone: 0.8.1 → none
status: Fix Committed → Confirmed
Jason Smith (jassmith) wrote :

I lied, i fixed it

Changed in do:
milestone: none → 0.8.1
status: Confirmed → Fix Committed
Jonathan Austin (mailforwho) wrote :

This makes me very happy :) Thanks

Jonathan Austin (mailforwho) wrote :

I think this introduced 'double reversal' when restoring a minimised app, as when minimising and restoring now I get my windows in the wrong order.

Just for fun, and to test how to do it, I (think I) fixed this and (I think I) made a patch - though the fix is trivial and I know a patch isn't worth it! (line 81 in WindowControl.cs) ... Is this how to do patches?

(note that there seems to be some weird behavior if the Do is restarted when lots of windows are already open. If Do is started while there are 6 windows open it doesn't either reliably invert the order (in the case of trunk) or get it right (with this fix) but once you click on each window once (or scroll through them) then it works fine)

Who

What window manager are you using?

On Wed, 2009-03-04 at 20:53 +0000, Who wrote:
> I think this introduced 'double reversal' when restoring a minimised
> app, as when minimising and restoring now I get my windows in the wrong
> order.
>
> Just for fun, and to test how to do it, I (think I) fixed this and (I
> think I) made a patch - though the fix is trivial and I know a patch
> isn't worth it! (line 81 in WindowControl.cs) ... Is this how to do
> patches?
>
> (note that there seems to be some weird behavior if the Do is restarted
> when lots of windows are already open. If Do is started while there are
> 6 windows open it doesn't either reliably invert the order (in the case
> of trunk) or get it right (with this fix) but once you click on each
> window once (or scroll through them) then it works fine)
>
> Who
>
>
> ** Attachment added: "Trivial patch to see if I know what's going on."
> http://launchpadlibrarian.net/23441122/trivial.patch
>

Jason Smith (jassmith) wrote :

the reason that .Reverse () is there is that windows are always handed
off in a stacked order. That is the top most window is at the 0th
element of the array. We reverse it to raise/lower them in the same
order, back to front instead of front to back.

Try increasing the sleep time to 50ms just for kicks (it will make
things a bit slow).

Jonathan Austin (mailforwho) wrote :

I'm using Metacity. BUT when I use xfwm4 I get the opposite behavior. For metacity the .Reverse() seems to mess things up, for xfwm4 it fixes what would otherwise be broken.

I'm doing:
$killall metacity; sleep 2;xfwm4; metacity --replace
to toggle window managers (and killing xfwm4 with ctrl+c in the terminal to go back to metacity)

Changing the delay just lets me be confused more slowly... ;) Even without changing the delay I can see the windows being rendered one by one (first forwards, then backwards :) - that's what made me look to remove the reverse in the frist place.

The 'bring to front' (as opposed to restore) code works for either WM. (ie when the windows aren't minimised it doesn't matter which WM I am using, I still get the top window staying on top)

Can anyone else verify this? Is my metacity being different?

Jason Smith (jassmith) wrote :

I'll add a metacity hack

Jonathan Austin (mailforwho) wrote :

Is this an okay way to do it? Tested with xfwm4 and metacity.

Jason Smith (jassmith) wrote :

That is pretty close to what I had in mind.

Robert Dyer (psybers) on 2009-07-03
Changed in do:
status: Fix Committed → Fix Released
Ryan Thompson (rct86) wrote :

I have more weirdness to report. When I minimize and then restore a group of windows, the Z-order is mostly preserved, except that the top two windows have their Z-order swapped.

I'm using version 0.8.2+dfsg-0~9.04~ppa3 on Ubuntu Jaunty.

Robert Dyer (psybers) wrote :

I'm not experiencing this on Jaunty. I'm running the latest bzr trunk though and I am on Compiz.

Ryan Thompson (rct86) wrote :

Robert Dyer wrote:
> I'm not experiencing this on Jaunty. I'm running the latest bzr trunk
> though and I am on Compiz.
>
>
Oh yeah, I forgot to say I'm using Metacity.

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

Other bug subscribers