GNOME Bugzilla – Bug 87191
Frustrating Panel Configuration
Last modified: 2004-12-22 21:47:04 UTC
The new panel configuration is very frustrating. Why is the upper panel set in stone? You can't change preferences or move it, or delete it. Grr. The top panel should be like any other panel. You should be able to drag it to the left or to the right. It should be fully configurable. I've had issues where I a program maximizes underneath this bar and I have to jump through hoops to shut it down. I encounter this with both sawfish and metacity. In case you don't think this little issue deserves attention I'd like to let you know that every article I've read on Gnome2 has griped about this extensively, that's a lot of bad press: http://www.kuro5hin.org/print/2002/6/30/15151/7188 "The top panel has been welded to the top of the screen and there is no amount of negotiating that will change that. This wouldn't be bothersome if you could set the panel to "auto hide", similar to the old panel in Gnome or those used in KDE and Windows. In fact I actually resorted to reading the help file for the panel and was informed that the "menu panel" cannot be moved or hidden. Granted it is very small and only takes a little room away, but it was an immediate source of frustration for me. I can only assume there are some hidden config files somewhere that will allow me to have my way but for now I'm stuck with the status quo." http://www.osnews.com/story.php?news_id=1280 "The Gnome menu panel now resembles a bit of MacOS. It sits on the top of the desktop, and no matter what I tried, I can't change its position. The window list can be found on the bottom of the screen. So, you get two gnome panels, one on the top and one on the bottom. I found this default configuration, bone-headed, at best. The panel on top only includes an 'Applications' and 'Actions' menu, then you get a huge unused space and then, at the right most side, you get the clock, and a menu which is equivelant to a chooser/finder as found on MacOS. It was a matter of time, before I deleted my bottom window list and embedded it on the main panel, to use all this unused space (note: I use a 1280x1024 resolution)." I use gnome2 as my primary desktop, this is my number one gripe. Otherwise I like the speed, and appreciate all the hard work that must have gone into this. If this is a design decision and you guys really want to stick to your guns on this please let me know...
Thanks for the feedback...but you kinda omit any useful comments/changes that should be made. If you complain without giving any worthwhile feedback it makes it quite difficult to know what to do.
It's not really a design decision. We were hoping that we'd be able to make it into a regular panel and use the menu applet to show the Applications/Actions menus, or some equivalent. This way we could have had it looking identical to the current menu panel, but without all the restrictions you mention. However, the menu applet so far hasn't had the love it needs to make it stable/accessible/all the other things it needs to be, so it didn't happen, unfortunately :/
Ahh, OK. Well, I'm not really trying to complain, you guys have done a great job on Gnome2. I was surprised to see there was no bug report, because everyone is talking about this. Just in case it isn't clear, the changes I would like to see are: 1) The top panel should be moveable, resizable and hideable. 2) You should be able to configure it so it isn't always in front of other windows. I guess to achieve these the menu applet needs work. Is anyone currently working on this project?
1) We hope to fix the "position of the menus set in stone" problem for GNOME 2.2, as Calum described. (PS, I guess that means we need to get cracking on the menu applet again...) 2) Having panels always on top is a design decision. Note that applications that implement WM hints properly should still appear completely on top (e.g. a movie player or presentation application should do this), but not general applications.For people accustomed to GNOME having the panels drop can occasionally free up a little real estate, but generally that space isn't especially useful. On the other hand, having the panels disappear can lock users into a "I don't know what to do situation". Without the tasklist, for example, they may not know how to make a giant window covering the whole screen "go away". I've seen this happen with new GNOME users a few times before. I'd appreciate information on the particular use cases that having panels on top is affecting? Do you try to use that space for working somehow, or is there a particular app like a movie player that's being interfered with?
*** Bug 87145 has been marked as a duplicate of this bug. ***
Trying to add apps to a sided panel via the ALT-F1 dialog will add the apps in the upper default panel - that's wrong too.
The current Alt+F1 menu will be disappearing Real Soon Now, to be replaced by the GNOME foot menu. It never made sense to pop up the panel menu on Alt+F1, as the user has no idea which panel it refers to.
Created attachment 9726 [details] Screenshot of app covered by panel
What window manager are you using, Sherman? Marking this minor and tempted to close invalid, as all of these things are duplicates unless there is particular useful and unique commentary here (which, AFAICT, there isn't.)
I don't know how usefull this is but I attached a screenshot terminal with it's upper bar covered by the panel. I placed this on there myself, however I have had apps (Evolution replies come to mind) placed there by the window manager (metacity or sawfish). The problem is that no matter how it gets placed, once it is there it becomes very difficult to move, especially if the window manager remembers it's position and restores it next time you start the app. So far my solution is to maximize the app using the tasklist below. This is still a problem, because if put it back to it's original state it is restored back to the position under the panel. My first instinct was to check the panel properties, which led to instant frustration because you can't. I like my panel to be 'always on top' but it's not a viable option when the application windows don't avoid it. I will post a better example when I get one, and try to reproduce this in both sawfish and metacity.
Given the current WM specs as laid out at freedesktop.org, if the WM places an app there, it is a WM bug. AFAICT, metacity implements this correctly. If you were using sawfish, was it v1 or 2?
Luis, The most important commentary here is that the menu applet needs some love and that apps need to avoid the panel on top. If that is duplicated elsewhere please close the bug. I know this report is long and too rambly. I think that these two issues are the most obvious usability issues gnome2 has right now, please make sure that they are represented somewhere before closing this. I was not able to find duplicate bugs (under gnome-panel) about configuring the top panel, but I was able to find an unconfirmed bug about applications failing to avoid the top panel (87644). Perhaps this should be closed and split into two more concise bugs? 1) The Menu Applet needs work so the upper panel can be fully configurable and 2) Applications need to avoid being placed behind the "immutable" top panel. (87644)
Luis, Currently my WM is metacity, but I have encountered the issue under sawfish v1.0.1. True when the WM places it there it is a WM problem, but what about when a user places it? I think the desired behaviour would be to have it 'snap' down, so that a user doesn't have to end up restarting gnome without saving the session in order to fix the issue.
I believe this bug should be given a higher priority. Perhaps even critical. This bug actually damages hardware! To my great surprise, I noticed my menu bar was lightly burned into my flat panel monitor. To my greater surprise, I found out I could not move the menu to avoid further burn in!
You can't move it, but you can always *re*move it and add a GNOME Menu on a different panel instead, which gives you all the same functionality as the Applications and Actions menus.
Sherman, Metacity should not be allowing window titlebars to sit under panels. If it currently is, that is a bug.
Sherman: your first point is a duplicate of bug #73072. As for your second point, if it still happens, please open a bug against the WM you're using. *** This bug has been marked as a duplicate of 73072 ***