GNOME Bugzilla – Bug 743933
gapplication: add --app-id command line option
Last modified: 2016-11-28 15:03:48 UTC
Allowing users to override an application's id is pretty hard to achieve with GApplication right now (need to subclass and override local_command_line). Applications that might want to use this are web Browsers (for web apps) and terminals (for application-like profiles). Applications need to opt in to it. Most apps would break in weird ways if we allowed overriding their app id.
Created attachment 296019 [details] [review] gapplication: add --app-id command line option Some applications support running in a mode where they present themselves as a different application to the user (for example web browsers or terminals). To facilitate this, add an option --app-id which allows users to override an application's id from desktop files or similar. Applications need to opt-in to this by setting the G_APPLICATION_APP_ID flag.
Just realized that this patch is faulty: it calls g_set_prgname() _before_ parsing the arguments. We cannot call it after either, because g_option_context_parse() calls g_set_prgname() itself. Maybe we could add a mode to GOptionConext that stops it from doing so?
Created attachment 296083 [details] [review] gapplication: add --app-id command line option Whitespace fix.
Created attachment 296084 [details] [review] gapplication: never set the prgname to the app id Stop setting prgname to the application's id. This was weird anyway and fixes the problem with g_option_context_parse(). It still makes sense to set the WM_CLASS of application windows to the app's id, but we can do that in GtkApplication.
Created attachment 296085 [details] [review] gtkapplication: set wm_class to application id
This is interesting for xdg-app. In some cases you want to run a parallel installable version of a package with both visible in the shell. For instance say "Gimp" and "Gimp unstable devel". These could not have the same dbus/desktop file name, because things would conflict. With this it would be easy to create such a package without having to patch any code (but the desktop file).
Review of attachment 296083 [details] [review]: Thanks for the patch. I don't like the name of the flag, but I'm not sure I have a better suggestion at the moment. I think we should add at the same time an option to disable the single-instance behaviour of the application (and under control of the same flag). I was also surprised to see that this patch did not move handling of --gapplication-service to being done in the same way. I think you had finally convinced me that this was a good idea, but we were only hanging on what got shown in --help (which is not the most important issue, admittedly).
(In reply to Ryan Lortie (desrt) from comment #7) > I don't like the name of the flag, but I'm not sure I have a better > suggestion at the moment. Agreed. > I think we should add at the same time an option to disable the > single-instance behaviour of the application (and under control of the same > flag). I don't understand. How would it be an option if it is under control of the same flag? Also, I see the two as orthogonal. If you have a desktop file for a different app id, you might want to run that as single-instance or ... not. > I was also surprised to see that this patch did not move handling of > --gapplication-service to being done in the same way. I think you had > finally convinced me that this was a good idea, but we were only hanging on > what got shown in --help (which is not the most important issue, admittedly). Ah right. Didn't attach it here because it doesn't really belong to the same bug.
Review of attachment 296085 [details] [review]: ::: gtk/gtkapplication.c @@ +605,3 @@ gtk_init (0, 0); + gdk_set_program_class (g_application_get_application_id (g_application)); This might be too broad of a stroke. I think gnome-shell currently relies on this being equal to the desktop ID, which is usually the same as the prgname for non-appid-named desktop files. It might make more sense to only do this for service mode, just as the prgname patch used to do (before it broke).
Review of attachment 296084 [details] [review]: This is not quite as simple as you let on here, and there is a potential bug in GOptionContext if it's setting this unconditionally (despite a warning on g_set_prgname() that it ought not to do that). All the same, the main argument holds up: this code has done nothing for half a year and nobody missed it.
(In reply to Lars Uebernickel from comment #8) > > I think we should add at the same time an option to disable the > > single-instance behaviour of the application (and under control of the same > > flag). > > I don't understand. How would it be an option if it is under control of the > same flag? Also, I see the two as orthogonal. If you have a desktop file for > a different app id, you might want to run that as single-instance or ... not. I meant the same GApplicationFlag would control the addition of both --gapplication-app-id and --gapplication-noregister (or whatever we call it). The main logic here is that fi your app is safe to run as multiple copies of itself under different appids then it's probably also safe to run as multiple copies of itself straight-up. Maybe that's not true in all cases, though... > > I was also surprised to see that this patch did not move handling of > > --gapplication-service to being done in the same way. I think you had > > finally convinced me that this was a good idea, but we were only hanging on > > what got shown in --help (which is not the most important issue, admittedly). I'd have considered it to be a separate patch as a lead up to this one.
(In reply to Ryan Lortie (desrt) from comment #9) > Review of attachment 296085 [details] [review] [review]: > > ::: gtk/gtkapplication.c > @@ +605,3 @@ > gtk_init (0, 0); > > + gdk_set_program_class (g_application_get_application_id (g_application)); > > This might be too broad of a stroke. I think gnome-shell currently relies > on this being equal to the desktop ID, which is usually the same as the > prgname for non-appid-named desktop files. gnome-shell looks at both the instance and the class name to lookup desktop files (shell-window-tracker.c:193). I think it's fine to always call this, not only in service mode.
(In reply to Ryan Lortie (desrt) from comment #11) > (In reply to Lars Uebernickel from comment #8) > > I don't understand. How would it be an option if it is under control of the > > same flag? Also, I see the two as orthogonal. If you have a desktop file for > > a different app id, you might want to run that as single-instance or ... not. > > I meant the same GApplicationFlag would control the addition of both > --gapplication-app-id and --gapplication-noregister (or whatever we call it). Ah sorry. I misunderstood. > The main logic here is that fi your app is safe to run as multiple copies of > itself under different appids then it's probably also safe to run as > multiple copies of itself straight-up. > > Maybe that's not true in all cases, though... I wouldn't count on this being true. Apps can already disable the single-instance behavior with G_APPLICATION_NON_UNIQUE, no? Why would we put both of these things under the same flag? > > > I was also surprised to see that this patch did not move handling of > > > --gapplication-service to being done in the same way. I think you had > > > finally convinced me that this was a good idea, but we were only hanging on > > > what got shown in --help (which is not the most important issue, admittedly). > > I'd have considered it to be a separate patch as a lead up to this one. It's a patch on bug #710965.
So, I have a new usecase for this. With xdg-app, all exported items from an app bundle, such as dbus service files, icon names, desktop files, etc have to be prefixed with the app id. Typically this app id is the same reverse-dns type of thing that dbus uses. So, the app id for gedit would be org.gnome.gedit, and the upstream would build an app with that name. However, if a third party build a version of gedit, like a distribution could, it should not use the org.gnome.gedit name, as that would trample over the namespace of upstream. So, the distro would change the name of the desktop file and service file. This currently requires a rebuild/patch of the app to grab the right dbus name. Ideally we should be able to use the work from this patch to change the dbus name via a tweak to exec lines in the desktop file and service file.
Ping on this? Its super useful when creating e.g. nightly build app bundles.
Created attachment 321552 [details] [review] gapplication: add a way to override the app-id Some applications support running in a mode where they present themselves as a different application to the user (for example web browsers or terminals). To facilitate this, add an option --gapplication-app-id which allows users to override an application's id from desktop files or similar. Applications need to opt-in to this by setting the G_APPLICATION_SETTABLE_APP_ID flag. https://bugzilla.gnome.org/show_bug.cgi?id=743933 cosmetics
Created attachment 321556 [details] [review] gapplication: add a way to override the app-id Some applications support running in a mode where they present themselves as a different application to the user (for example web browsers or terminals). To facilitate this, add an option --gapplication-app-id which allows users to override an application's id from desktop files or similar. Applications need to opt-in to this by setting the G_APPLICATION_CAN_OVERRIDE_APP_ID flag.
Alex, do you need this to be opt-out, rather than opt-in ? Otherwise, you'll still need to patch all the applications to opt in to this...
Attachment 321556 [details] pushed as b32f8ba - gapplication: add a way to override the app-id
(In reply to Matthias Clasen from comment #18) > Alex, do you need this to be opt-out, rather than opt-in ? Otherwise, you'll > still need to patch all the applications to opt in to this... The problem I see with making it an opt-out is that applications may rely on having a certain application identifier, or use the identifier for other things (e.g. GSettings, or locations on disk), and therefore the application needs anyway to be aware that the application identifier might change (and work accordingly). I did such a thing recently, and I don't see a way in which allowing overriding the application identifier by default can work without horribly breaking many existing applications