Okay, looks like I’m wrong about this.
I had two copies of the code file and while editing one, I was compiling and running the other. So I’m back to NOT having a solve for this.
This should about sum it up, as clear as possible:
else if (application->priv->flags & G_APPLICATION_HANDLES_COMMAND_LINE)
{
g_application_call_command_line (application,
(const gchar **) *arguments,
g_variant_dict_end (options),
exit_status);
}
else
{
if (n_args <= 1)
{
g_application_activate (application);
*exit_status = 0;
}
If you pass G_APPLICATION_HANDLES_COMMAND_LINE in the flags, the command-line args are passed to the primary instance and ::activate is not emitted.
An example again is an something like --hide-window or --do-without-disturbing-user which wouldn’t work if the default were to trigger ::activate and open the window.
So just pass G_APPLICATION_HANDLES_COMMAND_LINE and then call g_application_activate() in your ::command-line handler 
Thanks for that, Andy. I guess what this all comes down to is I was expecting this whole thing to act like a signal/callback system, same as that used in GDK. Mostly I thought that because that’s the way it’s presented.
But this seems like a monumentally complex combination of about five different paradigms that doesn’t adhere to any of them long enough for my poor brain to wrap around it.
I’ve got the onStartup and onShutdown signals firing and that’s as far as I’m going to take it for now.
That is the case 
. These are all fully documented in the API documentation.
In Gdk/Gtk, handlers for signals like ::key-press-event return a boolean, so you can handle the key press and return TRUE. Returning TRUE is just a way of saying “I’m taking ownership of this event”.
Signal handlers for the two command line signals in GApplication return integers because they’re triggered by command-line invocations, usually from a terminal shell. This means they need an exit code, just like any other CLI command. Your callback returns that exit code.
I reread this and realized this illustrates a point I’d like to make…
When the command-line signal is hooked up, the activate signal no longer works as expected. By calling activate(), I’m circumventing the entire signal/callback system. In fact, I could make a call to activate() without hooking up any signals just as I can handle command line arguments without it.
So my point is: why bother with the GIO signal/callback system at all? From what I’ve read, it adds needless complexity without any added benefit.
Inquiring minds (well, at least this one inquiring mind) wants to know.
I’m not seeing any mention of why the activate signal no longer fires when the command-line signal is hooked up. Can you point it out, please?
I think you’re just overthinking it .
The expected behaviour when handling command-line arguments is to not emit the ::activate signal, which gives you the option. That’s not a mistake or oversight, it’s by design.
I think you’re just assuming your use-case of “open the main window no matter what entry point I use” is the only one any one would want. For one thing, if that were the case, you could never have command-line options like --new-window without triggering your ::activate handler.
I suspect you’re not really understanding all that the GApplication class does and are looking at it through the lens of a singular use-case. If that’s the case, maybe it just does more than you need it to?
In g_application_run(), which describes the run-time order and situations in which signals are fired.
Yeah, probably. I do that when I’m going around in circles. 
This system incorporates so many things all under one umbrella. It’s hard to keep it all in my head at once.
Seems odd to my way of thinking… although, I do admit I can’t think of another mechanism that would do the job.
It’s more like… expecting a different mechanism by which the window is either opened or not opened in a scenario where the command-line signal is handled… something a little more (I don’t know) signalish.
That, my friend, is the biggest understatement in this thread! 
Thanks. I’ll give it a read.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.