GNU bug report logs - #53916
29.0.50; pgtk: Gtk-WARNING with popup menu

Previous Next

To reply to this bug, email your comments to 53916 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; pgtk: Gtk-WARNING with popup menu
Date: Thu, 10 Feb 2022 11:43:43 +0100

0. emacs -Q
1. Disable with menu bar with `M-x menu-bar-mode'
2. Press the F10 key to invoke `menu-bar-open'
=> In the shell the following warning is emitted:

(emacs-pgtk:6569): Gtk-WARNING **: 11:39:05.713: no trigger event for menu popup


In GNU Emacs 29.0.50 (build 11, x86_64-pc-linux-gnu, GTK+ Version 3.24.31, cairo version 1.17.4)
 of 2022-02-10 built on strobelfs2
Repository revision: d3c47011d5ace1e1c3fca830d3ff71d9c693ed5d
Repository branch: master
System Description: Linux From Scratch r11.0-115

Configured using:
 'configure --with-pgtk --with-xwidgets 'CFLAGS=-Og -g3'
 PKG_CONFIG_PATH=/opt/qt5/lib/pkgconfig'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBSYSTEMD LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PGTK PNG
RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP XIM
XWIDGETS GTK3 ZLIB

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

From: Po Lu <luangruo <at> yahoo.com>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 53916 <at> debbugs.gnu.org
Subject: Re: bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu
Date: Thu, 10 Feb 2022 20:12:58 +0800

Stephen Berman <stephen.berman <at> gmx.net> writes:

> 0. emacs -Q
> 1. Disable with menu bar with `M-x menu-bar-mode'
> 2. Press the F10 key to invoke `menu-bar-open'
> => In the shell the following warning is emitted:
>
> (emacs-pgtk:6569): Gtk-WARNING **: 11:39:05.713: no trigger event for menu popup

That warning is harmless, though we could make it go away by installing
a log handler.  Someone else should chime in at this point to decide
whether or not that's worth it, since such a filter might end up
obscuring legitimate problems in the future.

Alternatively, we could do the same dance with "saved menu events" as on
X.  That would make the warning go away, but is very much not
recommended for a well-behaved GTK program (which the PGTK port already
isn't, but I don't see a reason to make that problem even worse.)

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: Po Lu <luangruo <at> yahoo.com>, 53916 <at> debbugs.gnu.org
Subject: Re: bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu
Date: Thu, 10 Feb 2022 13:52:35 +0100

Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs <at> gnu.org> writes:

> That warning is harmless, though we could make it go away by installing
> a log handler.  Someone else should chime in at this point to decide
> whether or not that's worth it, since such a filter might end up
> obscuring legitimate problems in the future.

