Is there any way to configure GTK+ programs to use a different file dialog?

Reading ancient articles on the default dialog and seeing no difference to the current version does no bode well for it's improvement in the near future.

I've read this question, but I appear to be one of the few to do so in nearly a year. As I mentioned in a comment on that question:

For archlinux there is a patched version of FF for KDE. It works well if you are in KDE and like the stripped down version of dolphin/whatever it is, but unfortunately doesn't seem to change the file selector if you are not using KDE

As I'm currently in a custom openbox setup, Firefox is back to using the disliked GTK+ dialog. But this solution only works for Firefox, so I'd prefer a way to purge this from my system globally.

  • 1
    If I understand properly, the GTK dialog you have in Openbox doesn't allow you to type any filename or edit location bar? How come? I think it is better to post a screenshot of GTK dialog on your system for other people to look at. – clearkimura Nov 9 '15 at 20:37
  • @clearkimura It does have a location bar, at least most of the time (I haven't been able to determine what causes it omit it every so often..). My real gripe is the extremely long load times that it sometimes requires when opening a large directory (a few hundred image files) – gandalf3 Nov 9 '15 at 21:23
  • 1
    @clearkimura For me navigating to a directory containing ~1000 image files averaging a few 100 kB in a dialog presented by e.g. gimp (GTK 2) causes it to hang for > 20 seconds. Navigating to the same directory in dolphin loads instantly. – gandalf3 Nov 14 '15 at 8:47

This answer is revised from original post that was first answered in late 2015. Contents are now rearranged, some redundant text were removed and relevant text were added.

To begin with

[...] dialog presented by e.g. GIMP (GTK+ 2) causes it to hang for more than 20 seconds. Navigating to the same directory in Dolphin loads instantly.

It is somewhat odd to compare a GTK+ file chooser of an image editor to a Qt file manager (instead of Qt file chooser). Also, these applications don't use the same toolkit; It is apparent that things are handled differently in each other.

It does have a location bar, at least most of the time (I haven't been able to determine what causes it omit it every so often..)

For GTK+ dialog, the location bar will not appear while viewing "Recently Used" in the file chooser. In this view, even Ctrl+L shortcut keys will not work. This is likely the reason why OP had claimed the file chooser sometimes omit the location bar.

Direct answer

KGtk is the hackish way to use KDE dialogs in GTK+ applications. It was first released in mid-2006 and made available on KDE-Apps.org as upstream and also via AUR package.

While this sounds promising, note that this work intention is to give a uniform look for Qt and GTK+ applications. Most likely, it does not address the slow issues which have been debated by the users.

Extended answer 2015.11.23

This extended answer shall address two issues brought up in the question: the disliked GTK+ dialog (usability issue) and dialog hangs for some time (responsiveness issue).

The following are bug reports that mention relevant issues, which are relevant to GTK+.

  • Debian bug report in 2008 complained GTK+ file chooser can be slow to open and its pathname could not be edited in fastest way.

  • Kubuntu meta bug report in 2008 address the GTK+ dialog are being unfamiliar than KDE native dialogs, thus makes difficult to use.

  • SO question in 2009 had complained that browsing directories containing many files over network was very slow using GTK+ file chooser dialog.

  • SO question in 2011 had asked on how to customize GTK+ file chooser, which is impossible in standard dialogs.

  • GTK+ 2.0 bug report in 2012 had problems with uploading files via a Web browser and GTK+ 2 file chooser was slow or hangging for few minutes.

  • GD.SE question in 2014 was posted to ask any way to open a file the fast way in GIMP, because there was no browse button or textbox to edit the path to a file.

Next following are bug reports that mention relevant issues (notably responsiveness issue), which are relevant to KDE.

Regardless of GTK+ dialog or KDE dialog, responsiveness issue is not uncommon and becomes apparent when certain conditions are met (such as non-cached icons, etc.).

Extended answer 2017.02.12

Regarding usability issue, both GTK+ and KDE dialogs have undergone changes during the past years in respective desktop environments.

For GTK+ dialogs, location toolbar is used to be shown by default. However, it is now hidden by default in newer versions of toolkit.

  • GTK+ 2.X allows to edit location, by using Ctrl+L shortcut keys, or "Edit location" UI button.

  • GTK+ 3.X allows to edit location, by using Ctrl+L shortcut keys ("Edit location" UI button might not be shown at all).

For KDE dialogs, unique features are "File name:" text field that is always visible at lower half UI and location path bar that converts into location toolbar when editing.

  • KDE 3.X allows to edit location, by using Ctrl+L or / shortcut keys, or "File name:" text field (location bar cannot be directly edited in some program).

  • KDE 4.X allows to edit location, by using Ctrl+L shortcut keys, or "File name:" text field, or using mouse cursor to click on location path bar.

  • KDE 5.X allows to edit location similar to KDE 4.X

In contrast, Qt dialog is usually customizable and able to use either GTK+ or KDE dialog style. The dialog style may be changed by one of following methods.

  • manual configuration, program specific (by VLC media player, etc.)

  • manual configuration, system wide (by Qt Settings, so far only applicable for programs that depend on Qt 4 in older releases of Ubuntu i.e. 14.04)

  • auto configuration, system wide (by installing certain toolkit package that is detected automatically in newer releases of Ubuntu i.e. 16.04)

Despite different toolkit offers different experience and dialog style, all mentioned toolkit (GTK+, KDE and Qt) allow users to edit location in file chooser dialog.

TL;DR To this date, KGtk seems to be the only way to replace GTK+ dialog and it must be applied per application. There is no known alternative to actually replace the dialogs for system-wide case. Else, look for workarounds to make GTK+ file chooser load faster (This would be another question).

  • Thanks for the answer! I don't know why, but on my system the kde/qt dialog is much faster/responsive than the GTK dialog. As for usability, the GTK dialog has a number of unconventional behaviors that I'm not used to/dislike (e.g. needing to press enter after tab completing, which then causes a 2-3 second delay before I can type again). I'll have look at KGtk. – gandalf3 Nov 24 '15 at 19:27
  • Your answer doesn't make sense. "Slow" doesn't matter for a UI. It's not a particle simulation. And the KDE one does allow to edit the path, it's the GTK one that doesn't easily let you do that. – LtWorf Sep 29 '16 at 12:19
  • Finally, I managed to make some time to improve overall answer. I have confirmed that KDE dialog has more options to edit the location in file chooser thus, might be easier than GTK+. – clearkimura Feb 12 '17 at 9:56

Since around 2016 the answer is yes! At least for using the KDE file chooser with GTK3 apps.

Gtk+ developers call this “native file choosers” for “sandboxed applications”, while the primary target for this was Flatpak it also made it possible to use these on Windows. However you can also use this for non-sandboxed/flatpak applications using a trick:

  1. Install the xdg-desktop-portal-kde package: Arch Linux, Debian, Fedora, KDE Neon, Ubuntu (Direct Install link)
  2. If you are not actually using KDE, edit /usr/share/xdg-desktop-portal/portals/kde.portal and add the value of $XDG_CURRENT_DESKTOP, separated by a semi-colon to the UseIn=KDE line (i.e.: UseIn=KDE;xfce)
  3. Add the line GTK_USE_PORTAL=1 to ~/.pam_environment so that GTK will always behave as if it were in an sandboxed environment
  4. Log out and back in to apply these changes
  • I should maybe add that this will not work for apps using the classic GtkFileChooserDialog or GtkFileChooserWidget APIs: These expose the underlying GtkWidgets to the application which would not be available when rendering the file chooser using anything other than GTK. Hence, only GtkFileChooserNative and GtkFileChooserButton will work and if you see a GTK app still using the GTK file chooser after performing the above steps, you may want to send them a patch. ;-) – ntninja Apr 13 at 18:31

I found some instructions regarding replacing GTK dialogs with QT dialogs:


Under "Tips and Tricks", there is "KDE file dialogs for GTK+ applications".

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.