GNOME Bugzilla – Bug 92650
2.0 Panel is always at the top of the window stack
Last modified: 2004-12-22 21:47:04 UTC
Package: gnome-panel Product: gnome-panel Synopsis: 2.0 Panel is always at the top of the window stack Severity: normal Priority: High Bugzilla-Product: gnome-panel BugBuddy-GnomeVersion: 2.0 tim.foster@sun.com 2002-09-04 In GNOME internal release 2.0_beta1_080602, it seems that the panel is set to be "always on top" - ie. at the top level of the window stack. In earlier versions of GNOME (1.4) the panel behaved like a normal window, respecting any "raise when focused" settings you had with the rest of the window manager (which was much nicer imho) When you maximise windows, they only maximise to the edge of the panel, which is wasting screen space (I'd rather the panel be flipped under the maximised window). Alternatively, could we get the hardware people to ship with 19" and-a-bit-extra-on-the-verticle) monitors and get the framebuffer and x11 people to give us an extra, say 100 pixels on the y dimension ? :-) In particular, under metacity's "full screen mode" (great for using IDEs without the clutter of window borders) the panel still decides it wants to be at the top level, which is getting in the way. (see attachment) A workaround is to hide the panel when you're working full screen, but this means that whenever you flip to another workspace, you have to re-enable the panel (yes you could use auto-hide, but from a usability point of view, this is not the best. http://www.asktog.com/columns/022DesignedToGiveFitts.html has some good thoughts on this ( see question 4) ) Could this behaviour be reverted to the gnome 1.4/CDE behaviour ? Bugtraq+: 4741287 ------- Bug moved to this database by unknown@bugzilla.gnome.org 2002-09-06 07:28 ------- Reassigning to the default owner of the component, gnome-panel-maint@bugzilla.gnome.org.
i believe the panel always on top behavior is intentional, I'll cc havoc just in case. I also agree with you about the autohide behavior of the panel (ie. making it autohide into the corner), and had filed a separate bug related to that issue a while ago.
metacity/rationales.txt is proving useful :-) *** This bug has been marked as a duplicate of 81551 ***
Uhh - okay. Is this going to be documented in some sort of CDE -> GNOME migration document ? From a Sun user's point of view, I'd still consider this broken, despite having read the essay-like bugid 81551 and there's things that are artifacts of this bug that don't seem to work in the current build (take a corner panel, and click on the hide button to hide it, then try to move/resize a window over where the panel was - you'll find that the window move/resize is constrained by the space that would have been taken up by the panel were it not hidden.) I'll try a later build, and open a new bug if necessary. Screen real-estate wise, I still don't agree with the sentiments of the duplicated bug, but I'm trying to have an open mind :-)
The move/resize constraint for hidden panels is a gnome-panel issue, not a metacity issue. (gnome-panel still sets the _NET_WM_STRUT hint probably)
My Devil's Advocate question is: since a the whole point of a (GNOME) panel is that it's a part of the desktop that you can always access, why use one if you don't want it to be always-accesible? (Answer: applets, I guess, and I agree that being able to run applets on the desktop is probably a worthwhile requirement for a future release). My usability question is: Doesn't making the panel auto-hide solve these problems? That allows windows to maximize to whole screen, and you can pop up each panel on demand (with the exception of the menu panel, a problem which should be addressed when we get around to replacing it with a regular edge panel in a future release, and which you can always remove in the meantime). And if not, why not? As for the horizontal corner/sliding panel bug: this is indeed highly unpleasant from the user's perspective and needs fixing. (Preferably by getting rid of corner and sliding panels-- see my diatribe in bug #87027 about "too many pointless panel types" :)
Q. Why use a panel ? I find panels great for holding things that aren't as "important" as an application : things that don't warrant their own windows (utility applets, launchers - that sort of thing) My view of non-importance, also says that applications take precedence over panels, hence this bug (perhaps I'm wrong) The task list applet is the analogue of the old CDE icon box but it doesn't take up room on the desktop (alt-tabbing in CDE would switch to the icon box which I'd never conciously want to happen) - in GNOME, alt-tabbing has the correct behaviour, which is great ! Nice one. Q. Couldn't you use autohide ? Yes, I could - but in the scenario where I have 12 windows open and want to switch to one of those (without alt-tabbing, or just grabbing the window itself) I'd throw the mouse to the bottom of the screen, pause while the task list appeared, and then have to start hunting around on the tasklist for the application I want. If the panel wasn't auto-hidden, I can see where I'm aiming for instantly, and quickly select the right item from the tasklist. It's a minor niggle. ( much as I hate to quote Tog, I'd tend to agree with him on this one : http://www.asktog.com/columns/044top10docksucks.html - a different article than the one I originally posted about the sins of the OSX dock. ) As for comments on the "too many panels", I'd agree, to a certain extent. I've never used floating panels - though if users were attached to CDE (!), they'd be ideal for replacing the CDE panel. Likewise, if users were attached to MacOS, corner panels are quite like tabs : so I can understand why there are multiple panel types available. Eventually though, this bug, and bug #87027 prove that you really can't please everyone all of the time. Either we use a modern, well thought out desktop, or we revert to our old "comfortable" desktops that behave as we see fit - I guess I'll stop complaining, and get with the "now" ;-)
*** Bug 86751 has been marked as a duplicate of this bug. ***
*** Bug 90870 has been marked as a duplicate of this bug. ***
*** Bug 95670 has been marked as a duplicate of this bug. ***