Re: global menubars in GTK+
- From: chuchi <jbarbero quiter com>
- To: Nemes Sorin <nemes sorin gmail com>
- Cc: gtk-devel-list <gtk-devel-list gnome org>, Davyd Madeley <davyd madeley id au>
- Subject: Re: global menubars in GTK+
- Date: Mon, 25 May 2009 11:20:22 +0200
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
>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]