I've been working on this during the last couple of days, and there are some things we should consider before spending our resources on this: 1. This adds a source of inconsistency across GTK+ apps, unless GTK+ is patched. At the desktop level, we already face the inconsistency that exists between old apps that still use GTK+ 2 and other apps already using a GTK+ 3.x. Now, even applications using GTK+ 3 can look inconsistent by not using GtkHeaderBar (client-side decorations). The current open/save dialog (GtkFileChooserDialog) is implemented in such a way that each app creates a new instance of the dialog, and then shows it to the user. Just like creating any other child window (e.g. a preferences dialog, etc). Thus if we were to provide a Granite implementation, each app would have to be patched or modified to create a Granite File Chooser instead (see point 2 for more information on this), and apps not using Granite would still show the default GTK+ file chooser. At the moment, the only way to override the open/save dialog accross ALL GTK 3 applications (without patching any application) is by modifying the implementation of GtkFileChooserDialog in GTK+ (without touching the public API). This would require patching the library itself, and modifying some widgets to be more elementary-ish. Of course, it is a ton of work, but not a lot more than the other solutions available. 2. Providing a Granite implementation, in spite of inconsistency across GTK+ 3 apps is possible. Two basic approaches have been considered so far: 2.1 Exposing the File Chooser as a DBus service (suggested by Cameron Norman in comment #6). * This could be implemented in Pantheon Files, so that it provides the file chooser as a DBus service. The good thing about this approach is that the actual implementation would live outside Granite, meaning there would be no need to move widget implementations into Granite, which usually implies a lot of rewriting and restructuring (we are speaking about the sidebar, pathbar, and file browser icon and list views). * A wrapper API could be provided in Granite, so that apps don't actually have to deal with DBus (just like we do in ContractorProxy). Some issues with this approach: * The FileChooserDialog is usually required to be modal and block any other interaction until the user either cancels or selects a file. If the implementation is provided by another application, this would involve some window-manager trickery, and there doesn't appear to be a reliable way to steal focus from the main window. Example: https://bugs.launchpad.net/policykit-1-gnome/+bug/433851/comments/4 * There could be visual integration issues. For example, an application that is using the dark theme would have to let the application providing the File Chooser know about it via DBus, so it can use the proper style. * The DBus API would have to be extensive to stay on par with GtkFileChooserDialog. An acceptable replacement would have to provide all the facilities exposed by GtkFileChooser. See https://developer.gnome.org/gtk3/3.12/GtkFileChooser.html * A lot of plumbing is needed in files to implement this in a clean way without duplicating (i.e. not copy-pasting) a ton of code, which is what we're trying to avoid at all costs. Workarounds for these issues are possible, but not desirable, since they add clutter to the DBus API. 2.2 Implementing the File Chooser Dialog in Granite itself. As mentioned above, the main implication is that a lot of code from Pantheon Files would have to be moved (and in some cases, duplicated) into Granite. To avoid duplication of code and maintenance efforts, after doing this Pantheon Files should also use the widgets provided by Granite instead of in-house implementations. The bad thing is that most of those widgets have application policy and logic code within them, and abstracting this away is not easy or trivial. On the positive aspects, this is the less hacky implementation we could provide, although its effect wouldn't be global like patching GTK+. This wouldn't approach doesn't suffer from app integration issues, unlike the the DBus solution. Our apps would still need to be patched to support this new dialog.