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