GNU bug report logs - #57372
no-toolkit menu popups do not respect emacs font configuration

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Tomas Hlavaty <tom <at> logand.com>
Cc: luangruo <at> yahoo.com, 57372 <at> debbugs.gnu.org
Subject: bug#57372: no-toolkit menu popups do not respect emacs font configuration
Date: Wed, 24 Aug 2022 19:32:07 +0300

> From: Tomas Hlavaty <tom <at> logand.com>
> Cc: 57372 <at> debbugs.gnu.org
> Date: Wed, 24 Aug 2022 18:15:14 +0200
> 
> On Wed 24 Aug 2022 at 14:23, Eli Zaretskii <eliz <at> gnu.org> wrote:
> > Displaying pop-down menus with our display engine is "tricky", as the
> > TTY menus experience amply shows.
> 
> What does the tty menus experience show?

The implementation is extremely tricky, and basically blocks any input
as long as the menu is dropped down.  It works by overwriting portions
of the frame display's glyph matrices.  There are also complications
with binding keys to menu commands and with calculating the
coordinates where we need to drop down the menu.

> TTY menus seem fine except the extra > in menu-bar overlaps the next
> menu-bar item text.

That's by design, btw.

> In principle, it would be enough for me if the no-toolkit menus
> worked similar to TTY menus but respected faces instead of alien X
> resources.

TTY menus work, the tricky issues notwithstanding, because there's
only one font on TTY frames, and thus each line of the menu text
overwrites some part of exactly one line of the frame display.  That
is not possible to achieve on GUI frames, because faces and fonts
differ.  So the same technique as we use for TTY menus will not work
for GUI frame,s unfortunately, and if we try going that way in the X
no-toolkit build, the code will have to be much more complicated (if
it's at all feasible), and I think the result will be uglier.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.