Re: Yet another scrolling menus patch.

[Alexander Larsson <alla lysator liu se>]

On 31 Oct 2000, Owen Taylor wrote:

> Alexander Larsson <alla lysator liu se> writes:
> 
> > So, what about this version? I'm kinda satisfied with the behaviour.
> 
> Its getting much better. I'm not completely 100% satisfied yet,
> however.
> 
>  - I don't believe the blanked-out area is appropriate for menus
>    popped up from menu-bars. These menus should just be the length from the
>    menu item to the farthest side of the screen. Reasons for this:
> 
>     - Menus are usually popped up from near the top or bottom of the
>       screen, so making the menu full-height seldom gains much space.
>   
>       (Note that on the Macintosh, where this behavior was copied
>       from, menus from menubars always come from right near the
>       top of the screen, so I very much doubt is does it.)
>     
>     - The full-screen menu obscures the parent menu item on the 
>       menu bar.
> 
>     - Making the menu a bit shorter than the screen will fix the
>       problem that when such a menu is torn off it is taller than the
>       screen.
>  
>     - It looks odd. :-)
Will change.
 
>  - The blanked-out area is less odd-looking for option menus, but
>    seems a little odd to me. Having the text move over the background
>    without any bevelling doesn't give a very natural sense of
>    scrolling.
> 
>    One idea I had was to do something like the mockup in:
>   
>     http://people.redhat.com/otaylor/tmp/menu-scroll.png
> 
>    The idea here is to make it a little more obvious that the
>    blank area is off-the-edge of the menu, while still leaving
>    the outer frame in the same place to provide visual stability
>    and a big target for the mouse to hit. 

Yes, that looks good. I didn't understand what it depicted at first, but
now I see.

>  - There is fairly obvious bug with the option menus - when an option
>    menu partially off-screen scrolls up to fit onscreen, the top arrow
>    appears without needing to and stays there obscuring the top menu
>    item until you cursor onto it. 
Will fix.
  
> > There is some flashing redraw going on when you pop down a menu and there
> > is a torn of menu visible. I don't know how to fix this. The old way where
> > you call gtk_menu_reparent with unrealize==true is broken. If there are
> > torn off submenus of the torn off menu they're unrealized when their  
> > parent menu-item is unrealized as part of the gtk_menu_reparent, and they
> > never get realized again.
> 
> I don't quite understand the point here; unrealize = TRUE was
> only ever used for moving the menu from the tearoff to the 
> real menu, and unrealize = FALSE was always used for the other
> way.

Yes. I had to remove the usage of unrealize = TRUE for moving the tearoff
from the tearoff to the real menu beacuse of this chain:

gtk_menu_reparent() ->
gtk_container_remove (GTK_CONTAINER (widget->parent), widget) -> 
 (widget here is the GtkMenu, and parent is the GtkWindow)
gtk_widget_unparent (widget) ->
gtk_widget_unrealize (widget) ->
gtk_widget_real_unrealize (widget) ->
gtk_container_forall (GTK_CONTAINER (widget),
		  (GtkCallback) gtk_widget_unrealize,
		  NULL) ->
gtk_menu_shell_forall (widget, TRUE, gtk_widget_unrealize) ->
gtk_widget_real_unrealize (menuitem) ->
gtk_container_forall (GTK_CONTAINER (menuitem),
		  (GtkCallback) gtk_widget_unrealize,
		  NULL) ->
gtk_menu_item_forall (menuitem, TRUE, 
                      (GtkCallback) gtk_widget_unrealize,
                      NULL) ->
  if (include_internals && menu_item->submenu)
    (* callback) (menu_item->submenu, callback_data) ->
gtk_widget_unrealize(submenu)

This means that any torn of submenu of the reparented menu is unrealized
while it is shown, which is pretty nasty. This bug probably exists in Gtk+
1.2 too.

The thing was that removing the usage of unrealize == TRUE while moving
from the tear off to the normal window did not reintroduce any
flickering! All flickering i saw was when moving in the other director.
 
> I believe the flicker you are seeing here is exactly the same 
> flicker that GtkMenu always had, but just more obvious because
> you are testing it with bigger menus and more complicated geometries.
I don't claim to understand why this affects flickering, but using
unrealize == TRUE while moving from the normal menu to the tearoff did
remove the redraw flicker you normaly get on that operation. It had other
strange effects that i didn't explore further though, as i suppose they
are the same as the above chain.

> The only way I can think of to get rid of the flicker is to set a
> background of None - i.e.
> 
>  gdk_window_set_back_pixmap (window, NULL, FALSE);
> 
> on the GtkMenu and GtkMenuItem. 
> 
> You can either do this permanently, which will result in a rather
> strange appearance when moving windows over a torn-off-menu, or you
> could possibly do it temporarily only during the move from the
> popup to the torn-off window.

I'll experiment with this.
 
/ Alex