Re: [patch] Scrolling menus

[Alexander Larsson <alla lysator liu se>]

On 17 Oct 2000 otaylor redhat com wrote:

> 
> Alexander Larsson <alla lysator liu se> writes:
> 
> [...]
> 
> > >  - 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.
> 
> Possible, though I find the MS behavior quite annoying in general, and
> probably not that great to copy.  (the scroll speed is too fast when
> you are trying to scroll just a little bit, among other things)
> I think having controls that activate when you aren't holding the
> mouse down a little dubious.
> 
> (we do pop up submenus on mouse-over, but that's not really
> quite "activation")

There is on problem with the current code though, if you pop up a menu
from an optionmenu (doesn't work from menubar), press the mousebutton over
an item, and then drag the pointer to a scroll arrow without releasing the
mousebutton the menu will scroll, because menu_shell->button != 0. I can
basically not distinguish this case from the "pop down menu without
releasing mousebutton" case.

I think it will scroll on mouseover in both cases. I think it is a bit
more natural. Basically you drag the mouse "outside" the screen, a bit
like what you'd have to do if the menu fitted, instead of arbitrarily
having to click an extra time depending on the position of the window.

I will also experiment with different scroll speeds, depending on the
position on the scroll arrow.

> > >    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)
> 
> Hmm, the problem with this is it doesn't enforce the fact that
> the non-scrollable parts have to be at the beginning and the
> end.
> 
> I might prefer:
> 
>  gtk_menu_set_start_nonscrollable (GtkMenuMenu *menu,
>                                    gint         n_items);
> 
> and maybe:
> 
>  gtk_menu_set_end_nonscrollable (GtkMenuMenu *menu,
>                                  gint         n_items);
> 
> (Of course, you can have tearoff menuitems not at the beginning
> which is just as bad.)

Ugh, I forsee a lot of bad voodo handling what is essentially tree lists
as one. Especially when prepending or reordering menus.

Also, having spent some time reading in the archives and the reference
Nils gave I think I will implement menus the Mac way (Always make menus
their requested height if less than screen height, but possibly start
drawing some way down into the menu). This makes nonscrollable parts of
menus strange to say the least. I can't think of any way to make it work.
  
I will make tearoff windows use scrollbars, and not show scroll arrows,
but unfortunately I can't think of any way to get the tearoff item out
of the scroll window. (Except by gross ugly hacks.)

> The entire code definitely would be nice to clean up - I think that
> the tear-off code is only a small part of it, though some of the
> things it does (like the snapshotting) are definitely hacky and
> non-intuitive.
> 
> I don't have a very good sense of how you would go about cleaning
> it up - the problem is that there just a whole bunch of complicated
> GUI behaviors which are all interelated and don't factor well.
> 
>  - tearoffs
>  - single click popups and click and drag usage
>  - submenus
>  - scrolling
>  - triangle-navigation
>  ...

/me nods violently
 
> > I'll have to think some more about the whole size/positioning issue.
> 
> I think the Mac behavior that Nils reports where the menu is always
> the same size and the contents scroll within it may be the right
> way to go, though it strikes me as a bit unlike anything else 
> in GTK+. (It corresponds to a negative adjustment position for
> a scrollbar)

I will try to implement this. For tearoff windows I will use a scrollbar
(without using negative positions) though.

/ Alex