GNOME Bugzilla – Bug 790857
W32: no way to see std output of non-console programs
Last modified: 2018-05-24 19:54:57 UTC
GTK4 uses meson, which links all GUI apps with -mwindows by default, which makes them run without attaching to a console and without having any std streams. All g_log*() functions invoke the default std stream writer, which fails, because std streams are absent. Thus the program has no visible output, which greatly impedes the process of debugging it.
Created attachment 364444 [details] [review] W32: add std stream redirection command line options This commit adds two W32-only command line options to GApplication: * --gapplication-win32-alloc-console will create a new console if the process has no console by itself This option is for GUI apps that are launched from GUI processes, in which case there's no console anywhere near them. * --gapplication-win32-attach-console will reopen a given std stream and tie it to the console (using existing console or parent console) This works with either the other option (to create a console), or if the app is launched from a console process (often the case for developers) With these it's possible to see the output of g_log*() functions when running GTK4 applications.
Is this how Windows developers debug programs? Surely there should be something a little more modern than looking at console output? I’m a little uncomfortable about adding new command line arguments which are essentially just for development and debugging.
Um...what else is there other than looking at console output? I know i haven't been at the forefront of software development for some time, but i really don't see any alternatives. One thing to note about this patch, is that while it works as intended, the console loses color support. So far i haven't found a way to fix that.
(In reply to LRN from comment #3) > Um...what else is there other than looking at console output? I know i > haven't been at the forefront of software development for some time, but i > really don't see any alternatives. Logging to the equivalent of the systemd-journal, for example?
The closest equivalent that i know of would be Windows event log. Which doesn't seem like a very good idea, since Event Viewer application is rather slow and not very well-maintained (for example, it doesn't support HiDPI property). I am unaware of anyone using it for software development purposes anyway. I'm also unsure how well it would receive stuff logged by g_log*() (structured logging might be more compatible, but it's still not as widely-used as g_log*()). Logging into a file (by the way, i have nothing against supporting output redirection into a file instead of a console) and then filtering out its contents would be an option, something like what gstreamer already does (and what it can *potentially* do; i remember seeing a video about a gstreamer log analyzer application that massages the log extensively). But that's not something i can implement with a simple patch. Right now i'd be simply content to be actually able to *see* these critical warnings that GTK throws around all the time. The only reason this is a patch against *glib* (GApplication), and not *gtk* (GtkApplication), is that i haven't found a convenient place in GtkApplication where i could insert these options.
Is it a deliberate decision to leave GTK+ programs that don't use any Application with the same problem? I know we want to encourage people to use an app, but not whether we're at the point of almost forcing that by making some new functionality only work is they are.
Um...i could modify this to also trigger from special environment variables. Wouldn't be the first time environment variables are used to enable debugging functionality, and i think that this is actually the direction GTK+ itself is going (deprecation of --gdk-debug in favour of GDK_DEBUG).
Created attachment 369424 [details] [review] W32: add std stream redirection envvar options This commit adds two W32-only environmental variable checks: * G_WIN32_ALLOC_CONSOLE, if set to 1, will force glib to create a new console if the process has no console by itself. This option is for GUI apps that are launched from GUI processes, in which case there's no console anywhere near them. * G_WIN32_ATTACH_CONSOLE, if set to a comma-separated list of standard stream names (stdint, stdout, stderr), will reopen a given std stream and tie it to the console (using existing console or parent console). This works either with the other option (to create a console), or if the app is launched from a console process (often the case for developers). The redirection is done with freopen(), dup() and dup2(). If everything goes well, C file descriptors 0, 1 or 2 will be bound to stdin, stdout and stderr respectively (only for streams listed in the envrionmental variable), and so will be stdio streams by the same names. With these it's possible to see the output of g_log*() functions when running GTK4 applications, which are linked as GUI applications, and thus do not get a console by default. v2: * Uses envvars instead of commandline arguments * Accordingly, initialized in glib instead of gio * A more elaborate process of substitution, but with better results (for example, colors now work in redirected console), also with more error checking
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/1304.