Replace GTK+ file dialog with alternative
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:
- Install the
xdg-desktop-portal-kde
package: Arch Linux, Debian, Fedora, KDE Neon, Ubuntu (Direct Install link) - 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 theUseIn=KDE
line (i.e.:UseIn=KDE;XFCE
) - Add the line
GTK_USE_PORTAL=1
to~/.pam_environment
so that GTK will always behave as if it were in an sandboxed environment - Log out and back in to apply these changes
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.
Some clarifications
[...] 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.
KDE bug report in 2010 reveals that KDE dialogs were very slow.
KDE bug report in 2012 similarly reported that KDE dialogs can be even slower than other file chooser in KDE 4.X releases.
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).
Answerer's note: This answer was first written to address the usability and responsiveness issues of the file dialogs in GTK+, KDE, and Qt. Things may have changed since then and this answer may be deprecated. Hence this answer is now a community wiki, so that anyone with minimum reputation can improve this post or at least now more open to community edits.