Re: GTK+ menu problems/suggestions

[Owen Taylor <otaylor redhat com>]

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. ;-)
 
> 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)
 
> - 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.
 
> - 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.

> - Assigning the keys to menu items by pressing them activates the item 
> immediatelly, too (apparently only some keys, but not the others?)

Assigning non-modified keys to menu items really needs to be 
disabled when used in conjunction with underline accelerators.
 
> - 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's the same principle as GTK+ activating submenus automatically
on mouseover.

> - Home/End keys should work in the menu.

Might be a nice touch. Not something I think most people
would think of doing.
 
> - F10 should activate the menubar like in Motif/... (standard key).
> Deactivate too if pressed a second time.

Well, that could be done easily enough. One problem is
that right now we leave the Function keys completely
up to the application so we'd, in a sense, be invading that
name space.

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+.
 
> - 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?
 
> - 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.
 
> - 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.
 
> - Torn off menus should stay above parent frame (must set
> WM_TRANSIENT_FOR just like undocked menu bar already does).

Sounds right.

> - wish: conditional cascade submenus (like in OS/2). They are very
> useful to 
> keep the menus clean but still powerful. Some of the above stuff will
> have to 
> be done before they can be implemented. My window manager, icewm, has an
> implementation of these that is event better than OS/2 one...

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.

That's the problem - everybody has slighlty different
expectations. But a lot of your suggestions are good -
it's just a matter of somebody sitting down and
implementing them.

                                        Owen