Re: Yet another scrolling menus patch.

[Owen Taylor <otaylor redhat com>]

[ Arlo CC'ed on this mostly to get his opinion on the screenshot below.

  The subject under discussion here is scrolling menus, and in particular
  what happens when positioning the active item under the cursor 
  results in the menu being partially offscreen.

  Alex has been experimetnign with an approach based upon what the
  Mac apparently does where the menu window has a constant size/position
  even if that involves leaving a blank area on the top or bottom
  side of the menu window. ]
  
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. :-)

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

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

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.

[ it seems to me improbably that the torn off submenu items
get unrealized with the parent - more likely if this is happening 
is that refcounting gets messed up so that they get destroyed,
not just unrealized. ]

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.

> Except the flicker I'd call this final.

I think its pretty good. I'd like to do another read-through on
the code before you commit, and I think the issues above need
to be addressed.

Regards,
                                        Owen