Re: [patch] Scrolling menus

[Alexander Larsson <alla lysator liu se>]

On 16 Oct 2000 otaylor redhat com wrote:

> Alexander Larsson <alla lysator liu se> writes:
> 
> Let me first note some problems with the behavior from testing:
> 
>  - I think it looks a little funny to have the menu items just cut
>    off by the scroll arrows. 
>   
>    Perhaps there should be some separator or relief between the two-
>    e.g., make the scroll arrows raised buttons.

Windows does show a relief when the arrow is prelighted. I'll experiment
some to see what looks good.
 
>  - If you pop up the menu with a single click, then you have to
>    keep on clicking on the button for each scroll incroment.
>    If you get into a rut of doing this, then when the scroll
>    arrow disappears, you will select the first menu item.
> 
>    There should be an autorepeat here.
Would it be better if the behaviour when opening with a single click was
the same as when holding down the button (i.e. just mousing over the
scroll arrow starts the scrolling). It seems that is what MS does.

>    For torn off menus, when this happens, you untear the menu.
>    I tend to think that the tear-off indicator probably shouldn't
>    scroll, though implementing that is not easy. 
> 
>    (Note that in IE, for the Favorites menu, only the favorites
>    scroll, and not the "Edit", etc, options, so the general facilitiy
>    to define an unscrolling top section could be useful.)

Having a non-scrollable part of the menu seems like a good idea. There has
to be some sort of public API to define what parts should scroll though.
I'll look into it. Scrolling is a GtkMenu only thing, so maybe something
like:

 gtk_menu_append_nonscrollable (GtkMenu *menu, GtkMenuItem *item)

There could also be some special handling of tearoff items in
GtkItemFactory.
 
>  - Also, when you are over an arrow, popped up submenus stay up
>    permanently.

Eh? When you scroll they pop down, don't they?
 
>  - The fact that when you tear off a menu, it tears off at the
>    size that it was when you tore it off and it stays that way
>    is a little odd. I almost think that if you have a scrolling
>    menu and you tear it off, you should get a scrollbar.

All the tear off code makes the code really hacky and hard to grasp, and
it gets hackier as the difference between the normal and tear-off
behaviour increases. Having a scrollbar in the popup is a good idea, I'll
see if I can make it so.
 
>  - Something weird happens with option menus - when an option
>    menu is popped up with scroll arrows, the current item is
>    not selected on popup as it is in other cases, so you have
>    to move off it and then move back.
> 
>    Also, with option menus, in my opinion, if you pop it up
>    with only one line showing, then as you scroll, more lines
>    should become visible. That is, the menu should move onscreen
>    as you scroll, not just stay small and scroll.
> 
>    Finally, with option menus, the limiting case where the menu is
>    right on the edge of the screen works really badly - you can get
>    scroll arrows and nothing else. (In fact, I was able to get a
>    assertion failure in gtk_menu_handle_scrolling in this case) I'm
>    not really sure what to do here - the suggestion in the previous
>    paragraph will help some, since if you scroll a bit, more will be
>    visible. If that is not sufficient, then perhaps we need to force
>    one line of the menu to be always visible, even if that breaks
>    it so that the current menu item isn't immediately selected.

I'll have to think some more about the whole size/positioning issue.

/ Alex