Would like to configure the file opening dialog for an app

[pixelmixer (mark sweeney)]

It would be nice to configure the file opening dialog so that it is relevant to the app.

This issue has been kicked from GIMP, to GTK, to here.
Does anyone have thoughts or suggestions on this issue?

Unable to configure the file dialog side panel (#5918) · Issues · GNOME / gtk...

[pixelmixer (mark sweeney)]

Is this question in the wrong forum?

Does anybody where a question about the file dialog in GTK should go?

[ebassi (Emmanuele Bassi)]

@pixelmixer

Is this question in the wrong forum?

No, it’s the correct forum.

It’s simply as I told you in the issue: there’s no spare design and development capacity for a file selection dialog redesign.

In general, GTK developers try to touch the file selection dialog as little as possible—every change ends up being met with the equivalent of xkcd 1172; platforms can use portals, these days, if they want to ship a completely different UI.

[pixelmixer (mark sweeney)]

My understanding so far:

The OS could implement portals for the app developers to use.
File dialogs provided by GTK is not being developed any further because of portals.

[dboles]

The file chooser will be developed for clear bugs or functional needs, but a redesign is unlikely because there are already more than enough opinions/controversy about the current design…and equally few resources to take on such a big/fraught task. Customisation is not a priority, for the same reasons and since it is less generally ‘useful’.

Portals help by letting users get their native OS/DE’s file chooser, which might be more to their tastes and/or offer more customisability, as it would seem in this case.

[pixelmixer (mark sweeney)]

Thanks, is this more accurate?

File dialogs provided by GTK are not being redesigned any further.
For example, grouping the folders and files available to be opened, or allowing default desktop folders to be removed would be a redesign or customisation, not a functional need. And is therefore generally considered to be a less useful use of scarce GTK resources.

Portals, which are implemented by the OS, will offer more customisation options. They will also be a seamless experience for the user, file dialogs will appear the same as in the file system.

Until Portals are supported, file dialogs will remain as is, a flat list of all folders from the OS.

[emergenz]

@ebassi

platforms can use portals, these days, if they want to ship a completely different UI.

With “portals”, do you mean the XDG Desktop Portal?

I am quite new to it. It is said that the dialog windows must still be made by using a particular toolkit (e.g. GTK or QT). So, honestly, I don’t understand what is the groundbreaking moment by using portals. This is an additional layer - do we have not enough of that stuff?

The FileChooser evolution was, in fact, rather unhappy. In older versions of the Open file variant, it was possible to type in the filename with autocompletion, which I found useful. Then this feature was removed. On the other hand, I find it overloaded with features that I never used. The right answer to controversy over useful/useless features would be a customizable File dialog (e.g. Basic and Advanced versions, something like by the Calculator).

[emergenz]

@dboles

Portals help by letting users get their native OS/DE’s file chooser, which might be more to their tastes and/or offer more customisability, as it would seem in this case.

What is the native File dialog on Linux/UNIX?

[dboles]

It could be done via the file chooser of the desktop environment, run via a portal. There’s no law saying it has to be the GTK file chooser dialog.

[ebassi (Emmanuele Bassi)]

@emergenz

I am quite new to it. It is said that the dialog windows must still be made by using a particular toolkit (e.g. GTK or QT). So, honestly, I don’t understand what is the groundbreaking moment by using portals. This is an additional layer - do we have not enough of that stuff?

Portals are vendor-neutral D-Bus interfaces; the implementation of those interfaces is desktop/environment specific, while the callers typically reside in toolkits and additional libraries. If you use GtkFileChooserNative in GTK3 or GtkFileDialog in GTK4 you are already going through the portal API.

The whole point of using a portal is that desktop environments can provide an implementation that fits in with the environment’s own interface guidelines; for instance, GTK-based environment currently get a GTK3 file chooser dialog; GNOME gets a GTK4 file chooser dialog, but there’s some effort towards modifying Nautilus itself so it can be used as a file selection dialog. When running a GTK application under KDE, you’ll get the KDE file selection dialog; and so on, and so forth. Every environment provides its own implementation, and applications use it transparently.

@emergenz

The right answer to controversy over useful/useless features would be a customizable File dialog (e.g. Basic and Advanced versions, something like by the Calculator).

That’s an answer only if you don’t value maintainer time and user time, and you think the former should maintain a complex mess of settings, modes, and interactions, while the latter should spend their time customising something that needs no customisation whatsoever, just so you can get a CLI feature like autocompletion—something that, incidentally, still exists in the file selection dialog in GTK 3 and 4.

Additionally, “basic” and “advanced” modes are known to be a broken UX, because there’s no way to discover what’s “advanced” or “basic”, and there’s no way to incrementally move the user from a basic dialog to an advanced mode without the user already knowing what the “advanced” dialog mode contains. In short: it’s a terrible idea, usually offered as a way for “advanced” users to bail out of any design discussion, leaving just breadcrumbs to what they perceive as being non-advanced, or lesser users.

[emergenz]

Thank you for the short but insightful explanation!

@ebassi

… there’s some effort towards modifying Nautilus itself so it can be used as a file selection dialog

I think that this would be a better solution compared with making File dialogs more and more complicated.

@ebassi

Additionally, “basic” and “advanced” modes are known to be a broken UX, … it’s a terrible idea, usually offered as a way for “advanced” users to bail out of any design discussion, leaving just breadcrumbs to what they perceive as being non-advanced, or lesser users.

Surprisingly, I suspect that I would prefer the Basic version. However, I would call it “ascetic” and not “less-advanced”

[barefootliam (Liam Quin)]

On Linux under Gnome at least, you can type control-L in e.g. the gimp gtk+ file chooser, and in that text field there is autocomplete.

Unfortunately, UX research into file choosers was going strong in the early 1990s, e.g. with Sun and AT&T and others experimenting with using drag and drop and a file chooser window in OpenLook 3.1, but it got killed off when Sun moved to CDE, and the choosers regressed by a decade or so. The key insight from that research is highlighted by your question about completion - it’s about discoverability and affordances. Having a visible drag target in every application was what made that part work.

Accessibility work on drag and drop has also shown the need for drag lock support, so you don’t have to hold down the mouse.

I should admit, too, the OpenLook UI had lots of “advanced” panels that opened up to show weird features, and was far from perfect, but hey, it’s a UI from 1990 or so. At least they were doing the research. The lab later worked on stuff for Gnome, in Ireland.