Re: Yet another scrolling menus patch.
- From: Owen Taylor <otaylor redhat com>
- To: gtk-devel-list gnome org
- Cc: arlo eazel com
- Subject: Re: Yet another scrolling menus patch.
- Date: 31 Oct 2000 14:59:21 -0500
[ 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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]