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*
responsibility.
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:
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.
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
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.
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
issue to.
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
pitchforks.
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+
team.
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
it disappear.
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
code.
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
accordingly.
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. :-)
Regards,
