On 2019-08-13 at 06:12:30, Philip Withnall wrote:
> Hi,
> I can’t speak for the Debian project, but as an upstream GLib developer
> I can say such an environment variable would not be welcome upstream.
> Hiding such warnings makes them less likely to be fixed. It’s a way of
> sweeping bugs under the carpet which I don’t want to encourage. Each
> warning emitted by GTK or GLib indicates a non-trivial bug in the code
> which is calling it, which should be fixed.

Unfortunately, it's often impossible to write code which works on
multiple versions of GTK+ without warnings. I took a version of GVim
which worked fine on Debian unstable with GTK+3 but produced copious
warnings on CentOS 7. This makes it difficult for folks who would like
to upgrade one single component on a system without rebuilding the
entire GTK+ stack. In addition, an upgrade of GTK+ can cause previously
working programs to produce errors where they did not before, causing
problems for users.

In addition, Unix programs typically produce output to standard error to
reflect a user-relevant error: something that the user has done wrong or
that prevents the program from functioning in the way the user
requested. These warnings are not user relevant: they reflect a
developer error, not a problem that reflects a user-visible failure.
From the user perspective, everything is functioning as intended, so
output to standard error is not appropriate.

And finally, overwhelmingly, developers take a long time to fix warnings
like this, if they get fixed at all. Perhaps they don't see the use case
of running graphical programs like PDF viewers from the command line.
More likely, they are overwhelmed with other issues and consider this
low priority.

I appreciate that these reflect a defect in the program that should be
fixed, but it isn't fair to force users to either fix these defects for
themselves or deal with terminal junk. As a Git developer, I can tell
you people would be extremely unhappy if libpcre or libcurl produced
errors on their terminals when they ran Git, even if those were bugs in
Git itself. I'm not sure why GLib should be different in this regard.

Ultimately, I think it's most appropriate to let users decide for
themselves if they would like to see non-user-visible issues on their
terminal. I'm not even asking for this to be the default, just an option
users can turn on.
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

Attachment: signature.asc
Description: PGP signature

Reply via email to