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
signature.asc
Description: PGP signature
