GNOME Bugzilla – Bug 584651
top panel should act like a menubar
Last modified: 2010-06-08 05:52:04 UTC
All of the items on the top panel should have drop down menus that act like part of a single menu-bar. This includes the status area icons and the clock.
Does this suggestion include moving GTK to a single menu-bar model like OSX? I have been thinking about this for a while... at least I tend to use many apps full-screen on it's own workspace with gnome-shell (something I did never really do before) so a menu bar like the one in OSX would make sense for me now.
i have the same imagine. i think the top bar should be like mac os X top menu ,which can dynamic change. the menu bar may be used to display the current application's menu bar ,just like mac os x. when using sidebar of gnome-shell it could display a system menu.
Created attachment 147161 [details] the top bar may use to show the menu of the curent aplication
Created attachment 147162 [details] when show workspace,the top bar can use to show a main menu
and i think that should to reduce as more clicks as can
wzssyqa: this bug is not about having a mac-like global menubar, it's about changing the behavior of the things that are already in the panel
sorry,i misunderstand it. what should i do now? make a new bug?
So... this is hard. gtk_menu_popup() tries to get a pointer grab, and bails out if it can't get it. But once a tray icon gets a pointer grab, the shell no longer has the ability to control what happens when you move the mouse away from that icon to a different one. If we could control the way that the tray icon's menu was created, we might be able to make this work by sticking it into a specially-written GtkMenuShell whose GdkWindow wrapped a Window owned by the shell, so that all tray icons would share the same grab window. But I'm not sure that doing a cross-process grab like that would actually work, and this would require making a bunch of changes to GtkStatusIcon, and at any rate, GtkStatusIcon *doesn't* control how the tray icon's menu is created anyway; it just emits "activate", and the app creates its own GtkMenu (or does whatever else it wants to do). So basically, AFAICT, this requires, at a minimum, adding new APIs to GtkStatusIcon and then porting each tray icon we care about to make it use those new APIs. But it's possible that that won't work anyway and actually it would require moving all of the tray icons into the gnome-shell process as well.
Going to mark this as done; we have the infrastructure, moving individual items to it should be individual bugs.