My impression is that most of these warnings from GTK are harmless, so
perhaps having a log handler (and defaulting it to "off") would be good.
(But there should be a user option to switch them on.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Po Lu <luangruo <at> yahoo.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Stephen Berman <stephen.berman <at> gmx.net>, 53916 <at> debbugs.gnu.org
Subject: Re: bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu
Date: Thu, 10 Feb 2022 21:03:59 +0800

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
> editors" <bug-gnu-emacs <at> gnu.org> writes:
>
>> That warning is harmless, though we could make it go away by installing
>> a log handler.  Someone else should chime in at this point to decide
>> whether or not that's worth it, since such a filter might end up
>> obscuring legitimate problems in the future.
>
> My impression is that most of these warnings from GTK are harmless, so
> perhaps having a log handler (and defaulting it to "off") would be good.
> (But there should be a user option to switch them on.)

I'm okay with doing that for this particular warning, and the
appropriate option already exists (the G_DEBUG environment variable can
be set to `fatal-warnings', which will cause GLib to abort upon
encoutering such a warning, even if we filter it out.)

But I don't know whether or not it's okay to treat all warnings that
way.  For example, bug#53900 is a serious bug that got caught by someone
noticing a warning emitted by GTK, and presumably wouldn't have been
reported if the warning had been filtered out.

Thanks.

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: Po Lu <luangruo <at> yahoo.com>, 53916 <at> debbugs.gnu.org
Subject: Re: bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu
Date: Thu, 10 Feb 2022 14:30:27 +0100

>>>>> On Thu, 10 Feb 2022 20:12:58 +0800, Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org> said:

    Po> Stephen Berman <stephen.berman <at> gmx.net> writes:
    >> 0. emacs -Q
    >> 1. Disable with menu bar with `M-x menu-bar-mode'
    >> 2. Press the F10 key to invoke `menu-bar-open'
    >> => In the shell the following warning is emitted:
    >> 
    >> (emacs-pgtk:6569): Gtk-WARNING **: 11:39:05.713: no trigger event for menu popup

    Po> That warning is harmless, though we could make it go away by installing
    Po> a log handler.  Someone else should chime in at this point to decide
    Po> whether or not that's worth it, since such a filter might end up
    Po> obscuring legitimate problems in the future.

Can such a log handler put those warnings in *Messages*?

Robert
-- 

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

From: Po Lu <luangruo <at> yahoo.com>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: Stephen Berman <stephen.berman <at> gmx.net>, 53916 <at> debbugs.gnu.org
Subject: Re: bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu
Date: Thu, 10 Feb 2022 21:31:17 +0800

Robert Pluim <rpluim <at> gmail.com> writes:

>     Po> That warning is harmless, though we could make it go away by installing
>     Po> a log handler.  Someone else should chime in at this point to decide
>     Po> whether or not that's worth it, since such a filter might end up
>     Po> obscuring legitimate problems in the future.
>
> Can such a log handler put those warnings in *Messages*?

Yes.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: rpluim <at> gmail.com, stephen.berman <at> gmx.net, 53916 <at> debbugs.gnu.org
Subject: Re: bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu
Date: Thu, 10 Feb 2022 19:40:28 +0200

> Resent-From: Po Lu <luangruo <at> yahoo.com>
> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
> Resent-CC: bug-gnu-emacs <at> gnu.org
> Resent-Sender: help-debbugs <at> gnu.org
> Cc: Stephen Berman <stephen.berman <at> gmx.net>, 53916 <at> debbugs.gnu.org
> Date: Thu, 10 Feb 2022 21:31:17 +0800
> From:  Po Lu via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> Robert Pluim <rpluim <at> gmail.com> writes:
> 
> >     Po> That warning is harmless, though we could make it go away by installing
> >     Po> a log handler.  Someone else should chime in at this point to decide
> >     Po> whether or not that's worth it, since such a filter might end up
> >     Po> obscuring legitimate problems in the future.
> >
> > Can such a log handler put those warnings in *Messages*?
> 
> Yes.

I wouldn't recommend mixing GTK diagnostics with *Messages*.  Why not
have a separate buffer for the GTK messages?

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

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rpluim <at> gmail.com, stephen.berman <at> gmx.net, 53916 <at> debbugs.gnu.org
Subject: Re: bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu
Date: Fri, 11 Feb 2022 08:59:08 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Resent-From: Po Lu <luangruo <at> yahoo.com>
>> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
>> Resent-CC: bug-gnu-emacs <at> gnu.org
>> Resent-Sender: help-debbugs <at> gnu.org
>> Cc: Stephen Berman <stephen.berman <at> gmx.net>, 53916 <at> debbugs.gnu.org
>> Date: Thu, 10 Feb 2022 21:31:17 +0800
>> From:  Po Lu via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>> 
>> Robert Pluim <rpluim <at> gmail.com> writes:
>> 
>> >     Po> That warning is harmless, though we could make it go away by installing
>> >     Po> a log handler.  Someone else should chime in at this point to decide
>> >     Po> whether or not that's worth it, since such a filter might end up
>> >     Po> obscuring legitimate problems in the future.
>> >
>> > Can such a log handler put those warnings in *Messages*?
>> 
>> Yes.
>
> I wouldn't recommend mixing GTK diagnostics with *Messages*.  Why not
> have a separate buffer for the GTK messages?

I think it would be confusing to have such a buffer suddenly appear.
How about prefixing the messages with "GTK diagnostic"?

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: Stephen Berman <stephen.berman <at> gmx.net>, 53916 <at> debbugs.gnu.org
Subject: Re: bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu
Date: Fri, 11 Feb 2022 07:20:10 +0100

Po Lu <luangruo <at> yahoo.com> writes:

> But I don't know whether or not it's okay to treat all warnings that
> way.  For example, bug#53900 is a serious bug that got caught by someone
> noticing a warning emitted by GTK, and presumably wouldn't have been
> reported if the warning had been filtered out.

That's true.  Perhaps redirecting the messages to *Messages* instead of
stderr (and do no filtering per default?) is a better solution indeed.
(I think the having the warnings in the terminal looks a bit
unprofessional and untidy, so keeping them inside Emacs would help.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Po Lu <luangruo <at> yahoo.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Stephen Berman <stephen.berman <at> gmx.net>, 53916 <at> debbugs.gnu.org
Subject: Re: bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu
Date: Fri, 11 Feb 2022 14:24:07 +0800

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Po Lu <luangruo <at> yahoo.com> writes:
>
>> But I don't know whether or not it's okay to treat all warnings that
>> way.  For example, bug#53900 is a serious bug that got caught by someone
>> noticing a warning emitted by GTK, and presumably wouldn't have been
>> reported if the warning had been filtered out.
>
> That's true.  Perhaps redirecting the messages to *Messages* instead of
> stderr (and do no filtering per default?) is a better solution indeed.
> (I think the having the warnings in the terminal looks a bit
> unprofessional and untidy, so keeping them inside Emacs would help.)

Great, does anyone know what "%s" parameters to `add_to_log' are
expected in?  UTF-8?

Thanks in advance.

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

From: Po Lu <luangruo <at> yahoo.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Stephen Berman <stephen.berman <at> gmx.net>, 53916 <at> debbugs.gnu.org
Subject: Re: bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu
Date: Fri, 11 Feb 2022 14:26:21 +0800

Po Lu <luangruo <at> yahoo.com> writes:

> Great, does anyone know what "%s" parameters to `add_to_log' are
> expected in?  UTF-8?

About 5 seconds after sending this, I realized that it accepts Lisp
objects and format control strings like `format'.

So hopefully that means it will be okay to print out unibyte strings via
that mechanism, since I don't want to go down the rabbit hole of what
text encodings various libraries using the GLib logging system subject
it to.

Thanks.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: rpluim <at> gmail.com, stephen.berman <at> gmx.net, 53916 <at> debbugs.gnu.org
Subject: Re: bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu
Date: Fri, 11 Feb 2022 09:18:51 +0200

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: rpluim <at> gmail.com,  stephen.berman <at> gmx.net,  53916 <at> debbugs.gnu.org
> Date: Fri, 11 Feb 2022 08:59:08 +0800
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> > Can such a log handler put those warnings in *Messages*?
> >> 
> >> Yes.
> >
> > I wouldn't recommend mixing GTK diagnostics with *Messages*.  Why not
> > have a separate buffer for the GTK messages?
> 
> I think it would be confusing to have such a buffer suddenly appear.

Why confusing?  We already have in Emacs 28 and later a buffer named
*Async-native-compile-log* that "suddenly appears" as soon as Emacs
needs for the first time to natively-compile a Lisp file.  How is this
case different?

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

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rpluim <at> gmail.com, stephen.berman <at> gmx.net, 53916 <at> debbugs.gnu.org
Subject: Re: bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu
Date: Fri, 11 Feb 2022 15:25:49 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

> Why confusing?  We already have in Emacs 28 and later a buffer named
> *Async-native-compile-log* that "suddenly appears" as soon as Emacs
> needs for the first time to natively-compile a Lisp file.  How is this
> case different?

That one is a log of things Emacs is doing, while this one usually
appears without context, and could contain scary error messages from
various different libraries.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: larsi <at> gnus.org, stephen.berman <at> gmx.net, 53916 <at> debbugs.gnu.org
Subject: Re: bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu
Date: Fri, 11 Feb 2022 09:59:41 +0200

> Cc: Stephen Berman <stephen.berman <at> gmx.net>, 53916 <at> debbugs.gnu.org
> Date: Fri, 11 Feb 2022 14:26:21 +0800
> From:  Po Lu via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> Po Lu <luangruo <at> yahoo.com> writes:
> 
> > Great, does anyone know what "%s" parameters to `add_to_log' are
> > expected in?  UTF-8?
> 
> About 5 seconds after sending this, I realized that it accepts Lisp
> objects and format control strings like `format'.

Yes, the arguments are Lisp strings.

> So hopefully that means it will be okay to print out unibyte strings via
> that mechanism, since I don't want to go down the rabbit hole of what
> text encodings various libraries using the GLib logging system subject
> it to.

Just use DECODE_SYSTEM, the encoding is already figured out for you.

Please do NOT use the original unibyte strings, they are likely to
display as gibberish in some cases.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: rpluim <at> gmail.com, stephen.berman <at> gmx.net, 53916 <at> debbugs.gnu.org
Subject: Re: bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu
Date: Fri, 11 Feb 2022 10:10:42 +0200

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: rpluim <at> gmail.com,  stephen.berman <at> gmx.net,  53916 <at> debbugs.gnu.org
> Date: Fri, 11 Feb 2022 15:25:49 +0800
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Why confusing?  We already have in Emacs 28 and later a buffer named
> > *Async-native-compile-log* that "suddenly appears" as soon as Emacs
> > needs for the first time to natively-compile a Lisp file.  How is this
> > case different?
> 
> That one is a log of things Emacs is doing, while this one usually
> appears without context, and could contain scary error messages from
> various different libraries.

I don't see the crucial difference.

From my POV, having GTK messages in *Messages* will make debugging
Emacs's own problems harder.  Some redisplay problems are only
visible in *Messages* (because we cannot signal an error), and having
the buffer filled up by irrelevant GTK stuff will make reading the
messages harder, and could even make the important messages disappear,
if the GTK stuff overflows message-log-max.

So I really prefer a separate buffer.

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

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, stephen.berman <at> gmx.net, 53916 <at> debbugs.gnu.org
Subject: Re: bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu
Date: Fri, 11 Feb 2022 19:11:28 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Cc: Stephen Berman <stephen.berman <at> gmx.net>, 53916 <at> debbugs.gnu.org
>> Date: Fri, 11 Feb 2022 14:26:21 +0800
>> From:  Po Lu via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>> 
>> Po Lu <luangruo <at> yahoo.com> writes:
>> 
>> > Great, does anyone know what "%s" parameters to `add_to_log' are
>> > expected in?  UTF-8?
>> 
>> About 5 seconds after sending this, I realized that it accepts Lisp
>> objects and format control strings like `format'.
>
> Yes, the arguments are Lisp strings.
>
>> So hopefully that means it will be okay to print out unibyte strings via
>> that mechanism, since I don't want to go down the rabbit hole of what
>> text encodings various libraries using the GLib logging system subject
>> it to.
>
> Just use DECODE_SYSTEM, the encoding is already figured out for you.
>
> Please do NOT use the original unibyte strings, they are likely to
> display as gibberish in some cases.

Thanks.

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

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rpluim <at> gmail.com, stephen.berman <at> gmx.net, 53916 <at> debbugs.gnu.org
Subject: Re: bug#53916: 29.0.50; pgtk: Gtk-WARNING with popup menu
Date: Fri, 11 Feb 2022 19:12:55 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

> I don't see the crucial difference.
>
> From my POV, having GTK messages in *Messages* will make debugging
> Emacs's own problems harder.  Some redisplay problems are only
> visible in *Messages* (because we cannot signal an error), and having
> the buffer filled up by irrelevant GTK stuff will make reading the
> messages harder, and could even make the important messages disappear,
> if the GTK stuff overflows message-log-max.
>
> So I really prefer a separate buffer.

Okay, reasonable enough, thanks.

Previous Next

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