Re: Turn off GTK+ warnings



On 01/04/17 20:24, Emmanuele Bassi wrote:
On 1 April 2017 at 11:05, Stuart Longland <stuartl longlandclan id au> wrote:
On 01/04/17 17:41, Stefan Salewski wrote:
On Sat, 2017-04-01 at 16:53 +1000, Stuart Longland wrote:
How, as a user, do I go about silencing these warnings?

- Doctor, doctor! My arm hurts when I move it this way!
- Then don't move it this way

You're blaming the nervous system notifying you that you're doing
something wrong and/or painful, and you're asking to ignore the pain,
instead of figuring out the cause and fixing that.

The pain you feel is the message; you fix the cause, not the pain.

If my arm were sore, I'd see a doctor, I would not bother seeing a
police officer about it, at best they'll simply refer me to a doctor, at
worst they may choose to press charges on wasting police time.

GTK+ is complaining to me about its "sore arm" … it should really go see
the "doctor" (the application developer).

I don't think it is a good idea to ignore such warnings as a user in
general case. There may be very few warnings, for which it may be ok to
ignore it. But generally, there is a reason why warnings are shown.
Indicating that something is wrong, and the software may not work
properly.

I would very strong try to avoid software which continuesly emit
warnings -- that may be an indication that the software is stale,
nobody cares about it, so it may have dangerous (security) bugs.

One example was indeed gvim, I have stopped using it.

Well, in my case it isn't `gvim` that's emitting the warnings, its GTK+.
 `gvim`'s (ab)use of the GTK+ library might be the underlying cause, but
GTK+ is what's polluting stderr.

GTK+ is not "polluting" stderr: it's emitting a warning that the
application is doing something wrong at run time. The application is
causing the warning.

GTK+'s warning is polluting stderr.  stderr is meant for the application
to report things via the console, not GTK+.  GTK+ has permission to talk
to the X server, but not to stderr.

In the case of `gvim`, they don't think it's their problem:
https://github.com/vim/vim/issues/1149

I have a hunch it is theme-related.  I tried several before finally
settling on the vertex theme, which seemed to generate less errors than
others, including the default GTK+ theme.

That puts the ball firmly in GTK+'s court in my book.

You should file a bug against the application that is creating those
warnings.

I have, right here.  Those warnings are being emitted by GTK+.  This is
the GTK+ mailing list.

My proposal for a fix is that the warnings should be conditional on some
run-time flag which is enabled by GTK+ application developers.

Then developers can get all the warnings they want, even more detail
then they get now.

In a perfect world, the developer would be looking for and fixing those
issues.  As you can see from this email thread, and the above linked bug
report, we live in a real world, not a perfect one.

As mentioned, it isn't just `gvim` that's an offender here… this is from
my .xsession-errors:

(gkrellm:4216): GLib-GObject-WARNING **: The property GtkWindow:allow-shrink is deprecated and shouldn't be 
used anymore. It will be removed in a future version.
(nm-applet:4201): GLib-GObject-WARNING **: The property GtkButton:use-stock is deprecated and shouldn't be 
used anymore. It will be removed in a future version.
(pasystray:4197): GLib-GObject-WARNING **: The property GtkButton:use-stock is deprecated and shouldn't be 
used anymore. It will be removed in a future version.
(firefox:4256): GLib-GObject-WARNING **: The property GtkSettings:gtk-menu-images is deprecated and 
shouldn't be used anymore. It will be removed in a future version.
(thunderbird:4259): Gtk-CRITICAL **: IA__gtk_clipboard_set_with_data: assertion 'targets != NULL' failed
(gimp:12309): Gtk-WARNING **: Unable to locate theme engine in module_path: "adwaita",
(gimp:12309): Gtk-WARNING **: Unable to locate theme engine in module_path: "adwaita",
Gtk-Message: (for origin information, set GTK_DEBUG): failed to retrieve property 
`gtk-primary-button-warps-slider' of type `gboolean' from rc file value "((GString*) 0x558da0738da0)" of 
type `gboolean'

Some of those are Gnome projects.

Of course, since some application authors simply don't care
that their application is generating warnings (otherwise they'd have
already fixed it) your bet as to what will happens next is as good as
mine. As a toolkit developer I can only tell you that GTK+ won't stop
emitting those warnings because that's how application developers
identify and fix bugs in their code — and, sometimes, in GTK+ itself.

As I said before, I'm not saying getting rid of the warnings, I'm
saying, have a facility to turn them on and off at runtime and perhaps
re-direct them to a place where they may be more useful.

It does not need to be fancy.  A check for an environment variable at
start up initialising a uint8_t tucked away somewhere in GTK+'s bowels
would suffice; if non-zero, emit a warning, if zero, shut up.

If you really need that software, you may contact its author or
maintainers of your OS distribution, maybe it is a problem of the
distribution, maybe they ship too old or incompatible libraries or are
doing something just wrong.

Well as it happens, I do need GTK+, and hence, I believe this is the
mailing list for the authors of GTK+. :-)

This is gtk-list; if you want to contact the GTK+ developers you
should use gtk-devel-list gnome org.

We'll tell you the same thing I told you above, though: file a bug
against the application that emits the warnings.

No problems, I'll track down the GTK+ bug tracker and file a bug
accordingly.

So we should be happy that these warnings are shown at all, it would be
much worse when they are invisible or do not exist at all and software
just malfunctions in rare cases.

I'm not saying to get rid of the warnings, to a developer, they are very
useful clues as to what might be wrong with an application.

For me as a user, they are useless junk that is cluttering up my
terminal session, pushing data I actually *do* care about off the
scrollback buffer and making my life harder.

There's no way for an application, or a library, or any computer
program really, to discern intent or context.

No, there isn't yet… so let's give it a mechanism for telling it what's
going on.

Even if there was a way for you to provide context — an environment
variable, a toggle to remove warnings — the underlying issue is that
anything that comes after a critical warning inside GTK+ steps you
into "undefined behaviour" territory. Your application may cease to
work at any point, eat all your data, and turn you into a frog,
waiting for the kiss of minor royalty to break the spell.

Yep, and in such cases, the debugging procedure can be something along
the lines of:

GTK_ENABLE_WARNINGS=1 ./mybuggyapp

… and try to reproduce the bug whilst looking at what the warning
messages are telling you.

Even better is:

GTK_ENABLE_WARNINGS=/path/to/logfile ./mybuggyapp

Then you've got a log you can email around.

A "simple"
warning is less severe, but generally points to a misuse of the GTK+
API to the point of breaking internal assumptions — and it usually
leads to a critical warning somewhere down the line, with all that it
entails (crash, data loss, amphibian transfiguration).

You, as a user, have a single recourse: file a bug against the
application that causes the warning.

I'm saying these warnings can be better handled, and should be better
handed.  It isn't rocket science; the following would suffice:

/* in GTK+ somewhere */
static uint8_t verbose_warnings = 0;
…
if (getenv("GTK_ENABLE_WARNINGS")) {
    verbose_warnings = 1;

…

if (verbose_warnings)
    fprintf(stderr, "(%s:%d): Gtk-WARNING **: Amphibious transmutation
in progress!!!\n", argv[0], getpid());

For full-time GTK+ (application) developers, GTK_ENABLE_WARNINGS can be
set in .profile.
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.

Attachment: signature.asc
Description: OpenPGP digital signature



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