How do I correctly handle the open signal for opening files via CLI or D-Bus?

I’m trying to make a simple GNOME app in Builder using the GNOME app template (that uses Adwaita). I’m trying to get it to handle the open signal to use it to open files from “Open With” and the CLI, but it seems it’s not receiving the files properly. The only thing I did other than adding a label to the titlebar and changing the text view content is this:

In main.c:

app = testing_application_new ("com.example.Testing", G_APPLICATION_HANDLES_OPEN);

  g_signal_connect (app, "open", G_CALLBACK (app_open), NULL);

In testing-application.h:

void app_open (GApplication  *application,
                GFile        **files,
                gint           n_files,
                const gchar   *hint);

In testing-application.c:

void app_open (GApplication  *application,
                GFile        **files,
                gint           n_files,
                const gchar   *hint)
	gint i;
	GSList *file_list = NULL;

	for (i = 0; i < n_files; i++)
		file_list = g_slist_prepend (file_list, files[i]);
    gchar* name = g_filename_display_basename(files[i]);
    printf("Name: %s\n", name);

	file_list = g_slist_reverse (file_list);

I added a valid file in Build Preferences->Run Options.

The output:

Application started at 19:10:27
Name: ���ݏU
Application exited

What am I doing wrong? How can I get it to receive a valid file from the CLI that I can then process, without resorting to using the activate signal and handling the file with standard C functions?

Here’s a little question for you, what type is files?

I wrote a long comment going over the documentation but then realized that I confused g_file_get_basename and g_filename_display_basename.

I would like to suggest that if the documentation had proper links between keywords and their pages I would have been less likely to make such a mistake.

Now that I corrected this error, perhaps you could be so kind as to answer another question: Why is it that when passing a file in the Run Options the application exits immediately after printing to CLI without displaying any window?

Yeah, that’s a bug in the documentation generator: it seems it does not understand that the type of the array in the signal is GFile, and thus it’s missing the correct annotation.

You need to create a window in order to keep the application’s instance alive:

Currently, GtkApplication handles GTK initialization, application uniqueness, session management, provides some basic scriptability and desktop shell integration by exporting actions and menus and manages a list of toplevel windows whose life-cycle is automatically tied to the life-cycle of your application.

as the documentation says.

If you don’t create a top level window and add it to the application instance, the application will instantly terminate; the same will happen when you close all the windows associated to the application.

Thank you for your reply.

The next line in main after

g_signal_connect (app, "open", G_CALLBACK (app_open), NULL);


ret = g_application_run (G_APPLICATION (app), argc, argv);

If I don’t emit the signal (don’t pass a file), then the app window opens. If I do emit the signal then it doesn’t open and I need to open it manually? That’s how it’s supposed to behave?

So the solution is to add:


to my app_open function?

GApplication::open is used when there are files to open; otherwise, you get GApplication::activate. So you will need to create the application window in both places.

Typically, if your application handles the open signal, you will create the application window and pass the file(s) you got from the command line or the DBus activation.

I figured it out. Thank you very much for your help.

Do you happen to know where I can go for help regarding the libflatpak documentation? I want my app to interact with libflatpak, but when I go to the documentation, it’s hard to find the entry point for how I get objects that I need to pass as parameters. One of the things that makes it hard to find what I need is that the lists of function signatures don’t include the parameters, only function name and return type, so I can’t easily do a visual scan to find potential matches for what I need. I believe the GTK documentation has the same shortcoming.