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. >>> 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] _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list
