panel: window list applet should raise a lowered window

[Michael P. Soulier]

Currently, if I have window A and B both on my screen, but window B is obscuring
window A (higher layer), if I click on the window list applet for window A, I
expect it to raise window A to be on top of window B. However, since window A is
not minimized, the applet sees fit to minimize window A, even though I cannot
see it and do not wish it to be minimized.

When I click on a window in the window list applet, I expect to be able to see
it and use it. If I can already see it and use it, then minimizing is fine, but
not if it's completely obscured by an existing window. This is bad default
behaviour, IMHO.

Also, if I right-click on the window icon in the window list applet, the menu
does not include an option to raise the window to the top layer. My only real
option is to click on the indicator twice, minimizing and then un-minimizing the
window, and when it comes back up it's placed on the layer above the other
windows. That should be what happens when you click on it once, no?

Thanks.

http://bugzilla.gnome.org/show_bug.cgi?id=90134: http://bugzilla.gnome.org/show_bug.cgi?id=90134

[Sebastien Bacher (seb128)]

First, please open a bug for each issue you get.

Are you using warty or hoary ? What kind of focus are you using ?
Here if I click on B it brings the windows on the top level and don't minimize
it (using hoary).

[Michael P. Soulier (msoulier)]

(In reply to comment #1)
> First, please open a bug for each issue you get.
>
> Are you using warty or hoary ? What kind of focus are you using ?
> Here if I click on B it brings the windows on the top level and don't minimize
> it (using hoary).

I'm using Warty, with focus-follows-mouse, but no auto-raise.

The problem seems sporadic. I'll see if I can figure out a deterministic
set of steps so you can reproduce it. I can't yet get it to happen
reliably.

[Sebastien Bacher (seb128)]

*** Bug 11772 has been marked as a duplicate of this bug. ***

[Sebastien Bacher (seb128)]

gnome-panel issue in fact and a bug has been opened upstream about a such issue
as signaled in #5350:
http://bugzilla.gnome.org/show_bug.cgi?id=163343

[Elijah (newren)]

Actually, this bug sounds more like
http://bugzilla.gnome.org/show_bug.cgi?id=90134 -- which is something that
click-to-focus users will never see (because of the policy that clicking in a
window results in the window both getting focused and getting raised). sloppy
and mouse focus users, however, will see it on occasion. (Though, yes, the
duplicate sounds like gnome #163343)

[Sebastien Bacher (seb128)]

thanks for the details, splitting the bug again :)

[Chad Davis (cdavis)]

As posted in the other bug, if this is a dup of the other bug I have this issue
with click-to-focus. :/

[Lionel Dricot (ploum-deactivatedaccount)]

Accepted upstream.

[sam tygier (samtygier)]

this is marked fixed upstream and looks like the patch went into cvs in jan 2005.

is this bug still present in ubuntu?

[Michael P. Soulier (msoulier)]

> is this bug still present in ubuntu?

I have not been able to reproduce it in dapper.

[Ulf Karlsson (ohmega)]

Why does the status for gnome-panel (ubuntu) have the status "Fix released"? This problem is still present with sloppy focus in feisty. As I stated in 41761 that is now a duplicate of this bug:

If you click the window list for a window that is currently active it will become minimized. This is a problem when you use sloppy mode for metacity. Suppose that you are using window B that is partly on top of window A so that when you move the mouse down to the panel you will cross window A and activate it. Thus window A that you want to use is minimized instead of being raised! Note that this happens even if you only see one pixel line or so of window A behind window B. Thus it is quite confusing.

[Ulf Karlsson (ohmega)]

The problem may be that you are treating these two problems in Gnome as duplicates of each other:

http://bugzilla.gnome.org/show_bug.cgi?id=163343

http://bugzilla.gnome.org/show_bug.cgi?id=90134

They seem to be two distinct issues.

[Sebastien Bacher (seb128)]

the bug has been marked fixed because the submitter wrote that it works fine on dapper for him