GNU bug report logs - #64270
30.0.50; Font update for no toolkit menu

Previous Next

Package: emacs;

Reported by: Manuel Giraud <manuel <at> ledu-giraud.fr>

Date: Sat, 24 Jun 2023 17:01:02 UTC

Severity: normal

Found in version 30.0.50

Fixed in version 30.1

Done: Manuel Giraud <manuel <at> ledu-giraud.fr>

Bug is archived. No further changes may be made.

Full log


Message #83 received at 64270 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 64270 <at> debbugs.gnu.org
Subject: Re: bug#64270: 30.0.50; Font update for no toolkit menu
Date: Wed, 28 Jun 2023 17:20:55 +0800
Manuel Giraud <manuel <at> ledu-giraud.fr> writes:

> That is interesting.  This means that a face used in a frame might not
> exists in a form that is loadable by XLoadQueryFont, right?  So I think
> it is real shortcoming of what I wanted to do.

Yes.  The X core font requests can only utilize fonts that are present
on the X server, which precludes using any font from a FreeType-based
font driver.

> Yes, I know.  Everytime I'm trying to do something on oldXMenu this idea
> keep resurfacing.  But it is quite a task and oldXMenu is already here
> and not that bad.  Do you think that child frames could be a starting
> point for menus?

I don't think so; frames are quite resource intensive and slow to
create.  Child frames have also always been a mess, and they are
obscured by ancestor windows.  If we were to implement menus in terms of
frames, it would be better to apply an owner-events grab to an
override-redirect frame (as usual among X clients), but even that would
be slow.




This bug report was last modified 1 year and 323 days ago.

Previous Next


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