Re: global menubars in GTK+

[chuchi <jbarbero quiter com>]

Only one question: Why don't we use the window header for the
application menu? IMO the window border has not sense, only a lot of
space without any useful feature (only close and, sometimes, the title)

It is only another option...


El lun, 25-05-2009 a las 12:04 +0300, Nemes Sorin escribió:
> 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
> >
> >    
> 
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>