45

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.

Improve this question
3
  • 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.
    – user109256
    Nov 9, 2015 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, 2015 at 21:23
  • 3
    @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, 2015 at 8:47

4 Answers 4

Reset to default
14

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
Improve this answer
10
  • 1
    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, 2019 at 18:31
  • Some "environments" don't use $XDG_CURRENT_DESKTOP. I run FVWM as my "X session manager". So I'd be setting it to an empty string, which doesn't sound right. I'm assuming I should just put something to set that value in my login scripts to e.g. fvwm and then match it in kde.portal. Also I'd really rather not install flatpak stuff if I can avoid it (xdg-desktop-portal-kde pulls in flatpak as a dependency in debian). Additionally, I don't think ~/.pam_environment does anything on my install.
    – Wyatt Ward
    May 12, 2020 at 9:29
  • @Wyatt8740: If there is no standard value for $XDG_CURRENT_DESKTOP for your configuration making one up and using that is a reasonable solution. If ~/.pam_environment doesn't work try adding session required pam_env.so user_readenv=1 to end of /etc/pam.d/common-password (making it the very last session-type plugin executed) or, for X11, try exporting the value in ~/.Xsession instead. At least on my Debian unstable system I see no dependency of xdg-desktop-portal-kde on flatpak, only on bubblewrap…
    – ntninja
    May 19, 2020 at 18:34
  • 1
    Kubuntu 20.04, this method doesn't work.
    – James Bond
    Nov 7, 2020 at 9:29
  • 2
    Ubuntu 20.10, doesn't work
    – QkiZ
    Jan 4, 2021 at 11:05
11

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.

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.

Improve this answer
3
  • 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, 2015 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, 2016 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+.
    – user109256
    Feb 12, 2017 at 9:56
0

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

https://wiki.archlinux.org/index.php/Uniform_look_for_Qt_and_GTK_applications#QGtkStyle

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

Improve this answer
0

@mirabilos I got it going yesterday. Only thing wrong now is that i don't like the fading effect when selecting a file and don't see an easy way to turn it off anywhere (it's not a KDE desktop effects setting). Doesn't really mesh well with my otherwise Motif-looking desktop. But that's a separate issue. Thanks.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .