Re: Suggestion: Remove the Window Title Bar

[Sergey Zolotorev <sergey zolotorev gmail com>]

Just a note: global menu looks like it was teared from an application off.

BTW, mega menus look very pretty
(http://live.gnome.org/Design/Whiteboards/Menus). It is sad that there
are so much items in "But" section.

On Fri, Oct 7, 2011 at 11:47 PM, Gavin Engel <gavin engel com> wrote:
> Federico, that is a very interesting read.  One thing I wanted to point out
> is that there is a pseudo-Global-menu extension for
> GNOME: http://www.webupd8.org/2011/09/get-global-menu-in-gnome-shell.html
> What do you think? Also, is the placing menus in the window titlebar
> (example) just as tricky to accomplish as the Global-menu system you
> described?
>
> On Fri, Oct 7, 2011 at 12:38 PM, Federico Mena Quintero <federico gnome org>
> wrote:
>>
>> On Fri, 2011-10-07 at 10:44 +0200, Florian Müllner wrote:
>> > On vie, 2011-10-07 at 10:29 +0200, Aurélien Naldi wrote:
>> >>
>> > > I think most of the underlying tech is here already: unity use a
>> > > protocol through which the applications describes its menu. Then it is
>> > > up to the shell to decide how to organize them.
>> >
>> > Except that Canonical is in a position where they can patch
>> > non-GNOME/GTK+ applications (Firefox, Libreoffice, Qt, Motif, ...),
>> > while GNOME is not.
>>
>> Unity's implementation has some *big* problems.  It works like this:
>>
>> 1. The application-side code scrapes the GTK+ widgets in the menu
>> (menubar, menus, menu items...) trying to extract things like labels for
>> menu items.
>>
>> 2. The application-side code then transfers this via D-Bus to the global
>> menu manager.
>>
>> 3. The global menu manager then reconstructs the menu from the labels
>> and the info it got passed.
>>
>> 4. When an item gets selected, the global menu manager calls back into
>> the application-side code (again, via D-Bus) and tells it which menu
>> item was activated.  I guess the app-side code then synthesizes the
>> appropriate GTK+ widget signal on the original menu items.
>>
>> Now, for the problems:
>>
>> GTK+ menus are *very* flexible; they have grown over the years into
>> something much more sophisticated than "items in a hierarchy with a
>> label and an optional icon".  You can have items in a tabular
>> arrangement, you can insert any widget inside a menu item (and some
>> applications take advantage of this), and you can hook into a menu in
>> strange ways to make it do things that are quite specific to particular
>> applications (e.g. if you need a slider in a menu item, you need to do
>> some scary hacks with mouse grabs and event forwarding so that the
>> behavior feels right).
>>
>> However, all that flexibility means that it is impossible to transfer
>> all that information and all that behavior to the global menu manager.
>> A GTK+ menu is just not something that you can screen-scrape and
>> reconstruct in the general case.
>>
>> (I'm not saying that Unity's implementation is bad; Cody Russell (an
>> extremely competent GTK+ hacker) wrote it, but GTK+ doesn't make things
>> easy at all for this purpose.)
>>
>> To make a global menu possible, and robustly, we have several options:
>>
>> - Have applications manage their menu, and provide a way for them to
>> "have their menu detached" and re-attached to the global menu bar -
>> think of a window manager that sniffed for menus, and put them in the
>> global place.  This has all sorts of funky details, but you get the
>> idea.
>>
>> - Have a restricted and well-defined set of functionality for menus,
>> that is transferable over D-Bus with no loss in behavior.
>>
>> Either option would be *much* easier if GTK+ finally implemented a
>> GtkApplicationWindow with actual space for a menu bar - *the* menu bar,
>> not just a random menu bar that happened to be placed by the app in the
>> conventional place within its window.  I'm sure there is a bug filed for
>> this; you may want to look for it and see the progress there.
>>
>> The first option would make a lot of sense for X11 toolkits.  No toolkit
>> is going to be happy restricting its menu functionality to some
>> arbitrary subset, but they are already comfortable with letting a window
>> manager manage them.  "Reparent the menu to an external window" is
>> scary, but we've been there before.
>>
>> The second option would be very good for non-X11 platforms; with a
>> restricted set of functionality for menus, they could very well be made
>> to "just work" on MacOS, for example.
>>
>>  Federico
>>
>> _______________________________________________
>> gnome-shell-list mailing list
>> gnome-shell-list gnome org
>> http://mail.gnome.org/mailman/listinfo/gnome-shell-list
>
>
> _______________________________________________
> gnome-shell-list mailing list
> gnome-shell-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-shell-list
>
>



-- 
Sergey Zolotorev