GNU bug report logs - #50067
Context menus

Previous Next

Full log

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

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: alan <at> idiocy.org, mattiase <at> acm.org, homeros.misasa <at> gmail.com,
 tkk <at> misasa.okayama-u.ac.jp, larsi <at> gnus.org, 50067 <at> debbugs.gnu.org
Subject: Re: bug#50067: Context menus
Date: Thu, 19 Aug 2021 10:12:54 +0300

>> >> I guess the presence of the title should be platform-dependent.
>> >> For example, without a title it looks great on the GTK build.
>> >
>> > What happens if the GTK build displays a TTY frame?  Isn't the menu
>> > definition global, and thus doesn't distinguish between frame types?
>> 
>> The menu definition is constructed dynamically, so it possible
>> to set the title when (framep (selected-frame)) returns t on tty.
>
> OK, but as I wrote elsewhere, I think the string should always be
> present, and if some GUI toolkit wants to ignore it, it should avoid
> putting it into the native menu structure when it creates the menu
> widget(s).  The Lisp data should remain the same, IMO.

GUI toolkits can't ignore titles for all menus.  Some menus should be
displayed with a title for all toolkits.  The context menu is special.
Nowadays everyone is accustomed to down-mouse-3 popping up a context menu
without title.  But other Emacs-specific menus that are not familiar to users
such as mouse-buffer-menu bound C-<down-mouse-1> should display a title
for all toolkits to explain to the user what choice the menu presents.

Previous Next

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