GNOME Bugzilla – Bug 675819
document our intention with gtk_init() arguments
Last modified: 2016-05-16 12:48:35 UTC
After talking with some people I have found that there is a substantial amount of confusion over the fact that gtk_init() takes the commandline arguments from main() but GtkApplication doesn't wire them through. At some point we decided that libraries should use environment variables for behaviour customisation and commandline arguments should be reserved to applications. There was even talk about changing the gtk_init() to take no arguments, but it was too late in the cycle to do that. In any case, we've never made any formal communication of our intentions here, so we should determine precisely what they are and then document them. Perhaps we should also come up with a concrete plan that GTK4 will have a gtk_init() that takes no arguments (or perhaps no gtk_init() at all).
Phasing out commandline args is pretty much universally agreed to, I think. The devel is in the details - how do we get there ?
One major problematic issue with environment variables is the way they propagate to child processes too. In some cases, that's what you want, in others, it may not be. This matters because in e.g. some cases, applications can spawn other applications. Imagine an application which set GIO_USE_VFS=local (see e.g. bug 665092 ) - it'd break any other application it might run via g_app_info_launch(). The most important thing is for libraries to provide API that affect only the current process, since we know for other reasons the traps involved in calling setenv() after you've started. For developers, we might investigate a mode where the user controls inheritance of GLib environment variables. For example: $ env G_ENV_ONLY=G_SLICE=always-malloc myprog $ env G_ENV=DISPLAY=:10,G_SLICE=always-malloc myprog I'm not a fan at all of command line arguments generated by libraries.
Here is the list of options we are talking about: GTK: --gtk-module --g-fatal-warnings --gtk-debug --gtk-no-debug GDK: --class --name --display --gdk-debug --gdk-no-debug
And, to wrap this up: --gtk-module is covered by GTK_MODULES and a setting --g-fatal-warnings is covered by G_DEBUG=fatal-warnings --gtk-debug is covered by GTK_DEBUG --gtk-no-debug is pretty useless GDK: --class --name --display covered by DISPLAY --gdk-debug covered by GDK_DEBUG --gdk-no-debug is useless
Created attachment 276426 [details] [review] Deprecate passing arguments to gtk_init() Issue a warning when G_ENABLE_DIAGNOSTIC=1 is set.
Created attachment 276427 [details] [review] Deprecate some commandline parsing API gtk_init_with_args and gtk_get_option_group are not useful without commandline arguments, so deprecated them together with commandline args.
I sort of gave up on this: that's why we now have g_application_add_option_group: it is intended that this be used with gtk_get_option_group().
I dunno - giving up on not having commandline handling in GApplication is not the same as giving up on handling commandline options in the toolkit.
I'm saying that I gave up on not having _toolkit_ commandline handling in GApplication, because app authors weren't happy about losing it. Quite a lot of people were just wiring it back in again anyway, via local_command_line(). Colin's concerns about environment variable propagation are also valid and I've never been able to find a good counterargument for that. As such, I think WONTFIX might be appropriate at this point.
(In reply to comment #9) > Quite a lot > of people were just wiring it back in again anyway, via local_command_line(). why? to what end?
the counter argument to environment inheritance is dbus activation
(In reply to comment #10) > why? to what end? I can't answer this, but before we added GOptionGroup support to GApplication there was quite a lot of this sort of thing around: https://git.gnome.org/browse/gedit/tree/gedit/gedit-app.c?h=gnome-3-10#n697 If I had to guess, it's because a lot of the GTK options are still fairly useful...
(In reply to comment #12) > (In reply to comment #10) > > > why? to what end? > > I can't answer this, but before we added GOptionGroup support to GApplication > there was quite a lot of this sort of thing around: > > https://git.gnome.org/browse/gedit/tree/gedit/gedit-app.c?h=gnome-3-10#n697 > > If I had to guess, it's because a lot of the GTK options are still fairly > useful... quantifying "a lot": * GDK * --class * --display * --name * GTK * --gtk-modules * --g-fatal-warnings the rest are conditionally compiled with the debug options, so applications cannot rely on them. the GDK options are X11-isms, and are not really portable to other platforms or to other windowing systems; plus, they have to replicated in the environment (say for SSH sessions, if they even still work because of DBus), because otherwise other applications not using GTK will not work. specifying GTK modules on the command line is a bit weird, and pretty much something that is not something that applications should change; it looks like a debug-only option, or an "unbreak my application by removing this broken module" switch. passing arguments defined by the application is perfectly fine, but tool kit command line arguments are really something that should just not exist.
the only one that I see some value in propagating is --g-fatal-warnings, which is a developer-only switch; I honestly don't know what would happen if you launched an app without it, then launched a second instance with it, tho; the remote instance would suddenly crash? but then, then remote instance was not launched under a debugging tool, so what would be the point of forcing a crash?
This bug is sort of a zombie, I think. With GApplication using GOptionContext and the gtk GOptionGroup being automatically added in cases of GtkApplication this is no longer anywhere as confusing as it was before. I'd say that the only thing left to do here is to mention in the docs for gtk_init() that you don't need to call it if you are using GtkApplication -- and that note is already there. This bug was fixed a long time ago.