Detect when the open/save file dialog is launched


I want to know is there a way to detect when the dialog to open or save a file is launched. I take a look to the GtkFileChooserDialog and the GtkNativeDialog api in GTK but I didn’t know how to do that ?

Is there a way to detect that ?

To avoid XY problems, can you explain what are you actually trying to achieve?

You don’t typically check when a dialog is opened: you want to know when the user has selected a file, or dismissed the dialog.

I’m wondering if we can reproduce this functionality of default folder X. When a file dialog box is open, clicking on an opened window bring the file dialog to the path of this window. I know how to get the current path of nautilus, some terminals. But really don’t know how to hook in the file dialog box and programmatically interact with it. With a dedicated app or a gnome extension ?

I think that the user experience with file dialog boxes in gnome (and other desktop environment) is very poor. It is however a big part of a desktop environment !

That’s not something you can do from the outside of the toolkit.

At most, you should be able to drop a location from the file manager to the file selection dialog, but for that you’d have to modify GTK to allow dropping a text/uri on the path bar.

Feel free to open an issue describing the end result, and linking to this topic.

1 Like

Yes, I need to programmatically change the path of the file dialog.
I’ll post an issue. Thanks for your replies.

IMO, trying to modify the file chooser to do some special behavior in Linux is a futile effort, because there are many different toolkits each with their own file choosers. This has gotten better in recent years with the file chooser portal but still it’s impossible to be consistent on most common distros I have seen. This is unlike MacOS where there has only ever really been one toolkit with one file chooser.

If all that matters is a single app, you can implement a custom file chooser for that. If it’s a single deployment with a pre-defined set of apps that are only using one toolkit (or are all using the portal), you can consider patching the toolkit yourself, or deploying a custom portal implementation. Anything beyond that is not going to work consistently.

1 Like

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