Creating a modal dialog in a Files (menu) plugin

Hi all,

I develop a plugin called Eiciel for GNOME Files and I have recently updated it for the forthcoming Files 43 and GTK4. This plugin allows editing metadata of the files (ACLs and extended attributes). Aside from the plugin, the package includes a graphical tool that provides similar functionality independent of GNOME Files.

In Files <43 it was possible to insert arbitrary widgets inside a new tab of the Properties dialog of a file. This has changed in Files 43 and this dialog can be extended (via property providers) to display attributes of files (current examples of this are image and audio/video properties) but not edit them. I understand Files’ developers decision and I’m not questioning it at all.

In order to allow editing files easily from Files itself, I added a menu provider that invokes the graphical tool to edit the file. This works well and I’m OK with this option. One downside (but maybe that is me creating a problem out of nowhere!) is that the window of the graphical tool will not necessarily appear over the Files’ window. For instance, if there is enough screen state it will appear next to File’s window (which I find confusing).

That said, I was tinkering around and I found I can obtain the GApplication (using g_application_get_default) from the module itself, downcast it to GtkApplication so I can obtain the active GtkWindow (using gtk_application_get_active_window). If all this works fine then I can insert a GtkDialog when running the activate event of the menu item. A test using a modal GtkMessageDialog seems to work. I could extend this idea to show a custom modal dialog with the widgets of the editor (as it happened in Files<43).

However, I feel that I would be abusing GNOME Files’ infrastructure. As I said I’m happy with the current approach invoking the graphical tool but I was investigating if a more integrated (to Files, that is) option is reasonable.


Thanks a lot.

Hi Roger, thanks for talking to us!

The feedback of extension developers on the new API is very useful. I’m more than available to help.

That’s a good question. When removing the window parameter, my hope was to discourage extensions from creating dialogs.

I think extensions should be independent from GTK version, to avoid having all of them breaking when we port to a new major version of GTK. And this can only be done if extensions don’t use GTK at all. This means nautilus extensions shouldn’t create any kind of UI themselves, but always pass models through the API and let the application translate that into GTK widgets.

For extensions which added complex UI, my suggestion is to turn them into applications of their own right. I see you’ve already done this with Eiciel, which I applaud.

So, answering your main question: in my opinion, it shouldn’t look like a Files dialog. It’s a separate application: Eiciel. Let the the identity of your application shine!

Hi António,

Thanks for the prompt answer. You confirmed my hunch that I shouldn’t creating any UI inside nautilus. As I said I’m happy with invoking an external tool.

I’d like to thank you, and the team involved, for the good work you have been doing porting Files to GTK4, version 43 looks fantastic.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.