Re: Menu bar items structure

[Po Lu <luangruo@yahoo.com>]

Manuel Giraud <manuel@ledu-giraud.fr> writes:

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

Why use pixel_to_glyph_coords?  Why not use x_y_to_hpos_vpos on the menu
bar pseudo-window?