Re: global menubars in GTK+

[Davyd Madeley <davyd madeley id au>]

So, I agree with you, on large screens the global menu bar is a pain in
the neck.

This is not about implementing a global menu bar in GNOME, this is about
providing API in GTK+ for supporting global menubars on platforms where
they are present (let's not forget, GTK+ is also gaining a lot of
traction on small-display-size devices).

If applications gain support for this over time (e.g. as they're ported
to OS X) and someone wants to make this work as an applet on GNOME...
fine. If people making this work for a customised GNOME makes it easier
to run GTK+ apps on OS X fine.

I just want to make it easier to integrate applications into different
platforms.

--d

On Mon, 2009-05-25 at 12:04 +0300, Nemes Sorin wrote:
> global menu bar from Usability point of view ...
> 
> I am a designer interested in Man - Machine interaction.
> Regarding global menu in Gnome, I spent a 2 weeks using globalmenubar 
> being curious to find in which mode my workflow will be affected (Speed 
> ? Comfort ? ...).
> 
> Well after 2 full weeks - I can tell you all - when you have a huge LCD 
> / CRT ( you are designer or DTP guy ) global menu is not an option - 
> because you have to cross a lot of screen areas with the mouse cursor - 
> when is not the right case.
> 
> For example, having multiple windows on a big screen ( 16/10 ) -> a 
> color picker, a Nautilus instance  ( sized at 500x500 ) and an Inkscape 
> / GIMP / OpenOffice window ( 800x800 ) - on the area of the screen which 
> is on the right area -> you will use a lot more time doing normal 
> things  because for each non trivial command ( as copy paste or 
> drag-drop or a shortcut command ), where you need menu bar options you 
> will have to do a lot more mouse movement just to reach the upper top 
> screen zone where the globalmenubar is located.
> 
> With widescreens even on a mac globalmenu loose it's sense.
> 
> For the case of big screens - normal layout for menus ( old, orthodox 
> paradigm ) is more productive.
> 
> Normally a designer, working on a big screen, will keep  2 or more 
> opened windows on the same time.  Now imagine GIMP - you can not assign 
> all commands with shortcuts - for any filter (I have ~ 200 filters ) 
> which is not assigned to a shortcut, you have to cross all screen again 
> with the mouse cursor because of the global menu bar location. Without 
> globalmenu I can do the shortest way with the mouse - because my mouse 
> is in the canvas window so is very close with the menubar. For 
> repetitive tasks which request menu commands - global menu can be a 
> worst thing.
> 
>  From an usability point of view, I think the globalmenu is a death case 
> on the era of wide / big screens - even for MacIntosh.
> 
> Same case with the Microsoft ribbon - they don't preview the big screen 
> era  ;) so on a widescreen laptop the amount of vertical space used by 
> the MS ribbon is huge. Red Office ( the chinese Open Office )  has 
> discovered the right (old) paradigm for the wide-screens - the lateral 
> ribbon ( inspector ) - and Gnome need an infrastructure for implementing 
> fluid layouts - lateral floating inspectors ( like Mac has ) / vertical 
> ribbons, etc, accelerated canvas.
> 
> Finally - implementation of global menu in gnome core - can have a 
> single reason - to help Mac Users to use Gnome ( but the point is to 
> help the huge mass of Windows users ).
> 
> My 5 cents ...
> 
> SorinN
> 
> On 05/25/2009 08:59 AM, Davyd Madeley wrote:
> > (oh no, not this again)
> >
> > I was looking at the variety of different methods that are now being
> > employed on different platforms (MacOSX, Hildon, etc.) to implement
> > global menubar type options, and was wondering if we couldn't get some
> > synergy happening in GTK+.
> >
> > I had a look at rhult's IGE [1] and came to the conclusion that it
> > wasn't really an optimal solution to the problem because:
> >
> >       1. it's working from GtkWidgets (i.e. GtkMenuItem), which seems
> >          like a faulty abstraction.. it would be much better to work from
> >          GtkAction
> >       2. it provides API to rearrange items in the menubar (e.g. for
> >          MacOSX), which seems wrong to me
> >
> > After thinking about this for a bit, it seems to me like it would be
> > better to build an API based on GtkUIManager for the following reasons:
> >
> >       1. Everything connects to a GtkAction
> >       2. It would be possible to pass a different .ui file per platform
> >          or use menu-merging to rearrange parts of the menu layout per
> >          platform
> >       3. Setting shortcut keys for actions could be easily done via a
> >          macro [2] in the API or in the app
> >
> > This API would be implemented as a module that allowed for simple
> > overriding (e.g. for MacOSX, an embedded UI or even desktop GNOME).
> >
> > My initial thought is something simple like:
> >
> >          gtk_has_global_menu (void) ->  Boolean
> >          gtk_ui_manager_set_global_menu (GtkUIManager *manager, char *path) ->  void
> >
> > This sort of API could be made available in an external library, but it
> > seems like something that could be quite useful inside GTK+.
> >
> > Thoughts?
> >
> > --davyd
> >
> > [1] http://live.gnome.org/GTK%2B/OSX/Integration
> > [2] #ifdef MACOSX
> >      #define SHORTCUT(c) ("<Command>" x)
> >      #else
> >      #define SHORTCUT(x) ("<Ctrl>" x)
> >      #endif
> >
> >    
-- 
Davyd Madeley

http://www.davyd.id.au/
08B0 341A 0B9B 08BB 2118  C060 2EDD BB4F 5191 6CDA