Created attachment 174604 [details] [review]
initial proposal

this adds g_application_set_option_context() API to GApplication.

It should be used in main(), right after the creation of the GApplication object. If the app has a context, the default local_command_line handler tries to parse the arguments.

I've tried it here while migrating vinagre to the new GApplication API and it worked fine.

It still needs polishing, like documentation and perhaps a property.

Comments?

+1 to the general idea

i'll try to review the patch in the next week

Created attachment 174611 [details]
draft of a simple use case

your "simple use case" is a bit broken -- it should use the 'startup' and 'activate' signals to accomplish the logic of what you're trying to deal with in 'command-line'.  also: don't use HANDLE_COMMAND_LINE flag.

it is also possible that there are errors since the commandline message is just coming randomly over the bus...

also: the way in which you use the option context (with the global variables) is a bit distressing.  that clearly won't map very nicely into remote activations...

This is really necessary. We need a way to make GApplication to be easy to use together with GOptionContext.

eog's use case has a mix of requeriments. We need to handle:

1) --version (which only runs locally and then exits)
2) --new-instance, which will not connect to the remote instance and create a new one instead.
3) --help *must* run locally and show *all* the options.
4) all the other options must be passed to the remote instance.

Right now I can't find a simple way to do this without adding a lot of crap to the code.

For one, if I parse GOptionContext in main(), before running g_application_run(), then all the arguments are consumed and the only way I can pass the remote parameters is by somehow manually doing it through the bus, which is definitely not friendly to do.

Another option is to create locally a GOptionContext with the local options only (--version and --new-instance) and then remotely a GOptionContext with the other options. But the problem with that is that --help (which runs locally) will only display these and not the remote ones, unless I do it manually, which I don't want to.

I don't think this is an exceptionally strange use case, and somehow we need to support it.

*** Bug 624280 has been marked as a duplicate of this bug. ***

Has there been any progress on this? It's still a rather obvious problem when people start using GtkApplication.

(In reply to comment #6)
> Another option is to create locally a GOptionContext with the local options
> only (--version and --new-instance) and then remotely a GOptionContext with the
> other options. But the problem with that is that --help (which runs locally)
> will only display these and not the remote ones, unless I do it manually, which I don't want to.

And there will be no way to provide stdout/stderr feedback about those options, such as complaining about invalid combinations of options or invalid values.

By the way, using G_APPLICATION_NON_UNIQUE seems to avoid this problem, because the GApplication::command_line signal handler then runs in the local instance. However, I am still finding out what else I lose by using that flag.

This is probably WONTFIX. See bug 699893 for current thinking about minimal cmdline support in GApplication