After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 743933 - gapplication: add --app-id command line option
gapplication: add --app-id command line option
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: gapplication
unspecified
Other All
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2015-02-03 13:36 UTC by Lars Karlitski
Modified: 2016-11-28 15:03 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gapplication: add --app-id command line option (4.64 KB, patch)
2015-02-03 13:36 UTC, Lars Karlitski
none Details | Review
gapplication: add --app-id command line option (4.65 KB, patch)
2015-02-04 10:38 UTC, Lars Karlitski
reviewed Details | Review
gapplication: never set the prgname to the app id (2.53 KB, patch)
2015-02-04 10:40 UTC, Lars Karlitski
committed Details | Review
gtkapplication: set wm_class to application id (1.43 KB, patch)
2015-02-04 10:42 UTC, Lars Karlitski
reviewed Details | Review
gapplication: add a way to override the app-id (4.71 KB, patch)
2016-02-17 21:25 UTC, Matthias Clasen
none Details | Review
gapplication: add a way to override the app-id (4.73 KB, patch)
2016-02-18 01:35 UTC, Matthias Clasen
committed Details | Review

Description Lars Karlitski 2015-02-03 13:36:38 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.
Comment 1 Lars Karlitski 2015-02-03 13:36:41 UTC
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.
Comment 2 Lars Karlitski 2015-02-03 17:04:16 UTC
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?
Comment 3 Lars Karlitski 2015-02-04 10:38:10 UTC
Created attachment 296083 [details] [review]
gapplication: add --app-id command line option

Whitespace fix.
Comment 4 Lars Karlitski 2015-02-04 10:40:00 UTC
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.
Comment 5 Lars Karlitski 2015-02-04 10:42:46 UTC
Created attachment 296085 [details] [review]
gtkapplication: set wm_class to application id
Comment 6 Alexander Larsson 2015-02-10 20:00:58 UTC
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).
Comment 7 Allison Karlitskaya (desrt) 2015-02-11 01:38:15 UTC
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).
Comment 8 Lars Karlitski 2015-02-12 00:01:45 UTC
(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.
Comment 9 Allison Karlitskaya (desrt) 2015-02-17 17:09:33 UTC
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).
Comment 10 Allison Karlitskaya (desrt) 2015-02-17 17:14:24 UTC
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.
Comment 11 Allison Karlitskaya (desrt) 2015-02-17 17:18:26 UTC
(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.
Comment 12 Lars Karlitski 2015-02-17 18:12:34 UTC
(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.
Comment 13 Lars Karlitski 2015-02-17 18:18:35 UTC
(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.
Comment 14 Alexander Larsson 2015-05-13 11:32:24 UTC
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.
Comment 15 Alexander Larsson 2016-02-09 11:06:47 UTC
Ping on this?
Its super useful when creating e.g. nightly build app bundles.
Comment 16 Matthias Clasen 2016-02-17 21:25:44 UTC
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
Comment 17 Matthias Clasen 2016-02-18 01:35:02 UTC
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.
Comment 18 Matthias Clasen 2016-02-18 01:44:02 UTC
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...
Comment 19 Matthias Clasen 2016-02-18 13:20:59 UTC
Attachment 321556 [details] pushed as b32f8ba - gapplication: add a way to override the app-id
Comment 20 Adrian Perez 2016-11-28 15:03:48 UTC
(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