Unable to find what would be the log domain name for gtkbuilder.c

Platform Core
, ,
1

I would like to redirect messages from g_warning() and similar functions from gtkbuilder.c such as the famous:

(main.exe:39280): Gtk-WARNING **: 01:34:48.787: Could not find signal
ha ndler ‘on_window_realize’. Did you compile with -rdynamic?

using g_log_set_handler(). It expects the domain name as the first parameter, which is what I can’t seem to find. If G_LOG_DOMAIN is not defined in the source then it defaults to NULL in which case I won’t be able to use g_log_set_handler() to redirect it.

What is the log domain name for it or alternatively - how can I redirect those messages after all (I am redirecting them to a GtkTextBuffer)?

2

All warnings coming from GTK have a Gtk log domain.

Libraries typically define their own log domain; ideally, this would be documented in the API reference, but if it isn’t, you can still check the source code for G_LOG_DOMAIN definitions.

3

How do I do that? I don’t use github. It appears to me that I’ll have to devote a lot of time in investigations and I may not find a solution to the problem, which is why I am relying on someone who already knows this.
The documentation about GtkBuilder does not mention this, probably, because it is self-explanatory in some way.

I already have set a handler from “Gtk” domain and this does not filter those messages.

4

Good thing that GTK doesn’t use GitHub either.

You can check in the meson.build file, for GTK. Other libraries may have a:

#define G_LOG_DOMAIN "Foo"

in their sources, before importing <glib.h>.

There is an example in the documentation for g_log_set_handler(), though to catch a g_warning() you will need to add G_LOG_LEVEL_WARNING to the mask.

5

g_log_set_handler(“Gtk”, G_LOG_LEVEL_CRITICAL | G_LOG_FLAG_FATAL | G_LOG_FLAG_RECURSION, critical_handler, NULL);
g_log_set_handler(“Gtk”, G_LOG_LEVEL_WARNING | G_LOG_FLAG_FATAL | G_LOG_FLAG_RECURSION, warning_handler, NULL);
g_log_set_handler(“Glib-GObject”, G_LOG_LEVEL_CRITICAL | G_LOG_FLAG_FATAL | G_LOG_FLAG_RECURSION, critical_handler, NULL);
g_log_set_handler(“GLib-GObject”, G_LOG_LEVEL_WARNING | G_LOG_FLAG_FATAL | G_LOG_FLAG_RECURSION, warning_handler, NULL);
g_log_set_handler(“GLib”, G_LOG_LEVEL_WARNING | G_LOG_FLAG_FATAL | G_LOG_FLAG_RECURSION, warning_handler, NULL);
g_log_set_handler(“GLib”, G_LOG_LEVEL_CRITICAL | G_LOG_FLAG_FATAL | G_LOG_FLAG_RECURSION, critical_handler, NULL);
g_log_set_handler(NULL, G_LOG_LEVEL_WARNING | G_LOG_FLAG_FATAL | G_LOG_FLAG_RECURSION, warning_handler, NULL);
g_log_set_handler(NULL, G_LOG_LEVEL_CRITICAL | G_LOG_FLAG_FATAL | G_LOG_FLAG_RECURSION, critical_handler, NULL);

Is what I’ve wrote. It doesn’t catch those warnings from builder.

6

Might I suggest you put the mallet down and fix the problem (i.e. on_window_realize)?

7

Nope, I am re-writing application, which leaves it with trailing signal handlers specified by Glade.
I want to use my own Gtk-based debug terminal to filter out certain messages.

8

Ah, of course: GTK is using structured logging, which means the g_log_set_handler() won’t work:

This has no effect if structured logging is enabled;
see [Using Structured Logging][using-structured-logging].

You will need to use g_log_set_writer_func() instead, with your GLogWriterFunc callback. The log domain is inside the GLIB_DOMAIN field in the GLogField data structure passed to the callback.

9

Ah, thanks. I will try that. I did read about “structured logging”, but I wasn’t familiar with this term. I didn’t know what exactly it means and how to get around it. It was a bit confusing to be honest.

By the way, I admire your work :slight_smile:
Quite big of a GTK+ application is coming soon. Where do you suggest me announcing it?
Which community will be happiest about showcasing GTK+ applications? The bigger one if possible.

10

But …why?

It’s a problem that needs fixing, either fix it now or leave it for later

Blindly silencing it doesn’t solve anything. In fact you’ve probably spent more time playing with logging than you would need to fix it :slight_smile:

11

As I said, those are expected messages because of the lacking signal handlers in the sources due to rewriting from scratch, using the same gui description file. I’ll be slowly implementing them. I am not “silencing” the problem. I said that I am simply redirecting the output to a custom terminal. Other than the fact that what you said has nothing to do with me, you are absolutely right.

12

Check out if your application matches circle.gnome.org

13

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.