Re: Submenu arrow patch (Was: Re: Submenu navigation status?)

[Nils Barth <nils_barth post harvard edu>]

mini-patches/fragments, a remark, and questions:

* There is an i18n problem with GTK in that submenus default to
  cascading right, which is wrong in Arabic/Hebrew, so the default
  direction should be somehow configurable. The patch basically replaces
  GTK_DIRECTION_RIGHT in necessary places (two) with a macro
  GTK_DIRECTION_DEFAULT (which is now GTK_DIRECTION_RIGHT).

  This doesn't much help/solve the problem, but at least localizes it
  (no pun intended).

* The fragment is a tiny function for converting SubmenuDirection's to
  Arrow directions. I didn't know where to put it -- static/private to
  gtkmenuitem.c?
(this is necessary so that one can change, in
gtkmenuitem.c:467
GTK_ARROW_RIGHT,
to
gtk_submenu_direction_to_arrow (menu_item->submenu_direction),
so the arrow points the right way;
however, it could conceivably be a useful lil' function elsewhere)

* GTK_DIRECTION_[LEFT,RIGHT] are kinda confusing names for -Submenu-
  directions; that is, they are confusingly similar to
  GTK_DIR_[LEFT,RIGHT]. Shouldn't they be renamed something like
  GTK_SUBMENU_DIR_[LEFT,RIGHT]?


Thus spake Owen Taylor:
> Nils Barth <nils_barth post harvard edu> writes:
> > Thus spake Owen Taylor:
> > > I seem to remember that you
> > > had another patch for switching the side of the arrow for
> > > submenus. When I looked at it, you could get that to do strange things
> > > with torn off menus and expose events, but it mostly looked pretty
> > > reasonable. Do you have that or an updated version around somewhere?
> > > (I probably can dig it up out of my mail if necessary.)
> > 
> > Yup -- I submitted that one before noticing the torn-off menus
> > problem. Could you elaborate on the expose event strangeness? If you
> > cover/expose it, it would point in the wrong direction?
> > 
> > Now that submenu nav is taken care of, I'll fix this up.
> > I guess I need to include a re-calculation of the direction for when
> > a torn-off menu is moved? Or every expose event?
> > We'll see....
> 
> The problem was that the direction _was_ being calculated for every
> expose event, so if you tore off the menu, moved it so
> the arrows would pop up in the opposite direction, then did
> a partial expose of the window, the exposed portions would be
> drawn pointing one way, the unexposed portions pointing the
> other way. (Expose half the arrow, get an hourglass shape)
> 
> The two solutions I can think of are:
> 
>  - Do the calculation when the window is moved. (You can do
>    this by selecting on GDK_EVENT_CONFIGURE on the toplevel
>    window), and queue a redraw when the direction changes.
> 
>  - When calculating the direction during the expose event,
>    note if it changed from the previous time, and if so
>    queue a redraw on the entire menu.
> 
> I'm not sure offhand which one is better.

Okay -- we need to calculate the arrow orientation (call
gtk_menu_item_position_menu for each submenu) at these times:
* The menu is first displayed (er, is this called ``mapped'', i.e.,
  the GDK_MAP event?)
* The menu is moved (the top window gets a GDK_CONFIGURE event)

These are the only times the orientation can change (and you need to
know it at the begining), so they should be the only times the
computation is done; then if the orientation changes, we need to queue a
redraw.

How do I do this??? That is:
 - how do I ``select'' on a GDK event so a function is called, and
 - how do I queue a redraw to the window?
   (do I GDK put an expose event for the whole menu item?)

references to code are okay (see how it's done here), but I couldn't
figure out just from API docs, and didn't want to do it incorrectly.

> I'd guess maybe
> the first might look a little less odd, though both will
> seem a little odd to the user. 

? I don't follow. In both cases (and any correct case), when the menu
is moved so that the submenu will pop up in the opposite direction,
the arrow is redrawn pointing the opposite way, right ?
I guess that's a little weird, but should only be surprising the first
time...

thanks for the help.

-- 
  -nils
Public key: http://www.fas.harvard.edu/~nbarth/pub-key.txt

Index: gtkmenuitem.c
===================================================================
RCS file: /cvs/gnome/gtk+/gtk/gtkmenuitem.c,v
retrieving revision 1.41
diff -u -r1.41 gtkmenuitem.c
--- gtkmenuitem.c	2000/07/26 11:32:45	1.41
+++ gtkmenuitem.c	2000/09/05 07:03:50
@@ -35,6 +35,7 @@
 
 #define BORDER_SPACING  3
 #define SELECT_TIMEOUT  75
+#define GTK_DIRECTION_DEFAULT  GTK_DIRECTION_RIGHT
 
 #define MENU_ITEM_CLASS(w)  GTK_MENU_ITEM_CLASS (GTK_OBJECT (w)->klass)
 
@@ -171,7 +172,7 @@
   menu_item->accelerator_width = 0;
   menu_item->show_toggle_indicator = FALSE;
   menu_item->show_submenu_indicator = FALSE;
-  menu_item->submenu_direction = GTK_DIRECTION_RIGHT;
+  menu_item->submenu_direction = GTK_DIRECTION_DEFAULT;
   menu_item->submenu_placement = GTK_TOP_BOTTOM;
   menu_item->right_justify = FALSE;
 
@@ -708,10 +709,10 @@
       break;
 
     case GTK_LEFT_RIGHT:
-      menu_item->submenu_direction = GTK_DIRECTION_RIGHT;
       parent_menu_item = GTK_MENU (GTK_WIDGET (menu_item)->parent)->parent_menu_item;
       if (parent_menu_item)
 	menu_item->submenu_direction = GTK_MENU_ITEM (parent_menu_item)->submenu_direction;
+      else menu_item->submenu_direction = GTK_DIRECTION_DEFAULT;
 
       switch (menu_item->submenu_direction)
 	{

GtkArrowType
gtk_submenu_direction_to_arrow (GtkSubmenuDirection direction)
{
  switch (direction)
    {
    case GTK_DIRECTION_LEFT:
      return GTK_ARROW_LEFT;
    default: /* i.e., GTK_DIRECTION_RIGHT */
      return GTK_ARROW_RIGHT;
    }
}