Re: An idea for a fun menubar hack

[Anton Person <pltxtra ludd luth se>]

Personally, I find that a great idea. Perhaps it's my background
as an Amiga user (Amiga chose that system aswell back in the 80's.)

I've had plans to implement my own menu lib, but if it was
seriously considered for GTK, I would love it.

	Anton Persson,  the 733 kru (http://www.733kru.org)

On Thu, 1 Nov 2001, Joel Becker wrote:

> Folks,
> 	Here is an idea for a nice GTK+ 2.2 bit.  This is only half
> serious, as it would be a lot of work, but man would it be neat to do
> right.
> 	I've spent a long time arguing with our resident Mac lover and
> "I want it usable for my father-in-law" person.  He is very adamant
> about the benefits of the Mac-style single menu bar.  The fact that
> there is infinite screen space to mouse to is a big win.  I can't
> disagree with him on that point, but I do dislike the Mac-style menu,
> and prefer regular menus-per-window approach.
> 	However, this is X.  That means we should allow a choice (or
> three, if possible).  So, what if we did this:
>
> o Wrote an application that sat at the toplevel and displayed a menu.
>   When running, it would set a property on the root with its window_id.
>   This way, other applications would be able to find it.
>
> o Change the GTK+ menus so that the code silently looks for this root
>   property.  If it finds the root property, it communicates with the
>   menu application and creates menus via proxy.  The toplevel menu
>   application actually displays the menus.
>
> o Whenever an application gets the focus, it notifies the menu
>   application and communicates its menu list.  In this fashion the
>   menu application changes its menu.  I don't even think that the
>   application has to do a remote object architecture.  I rather think
>   that simple "Text, Hierarchy, unique_id" tuples would do.  Remote
>   object systems (like CORBA) are heavy and might not be needed.  Not
>   only that, but a non-GObject-based system would allow a GTK+/KDE
>   spec.
>
> o When events happen on the toplevel menu bar (I'm not sure how
>   granular we would want it, every event or merely "activate"), the
>   menu application would notify the focused app.  The recieving
>   application would then behave as if the menu were local.
>
> o By propagating events when the menu application was started or
>   stopped, the GTK+ applications could gain/lose their menu bars in
>   sync.  A user could then choose on the fly if they would like a
>   single, toplevel menu bar, or a menu bar in each application.
>
> 	So, discuss.  It would be a neat hack :-)
>
> Joel
>
> --
>
> "All alone at the end of the evening
>  When the bright lights have faded to blue.
>  I was thinking about a woman who had loved me
>  And I never knew"
>
> 			http://www.jlbec.org/
> 			jlbec evilplan org
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>