Re: Menu bar items structure

[Manuel Giraud]

Po Lu <luangruo@yahoo.com> writes:

[...]

> I suggest not trying to change the internal menu representation.
>
> As it is, it allows easily creating very deeply nested menus, and
> garbage collection of menu items "just works".
>
> When working on the Haiku port, I tried to represent the menu bar
> contents in some more intuitive format, which led to garbage collection
> issues and C stack overflows with somewhat deeply nested menus.

That is unfortunate.  I was not trying to change the internal menu
representation for the sake of change but I have a problem with the no
toolkit menu bar.

The 4th element of a menu item is a char position in the menu bar for
this menu entry (filled with xdisp.c/display_menu_bar).  This char
position is then used to identify if mouse click is on this menu entry
(around line 6000 of keyboard.c)… but that does not work well if you
have changed your menu face font (eg. with (set-face-font 'menu
"AnotherFont-20")).  This seems to be because pixel_to_glyph_coords will
then be off.

To overcome this issue my idea was two fold:

      1- change the semantics of this index from a char position to a
         pixel position
         
      2- add a fifth element to a menu item that records the end
         position of a menu entry (also in pixel and filled in
         display_menu_bar)

I have a patch that does just that and it seems to work for me™… but I
see that it will also impact every other *term (on system I cannot even
test).  This led me to this kind of "refactoring" question.  Any ideas?
-- 
Manuel Giraud