[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Menu bar items structure
From: |
Po Lu |
Subject: |
Re: Menu bar items structure |
Date: |
Thu, 17 Nov 2022 18:06:24 +0800 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
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?
- Menu bar items structure, Manuel Giraud, 2022/11/16
- Re: Menu bar items structure, Eli Zaretskii, 2022/11/17
- Re: Menu bar items structure, Manuel Giraud, 2022/11/17
- Re: Menu bar items structure, Eli Zaretskii, 2022/11/17
- Re: Menu bar items structure, Manuel Giraud, 2022/11/18
Re: Menu bar items structure, Manuel Giraud, 2022/11/17