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

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

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.

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.

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.

I lied, i fixed it

This makes me very happy :) Thanks

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
>

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

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?

I'll add a metacity hack

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

That is pretty close to what I had in mind.

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.

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

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.