Re: [patch] Scrolling menus

[otaylor redhat com]

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")
 
> >    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.)
 
> 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?

Yes, when you scroll, they pop down, but if you aren't scrolling
they stay popped up as long as the mouse is over the arrow.
(if you change to scroll on mouseover, then this becomes a
non-issue, I guess)
  
> >  - 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. 

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

I think the first thing to do if I was trying to clean it up would be
to get rid of all the complex event forwarding - my idea would be that
you might want something like a GtkMenuController object that did all
the event handling for the entire menu hierarchy.

A torn off menu should act something like a menu bar, so you
could share event handling code for trees rooted at a menu
bar or at a torn off menu.

But that's a long way from a real design, and it probably isn't
worth trying to do substantial changes if we can make things
work in the current framework for 2.0.

(At some point, however, a rewrite is pretty inevitable)

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

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)
                                        Owen