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