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