On 2019-08-14 at 07:09:19, Philip Withnall wrote:
> Sorry, I think you’re conflating two different types of programs here.
> Command line applications like git have very different output
> requirements on stderr/stdout from graphical programs. Command line
> programs don’t normally use GTK, so shouldn’t see any of the warnings
> you mention above. I would be very surprised if command line programs
> using GLib (not GTK) emitted different warnings with different versions
> of GLib. If they do, can you please provide me with concrete examples
> and I can advise you about how to eliminate them.

Lots of people run GTK+ programs from the command line. I do this all
the time, and that's why this is an issue. I agree that many people do
not, but those people who do are often heavy terminal users and this
really bites them.

Debian systems also invoke GUI programs from mailcap files and xdg-open,
both of which are frequently used from the command line and command line
tools.

> GTK and GLib are separate libraries.

They are indeed separate libraries, but they are developed as a set and
are highly intertwined. GTK+ programs use the GLib logging functions for
API misuse warning messages. Other libraries that are used with GTK+
also use these logging functions for the same purpose, which
necessitates a change in GLib, or an agreement by GTK+ and the other UI
libraries about how to honor the user's wishes not to receive these
messages.

If there were a simple solution where GTK+ and Clutter and all of the
other libraries just called something like g_report_api_misuse, then
there could be an environment variable or setting just for that, but I
don't believe such a function exists. Since it's currently impossible to
distinguish between GTK+'s warning messages and other messages, a bigger
hammer is required.

If you're willing to add such a function and allow users to suppress or
redirect the output, I'm happy to reassign this bug to GTK+.

> > 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.
> 
> If it’s not on by default, almost all users will never find out about
> it. If your argument is that seeing the warnings is only useful for
> developers, then such an option should be on by default and developers
> would have to explicitly turn it off.

I'm not even requesting that they be disabled by default, although I do
feel that they should be. I'm requesting an environment variable users
can set to disable GLib logging while keeping it on by default.
Alternatively, an environment variable directing GLib logging to a file
would meet my needs, provided it supported character specials.

I'd also be happy with just reporting these errors when developer mode
is turned on during the build, or when -Werror is passed as a flag to
the compiler. These are settings that will be turned on in development,
but will not be enabled for non-development uses.

I'm happy to look for solutions that solve the problem for me and all
the other users that are acceptable to upstream.

> Filing bugs against applications, which point out specific warnings
> which need fixing is, I feel, a much better use of people’s time than
> inventing new and innovative ways to hide those warnings.

You seem to have ignored the part of my previous mail where I stated
that this is not an effective solution to the problem. Some projects
have a much longer release cycle than GLib, meaning even the latest
versions of a release may acquire new warnings as new GLib and GTK+
releases come out.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

Attachment: signature.asc
Description: PGP signature

Reply via email to