bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#25851: 25.2; GTK warning when starting Emacs when desktop file has m


From: N. Jackson
Subject: bug#25851: 25.2; GTK warning when starting Emacs when desktop file has more than one frame
Date: Sun, 26 Feb 2017 17:41:22 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

At 10:17 +0200 on Saturday 2017-02-25, Eli Zaretskii wrote:
>
> So we are back at square one: we need to understand why the warning
> isn't get silenced by this:
>
>       /* Silence warning about visible children.  */
>       id = g_log_set_handler ("Gtk", G_LOG_LEVEL_WARNING | G_LOG_FLAG_FATAL
>                               | G_LOG_FLAG_RECURSION, my_log_handler, NULL);
>
> Can you look into the source of g_warning and see why the above
> doesn't avoid these warnings, and what should we do to avoid it?

Hello Eli,

I was unsuccessful in this assignment (so far at least). I suspect
the answer is that GTK is using structured logging, but that is
just a wild guess at this point.

[I don't know how to do source-level debugging of code that I
didn't build myself. Both glib and Gtk+ on my system were
built/installed by the distribution's package manager and I have
only the source code from upstream, not the source code for the
exact versions on my system.]

I did ascertain that the log handler `my_log_handler' that we
install in the code snippet above is never called.

For testing purposes, I also installed a catch-all handler, with
g_log_set_default_handler(), and that doesn't get called either.

I have no direct experience at all with either glib or Gtk+, but
the documentation at [1] [I don't know for what version this is
for, or if it's even relevant], seems to say that
g_log_set_handler() has no effect if structured logging is turned
on. It seems to say that structured logging is in effect if
G_LOG_USE_STRUCTURED is defined.

There is some indication that Gtk+3.22.8 might use the new
structured logging. For example:

  $ grep -rn "G_LOG_USE_STRUCTURED" /data/projects/vc/gtk+-3.22.8/              
               
  /data/projects/vc/gtk+-3.22.8/gdk/mir/Makefile.in:526:  
-DG_LOG_USE_STRUCTURED=1        \
  /data/projects/vc/gtk+-3.22.8/gdk/mir/Makefile.am:9:    
-DG_LOG_USE_STRUCTURED=1        \
  /data/projects/vc/gtk+-3.22.8/gdk/Makefile.in:697:      
-DG_LOG_USE_STRUCTURED=1        \
  /data/projects/vc/gtk+-3.22.8/gdk/win32/Makefile.in:602:        
-DG_LOG_USE_STRUCTURED=1        \
  /data/projects/vc/gtk+-3.22.8/gdk/win32/Makefile.am:9:  
-DG_LOG_USE_STRUCTURED=1        \
  /data/projects/vc/gtk+-3.22.8/gdk/wayland/Makefile.in:537:      
-DG_LOG_USE_STRUCTURED=1                \
  /data/projects/vc/gtk+-3.22.8/gdk/wayland/Makefile.am:9:        
-DG_LOG_USE_STRUCTURED=1                \
  /data/projects/vc/gtk+-3.22.8/gdk/Makefile.am:38:       
-DG_LOG_USE_STRUCTURED=1        \
  /data/projects/vc/gtk+-3.22.8/gdk/x11/Makefile.in:535:  
-DG_LOG_USE_STRUCTURED=1        \
  /data/projects/vc/gtk+-3.22.8/gdk/x11/Makefile.am:9:    
-DG_LOG_USE_STRUCTURED=1        \
  /data/projects/vc/gtk+-3.22.8/gdk/quartz/Makefile.in:531:       
-DG_LOG_USE_STRUCTURED=1        \
  /data/projects/vc/gtk+-3.22.8/gdk/quartz/Makefile.am:8: 
-DG_LOG_USE_STRUCTURED=1        \
  /data/projects/vc/gtk+-3.22.8/gdk/broadway/Makefile.in:574:     
-DG_LOG_USE_STRUCTURED=1        \
  /data/projects/vc/gtk+-3.22.8/gdk/broadway/Makefile.am:10:      
-DG_LOG_USE_STRUCTURED=1        \
  /data/projects/vc/gtk+-3.22.8/gtk/Makefile.in:1325:     
-DG_LOG_USE_STRUCTURED=1                        \
  /data/projects/vc/gtk+-3.22.8/gtk/Makefile.am:7:        
-DG_LOG_USE_STRUCTURED=1                        \
  ...

I don't have any more direct evidence at this stage. I might press
on with this enquiry, but I admit I am way out of my depth at this
stage.

N.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]