GNOME Bugzilla – Bug 644309
Program name is not set when using GtkApplication
Last modified: 2011-04-01 16:43:28 UTC
I'm writing an application that uses GtkApplication. I call gtk_init (NULL, NULL) as suggested as best practice in bug 639925 comment 3 like this GApplication * gdu_application_new (void) { gtk_init (NULL, NULL); return G_APPLICATION (g_object_new (GDU_TYPE_APPLICATION, "application-id", "org.gnome.DiskUtility", "flags", G_APPLICATION_FLAGS_NONE, NULL)); } but this causes gtk_init() to call g_set_prgname() to be called with "<unknown>" (or not called at all, I don't know). The result is that - the shell cannot match the app to the desktop file (shows <unknown> and a generic icon) - g_debug() et. al. shown <unknown> in the debug output
Hmm, good point. The obvious workaround in your code is to call g_set_prgname() yourself, but we should figure out a way to avoid the need for that.
Actually, g_application_run _is_ trying to work around that already: if (g_get_prgname () == NULL && argc > 0) { gchar *prgname; prgname = g_path_get_basename (argv[0]); g_set_prgname (prgname); g_free (prgname); } Are you not calling g_application_run or is that not working ?
(In reply to comment #2) > Actually, g_application_run _is_ trying to work around that already: > > if (g_get_prgname () == NULL && argc > 0) > { > gchar *prgname; > > prgname = g_path_get_basename (argv[0]); > g_set_prgname (prgname); > g_free (prgname); > } > > > Are you not calling g_application_run or is that not working ? I am, see http://git.gnome.org/browse/gnome-disk-utility/tree/src/palimpsest/main.c?h=udisks2-port#n28 but I guess it's too late by then as it's set to "<unknown>" by g_option_context_parse() http://git.gnome.org/browse/glib/tree/glib/goption.c?id=2.28.3#n1695 which is called by gtk_init() already... It seems broken that g_option_context_parse() sets the program name to "<unknown>"....
Created attachment 184183 [details] [review] goption: [linux] Look in /proc/self/cmdline for argv0 if not specified We really shouldn't use <unknown> when we can perfectly easily get argv0 out of /proc. This avoids people having to pass argv down into gtk_init/g_option_context_parse etc., which is important because GTK+ uses it to initialize the WM_CLASS, which in turn GNOME Shell consumes for application tracking.
Review of attachment 184183 [details] [review]: Looks good to me; I appreciate that there's a test case. We should commit this to both master and glib-2-28
Uhm, thanks for providing a patch but the fix seems a bit baroque to me. I mean, the problem here isn't that I'm _not_ providing argv/argc - as you can see in comment 3, this information is provided to GApplication just fine. Instead, the problem is that the library function g_option_context_parse() is second-guessing my application and setting the program name to "<unknown>" if not set already. And this is what causing GApplication to _not_ set the name from the provided argv/argc. I think a better fix is to stop making g_option_context_parse() call g_set_prgname() at all. Then things will start working and not only on Linux. I don't think this is an ABI break either - just make sure all callers of g_get_prgname() can cope with NULL being returned. This is the right fix because a library function g_option_context_parse() that shouldn't really modify process-wide state like it's doing. And setting it to "<unknown>" seems pretty futile in either case since it fools legitimate users (like GApplication) to believe that the prgname is set to something meaningful (and thus fooling GApplication into not setting it). And it's not like users of prgname cannot substitute NULL for "<unknown>" themselves. (Ideally we'd nuke gtk_init, g_type_init functions completely in gtk4 but that's another story.)
(In reply to comment #6) > I think a better fix is to stop making g_option_context_parse() call > g_set_prgname() at all. We can't; it's in the docs, and there are things relying on this: /** * g_option_context_parse: ... * Parses the command line arguments, recognizing options * which have been added to @context. A side-effect of * calling this function is that g_set_prgname() will be * called.
(In reply to comment #7) > (In reply to comment #6) > > > I think a better fix is to stop making g_option_context_parse() call > > g_set_prgname() at all. > > We can't; it's in the docs, and there are things relying on this: > > /** > * g_option_context_parse: > ... > * Parses the command line arguments, recognizing options > * which have been added to @context. A side-effect of > * calling this function is that g_set_prgname() will be > * called. Hmm, OK. Another idea I had was to avoid calling g_option_context_parse() if the user calls gtk_init(NULL, NULL). But then something else will probably break. Should probably just commit your patch then. Thanks for looking into this.
For what I want, the docs don't imply that prgname is set even if argv is NULL and until recently I don't think it was useful to do this in the first place... Perfectionism left aside, the fix only addresses Linux. Using GCC's global argv is probably a better idea to make it possible to have a working desktop on any system.
(In reply to comment #9) > For what I want, the docs don't imply that prgname is set even if argv is NULL > and until recently I don't think it was useful to do this in the first place... > > Perfectionism left aside, the fix only addresses Linux. Using GCC's global argv > is probably a better idea to make it possible to have a working desktop on any > system. What is gcc's global argv?
Hrm, sorry, I had been thinking of char* program_invocation_name but the man page tells me it's glibc-specific afterall. However I found that /proc/<pid>/psinfo exists on Solaris. Also GetModuleFileNameW and _NSGetExecutablePath would work for Win32 and OSX, so it looks like it shouldn't be hard to make this work on most systems. It's probably a good idea to go for separate patches for those.
Attachment 184183 [details] pushed as 14bb138 - goption: [linux] Look in /proc/self/cmdline for argv0 if not specified