GNOME Bugzilla – Bug 710965
GApplication: add --gapplication-service switch
Last modified: 2018-05-24 15:46:50 UTC
This will allow apps to take advantage of the glory of DBusActivatable without the pain.
Created attachment 258223 [details] [review] GApplication: add --gapplication-service switch Add a --gapplication-service switch to the default implementation of local_command_line. This name is unlikely to clash with any option used by an existing application. When a normal application (neither service nor launcher) is launched with exactly this one argument, G_APPLICATION_IS_SERVICE will be set. The idea is that people will write their D-Bus service file with --gapplication-service on the Exec line. This provides a nice compromise for people who want the benefits of DBusActivatable applications but without losing the ability to easily run them directly (under the debugger or inside jhbuild, etc.)
That seems a little hacky, not a fan. You shot down my patch to handle --version in this way. I can see this leading to badly implemented services that open windows even when launched as a service.
Can you elaborate?
After I turned gnome-software into a service, I had to do this: https://git.gnome.org/browse/gnome-software/commit/?id=84666d65017367a2d935d65dc69ca4d16d523827
After writing some tests for gnome-software, I'm coming around to the idea that it is very nice to have a single binary for both purposes.
Review of attachment 258223 [details] [review]: This needs documententation, probably in the same place where we discuss commandline handling and service-vs-launcher. Would also be great to have a testcase for this. ::: gio/gapplication.c @@ +489,3 @@ + return TRUE; + } + } This means that fake-sunset --extra-glow --gapplication-service will not work, and will likely make fake-sunset complain about an unknown option later. Is that intended ? fake-sunset --gapplication-service --extra-glow will start a sunset service, but is still likely to complain about an unknown option. Should you strip the processed option from the arguments ? Or is the idea that --gapplication-service can only be used as the sole option ? In that case, you should perhaps warn if there are other options, not silently ignore them ?
(In reply to comment #6) > Or is the > idea that --gapplication-service can only be used as the sole option ? In that > case, you should perhaps warn if there are other options, not silently ignore > them ? This is precisely the idea. This should be used from only one place: the service file with exactly the one argument. Adding a warning if other arguments are there might be a nice idea, indeed.
Created attachment 265877 [details] [review] GApplication: add --gapplication-service switch Add a --gapplication-service switch to the default implementation of local_command_line. This name is unlikely to clash with any option used by an existing application. When a normal application (neither service nor launcher) is launched with exactly this one argument, G_APPLICATION_IS_SERVICE will be set. The idea is that people will write their D-Bus service file with --gapplication-service on the Exec line. This provides a nice compromise for people who want the benefits of DBusActivatable applications but without losing the ability to easily run them directly (under the debugger or inside jhbuild, etc.)
May also be interesting to have a proper 'hybrid' mode: - by default, the process is a launcher - if --gapplication-service is given, then it's a service - if --gapplication-local is given then it's neither This means that normal invocations would active the service in the usual way but we could use --gapplication-local to short-circuit that for the case where we want to debug the app or have problems with D-Bus activation (like with jhbuild). I think this is pretty heavy, though, and it would only be useful for processes that care about the life-cycle of processes launched from the commandline. Those applications are in a fine position to add these features to their own local_command_line(). That said, this may be something we care about more going forward, if we start to consider the cgroup separation that we get from D-Bus activation to be important.
Review of attachment 265877 [details] [review]: Ok. Would be good to have a test exercising this.
Comment on attachment 265877 [details] [review] GApplication: add --gapplication-service switch Attachment 265877 [details] pushed as e8b7dd3 - GApplication: add --gapplication-service switch Testing this is going to be pretty difficult...
Created attachment 296020 [details] [review] gapplication: allow --service option --service reads much nicer and I just did the same for --app-id. --gapplication-service will continue to work.
-- 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/770.