Re: GTK+ menu problems/suggestions

[Marko Macek <Marko Macek gmx net>]

Owen Taylor wrote:
> 
> Marko Macek <Marko.Macek@gmx.net> writes:
> 
> > Here is a list of problems and some suggestions for gtk+ menus. I used
> > gtk+-1.1.11 from the latest gnome RPMS.
> >
> > I plan to fix these things myself if no one does it before me, but I
> > will
> > be very busy for some time...
> 
> Many of these things that you mention don't count as
> bug-fixes, so probably won't be dealt with until after
> 1.2, and possibly not then unless some interested party
> contributes patches. ;-)

I certainly plan to do it when I have the time. The current gtk menus
certainly feel wrong to me. Most of my suggestions is usability
improvements (some optional).
 
> > If you want more detailed explanation of some items send me email.
> >
> > Here is the list:
> >
> > problems with gtk menus:
> >
> > - when pulldown/popup displays the first item is selected even while
> > mouse is still being held down. The item should only be selected
> > if the popup was activated by keyboard or after the mouse is released.
> > This is especially ugly with tearoffs.
> 
> You're right that it isn't too pretty, but it doesn't seem
> to adversly affect operation.
> 
> > - Tearoff item should not be selected by default. The next item should
> > be selected instead.
> 
> That probably would be good. (GNOME making everythign tearoff
> by default certainly exacerbates this problem. I originally
> expected that only a few select menus would be tearoff)

I hope this can be made into a GNOME option. IMHO GNOME looks much
better with all the stuff for undocking menu bars/toolbars/tearoffs
hidden.

> > - The first item of the cascade submenu (skipping the tearoff if there
> > is one) should be vertically aligned with the menu item in the parent
> > menu that the submenu is attached to (I submitted a patch for this a
> > long time ago but it was not included for some reason)
> 
> I didn't apply it because I think the current scheme is better.
> The offset gives a visual separation between menu and
> submenu. If there was a large ground-swell of support in
> favor of the aligned look, I'd apply it despite my
> personal distaste, but I haven't heard such yet.

But it makes it much harder to aim for the submenu (see below for my
comments about mouse-over tracking).

> > - Alt+Letter selects submenus from the menubar like it must. But while a
> > submenu is active it is not possible to jump to another submenu the same
> > way.
> 
> Hmm, So you are saying that if we have:
> 
> _Colors
>   _Sea Green
>   _Aqua
>   _Yellow
> 
> _Shapes
>   _Circle
>   _Square
>   _Box
> 
> Then if you are sitting on Aqua and hit S, it should
> select Sea Green, but Alt-S should take you
> to shapes. This seems a bit Byzantine to me.

Yes, for the menu bar only. Makes perfect sense to me. Alt+letter select
toplevel menus from the menu bar. There is no reason to have this not
work while navigating the menus.
 
> > - When navigating popup menus with cascade submenus, the submenus should
> > not be shown automatically, but only when Enter or Right/Arrow is
> > pressed.
> >
> > When a cascade menu is shown off the popup menu, pressing left arrow
> > should hide the submenu and activate the parent menu.
> 
> I disagree here. Having the submenus activate automatically
> is somewhat useful in that it tells you what is in each submenu.

It looks *really* weird. Totally unresembling anything else.

(I know this is done because code is slightly weird with select_item
automatically popping submenu too. ... I guess I will have to fix this
when adding conditional cascade submenus).

> It's the same principle as GTK+ activating submenus automatically
> on mouseover.

I propose this be made an option too (see below).

> > - Home/End keys should work in the menu.
> 
> Might be a nice touch. Not something I think most people
> would think of doing.

90% of the good GUI is in nice touches (that do not get in the way).

> Having Alt activate the menus as in Windows is a bit
> more natural, but very hard to do within the way accelerators
> work in GTK+.

F10 is just as/more standard as Alt in windows. Works in Motif too.
 
> > - cascading submenus are often displayed over their parent menu instead
> > of
> > on the left/right side. (mostly when displaying menus to the left)
> 
> Hmmm, I can't reproduce this with some testing. Do you
> have an example?

I will send you a picture of this. (it occurs with gnome panel when on
right side menu). I believe I have once reproduced it with testgtk too.
 
> > - clicking the menu item activates the submenu, clicking again should
> > hide it.
> > (in menu bar too)
> 
> This only seems to apply to menu bars and torn-off menus,
> but yes, that would be natural.

It applies even to cascade submenus when you don't activate them by
default on mouse move.
 
> > - option (have I missed it?) to disable automatic mouse tracking when no
> > mouse is pressed. (Perhaps even as default). This is really important
> > because it is a really big pain to use the current menus with less than
> > perfect mice.
> 
> I don't understand this one. If you press/release on a
> menu item the menu stays up and you don't have to keep
> the mouse down. If you drag than menus get selected
> on mouse up.

I meant the fact that menus track mouse movements (select submenus) even
when no mouse button is pressed. This is annoying as hell unless your
mouse is brand new or cleaned every day... IMHO this should be disabled
by default.

> I must admit that the IceWM menus annoy the heck out of me
> because they are just subtly different from GTK+ menus
> in a lot of ways so things I expect to work don't.

Gtk+ menu are closer to motif1.2. icewm is closer to motif2.1 which I
find a big improvement in this area.

Apart from the conditional cascade menus which gtk+ doesn't have yet:
what bothers you? Icewm menus have most of my suggestions implemented.

Also: you can enable mouse tracking even with no buttons pressed to get
closer to current gtk+ menus. (it is disabled by default).

Mark
-- 
... MouseDevice "/dev/null"
--------_--------------------------------------------------------------
Marko.Macek@gmx.net                http://www.kiss.uni-lj.si/~k4fr0235/