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.