GNOME.org
 

Re: Turn off GTK+ warnings

On 1 April 2017 at 12:00, Stuart Longland <stuartl longlandclan id au> wrote:

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.


You stretched the metaphor until it broke.


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


GTK+, by itself, cannot do anything. You're endowing it with
supernatural powers.

At most, GTK+ can warn the application developer during the
development phase, and the QA phase. If the application developers
decide to release their code with warnings in it, or if they don't
test with newer versions of their dependencies and don't bundle them,
then it's still their responsibility to fix the warnings.


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


They are wrong.

The "mapped child but invisible parent" warning is a violation of the
documented invariants for GTK+ widgets; a child widget being mapped
requires that all its ancestors, up to the top level, are visible.

If you're getting that warning it means that the application developer
is doing something *very* wrong; considering how gvim abuses GTK+ as
if it were an X11 toolkit from the '90s, that does not surprise me one
bit.


I have a hunch it is theme-related.


It's not, unless you're using GTK+ 2.x, where themes were free to
inject random code inside the toolkit internals, and could manipulate
the widget hierarchy. That is not possible any more in GTK+ 3.x.


 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.


It really doesn't.


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.


You seem to operate under the misunderstanding that GTK+ emits those
warnings for internal reasons. It does not. GTK+, by itself, doesn't
do anything. You have to build an application to use it, and by doing
so, you have to respect the API contract that GTK+ provides. If you
break the contract, you typically get a crash — but, if you're lucky,
you get a warning first.


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


That does not work, demonstrably, as it been attempted multiple times.

The second we hid all the warnings, and told application developers to
enable them for their own purposes, is the second application
developers would simply ignore the warnings, and release buggy code.
They already do this with *visible* warnings.

We tried this approach already, and (unsurprisingly) it didn't work.
We also tried to be more drastic, and crash on warning during
development cycles, so that application developers would catch errors
during development; it didn't work either, because application
developers do *not* use development releases of GTK+ to test their
code, which means that they would simply not see the errors at all.

I, jokingly, proposed to have a modal dialog printing out the warning
by blocking the UI until a "Dismiss" button was clicked — which would
likely cause application developers to hunt me down with torches and
pitchforks.

The problem is that users can live perfectly fine with warnings, and
application developers are perfectly fine with ignoring them until
something crashes. The other problem is that, from a library
perspective, we cannot control what application developers do, or how
they decide to test their code, which means we need to rely on users
seeing these errors and complain to application developers.


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.


Deprecation warnings are perfectly fine; those we could likely make
conditional, but, again, application developers would never port their
code if that were the case. We're still debating this in the GTK+
team.


(thunderbird:4259): Gtk-CRITICAL **: IA__gtk_clipboard_set_with_data: assertion 'targets != NULL' failed


This is a critical warning; anything after this means that Thunderbird
is relying on undefined behaviour. You should file a bug.


(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",


This is a user error: you're attempting to configure your system with
the wrong GTK+ theme (the name is "Adwaita", not "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'


This is a broken configuration: you're using the wrong value for the
'gtk-primary-button-warps-slider' in your gtkrc file.


Some of those are Gnome projects.


I never claimed that GNOME developers are perfect; they ignore
critical warnings as well (also, only nm-applet is a GNOME project, of
all those listed there).


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.


They are usually directed to the systemd journal, on modern systems,
where they can be searched and isolated, with additional metadata
attached to them, like location in the source.

It seems you're using xsession-errors, which is limited by the textual
format you're using.


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.


Thanks for assuming we're all idiots who do not know how to write a
simple debugging toggle.

The GLib logging API is fairly more powerful than that, and we are
already using it; the problem is not writing the code, or adding the
code.


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.


And, once again, you confuse "application" with "library".

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]