Re: Turn off GTK+ warnings
On 01/04/17 21:45, Emmanuele Bassi wrote:
> On 1 April 2017 at 12:00, Stuart Longland <stuartl@xxxxxxxxxxxxxxxxxx> wrote:
>> On 01/04/17 20:24, Emmanuele Bassi wrote:
>>> On 1 April 2017 at 11:05, Stuart Longland <stuartl@xxxxxxxxxxxxxxxxxx> 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.
Maybe so, but it is the *developer's* responsibility, not the *user's*
If I tell it "I'm a developer", sure, go to town and tell me everything.
If "I'm a user", don't bother. Yes, the application might crash … then
it'll look like the application is at fault (which it is), not GTK+.
>>>> 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:
> 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
And as a user, what am I supposed to do about it other than file a bug
report with them (which has been done)? If they want to hear no more
about it, nor do I.
>> 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.
The number of warnings did go down in gvim's case when I recompiled
against GTK+2.0, linking against GTK+3.0 makes things very unstable.
>> 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.
Well, a buggy theme is hardly the application's fault is it? You are
right in that it isn't GTK+'s either, but unless the user wrote the
theme themselves, we can conclude the user didn't cause this.
>>> You should file a bug against the application that is creating those
>> 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.
I am not disagreeing with you on the latter point. But GTK+ chooses to
use `stderr` as its means of reporting errors, and that's what I take
More to the point, I, as a user, did not break that contract, the
application did. So what good is it moaning to the user?
None whatsoever. All it does is drag GTK+ devs into the firing line as
this thread demonstrates.
>> 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.
The alternate approach is to make it on by default, but still possible
to turn off. I came here hoping such a flag existed.
> 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
So we choose the alternate UI channel by messing with the application's
third file handle… not great either.
> 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.
Yes, and if the application developers were proactive about it, that
would be fine.
If I as a user start experiencing problems with an application that
actually cause me grief… I start investigating. In the case of `gvim`,
I saw that bug, saw they considered it "not a problem of vim", and so
far the problem has not prevented vim from working as expected.
So it starts to sound like the boy who cried wolf.
>> 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+
As you point out though, it's something application developers need to
do, not the end users. If the application developer is not willing to
do something about it, pestering the user gains almost nothing but ire
from the user concerned.
>>> (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.
Maybe… sometimes they can be uncaring about bugs too.
>>> (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").
In this case, since it is something the user *can* do something about,
wouldn't the above modal approach be a better option? I only saw that
message when I deliberately went looking for it.
>>> 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).
Fair enough, I thought The Gimp was also under the Gnome group of
projects, given GTK+ started as a toolkit for The Gimp (replacing Motif).
>>> 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.
Yep, I have not made the jump to systemd as yet, still debating whether
I should. That is a separate matter though.
>> 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.
Well, it seemed as if I was asking for the impossible.
Control over the visibility of those messages is all I ask for. Default
on, default off, don't care ultimately, but something I can set to make
An environment variable has the advantage that it can be overridden for
specific cases if needed. i.e. if debugging a crash.
A setting in .gtkrc also works, although not as easily overridden.
If I have to add GTK_SILENT=1 to .profile and manually unset GTK_SILENT,
that's fine. That achieves the objective, and works for this purpose.
It also means those warnings are not hidden from developers.
> 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
I figured it was more advanced than `fprintf`, which suggests to me that
adding this feature should be a fairly painless and trivial affair.
>>> 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
> And, once again, you confuse "application" with "library".
Well, if I can't fix the application to not cause the warning condition,
and the warning condition is otherwise not causing me other
side-effects, then it is reasonable to conclude that the warning is not
as serious as is made out.
Maybe the warning is serious in other circumstances and yes, should be
fixed in all cases. Once reported upstream, the warning serves the user
little: it might as well be turned off to give the user some peace.
My bug is that the library lacks that little switch. I know I have some
buggy applications, but unless I'm trying to debug a GTK+ application, I
needn't worry about it unless the application misbehaves in other ways.
If GTK+ shuts up about it, it is harder for someone to point the finger. :-)
Stuart Longland (aka Redhatter, VK4MSL)
I haven't lost my mind...
...it's backed up on a tape somewhere.
gtk-list mailing list