Where is the FileChooser feature list?

The FileChooser has some idiosyncratic behavior that end-users might not expect. Our open source project runs on Linux, MS Windows & macOS. The GTK FileChooser behaves differently from the OS standard versions. Is there a checklist of features so that I can cover everything in the User Guide? (NOT looking to write a programmer’s reference.)

Among the things that I know I must cover:

  • Switching between breadcrumbs & standard mode
  • Click versus double-click selection & navigation
  • Customizing shortcut buttons
  • Settings shared between GTK applications
  • Saving setting specific to 1 GTK application
  • Environmental variables

A while back, I asked if anyone had written FileChooser docs for end-users and was willing to share. There was no response. Maybe just hitting bullet points will get a response.

Then you want to use GtkFileChooserNative (also available in GTK3), which will use the Windows or macOS file selection dialog, depending on the platform.

Ctrl+L will switch between the path bar and the location dialog.

I have no idea what this means. You have to double click in the file browser, but the side bar will use a single click.

Again, no idea what you’re referring to. There are no custom shortcuts buttons.

The settings are part of GTK, and they only include:

  • the initial location of the file selection dialog (either the current working directory, or the recently used files list); this only applies to the “Open” file selection dialog, as the Save mode does not have recent files. Additionally, the application can change the current folder.

There are no application settings.

There are no environment variables.

You should ask specific questions. Asking open ended questions makes it harder to give you sensible answers.

I was asking for anyone who had written ANY online introduction to using the FileChooser to share that URL. The more examples, the more likely that we can collate a GOOD introduction that EVERYONE can copy as a starting template.

We don’t want different native dialogs for the different OSes. We want to be able to respond with a workflow to a support question and have it cross-platform usable.

The features mentioned DO exist for this dialog.

Some are advanced user options … like making Directories sort first. (In our Windows port, that means tweaking the sort-directories-first switch in the C:\Program Files\GrampsAIO64-5.1.4\share\glib-2.0\schemas\org.gtk.Settings.FileChooser.gschema.xml

You are incorrect about shortcuts. Applications can set shortcuts, users can set bookmarks. See this

The click/double-click behavior is that some OSes require a double-click to change directory level or open a file. And there is a timeout. But in the GTK file chooser, the action occurs on a click of a selected item. And it can evilly pass the second click of a double-click through to the dialog after the refresh. So, since the first item in the list is selected by default, double-clicking the first item (e.g., a folder) applies the first click to the selected item, opening the folder. But the SECOND click is passed through to the next list after the refresh. And, since that will ALSO be the 1st item & be selected, that item will be opened,… which means blindly drilling down an extra level if it is a folder or blinding opening the first file. Ugly.

No, there is no documentation for the file selection dialog.

I don’t doubt that what you want exists, it’s just that I don’t understand what you’re asking because you did not describe it.

“Advanced” is a misnomer: they are mostly Easter eggs that should not exist in the first place.

Right, I thought you were asking for key shortcuts, because you did not explain what you meant with “shortcuts”, and there’s a naming collision.

I still have no idea what you’re asking, though.

Once again I’m asking: what are you asking, here.

I just listed the click/double-click behavior as an EXAMPLE that is among the feature or behaviors that would eventually be documented in the Users docs.

I am looking ANY feature/functionality list that would mention an item related to the FileChooser. This would help me compile a checklist with the right terminology. Then I write the docs while checking off the list.

There may be no documentation in the Gnome org. That doesn’t mean that NO application layered on GTK has written docs. (That was my original objective, to find something already written. The chance that NO ONE has written a hint or tip mentioning a tricky FileChooser action is highly unlikely. However, the chance that the author is reading this thread is also unlikely.) Now I am falling back to slogging through arcane programmer reference.

What I don’t understand is why you’re trying to make this such a difficult conversation. Use your intuition. I’m writing end-user docs. I’m writing about the FileChooser. I’m looking for the arcane specification and any scattered enhancement lists so I can write a demystified tutorial.

I am one of the people working on GTK. I am also one of the authors of the GNOME developer documentation.

To the best of my knowledge, there is no user documentation for the GTK file selection dialog.

The original author of the file selection dialog, back in GTK2, is not working on GTK any more, and hasn’t been for more than a decade; plus, the original file selection dialog has been changed over the past nearly 20 years since its introduction, so even if somebody actually documented it at the time, the documentation would not be relevant any more.

In general, the only documentation available is the API reference, which is for application developers.

I’m sorry, but I don’t want to use “intuition”: I am asking, pretty explicitly, what it is that you want, because this is a textual medium, and I cannot read your mind. If you want to ask specific questions, I can give you answers on how the file selection dialog is supposed to work, so that you can write documentation; asking generic, 10000 feet questions is pointless.

Incidentally, if this is how you write user documentation, I’m afraid you’re going to have a bad time—and your readers will have a bad time, too.

The first part of writing user documentation for software is usually prying information out of programmers who think differently from from the target demographic. API documentation that suits a programmer’s thinking patterns is too explicit & linear. This needs to be abstracted to give the user a conceptual framework.

I’m writing for a “great-aunt Martha” type who is artistic, totally non-technical. There are different learning modalities. Don’t try to shoehorn everything into your modality.

Honestly if you’re trying to document GtkFileChooser, you’ve probably already made a mistake. Your app really ought to use GtkFileChooserNative, or it won’t work properly on any platform. It will look weird on Windows and macOS because it won’t be using the platform native file chooser, and it will be downright broken if sandboxed on Linux because it won’t be able to see the host filesystem. (And if your app is not sandboxed on Linux, then that is a disaster!) The original GtkFileChooser just doesn’t stand up to the demands of 2022 and I highly recommend you move away from it.

I have to document what exists in the current application, not what I wish was there.

While I can submit a request for switching over to GtkFileChooserNative, it is uncertain when (or if) that will occur.

Well that would still probably not be a way to get an answer because GTK is a library for application developers. There is no other user documentation, programmers are the target demographic. A non-technical end user probably does not even want to know what GTK is.

You could make a case that GNOME (the desktop) should get a help section for this, but someone would have to write it.

Yeah. There are multiple layers of information siloing going on here.

The application designers don’t know all the idiosyncracies of the library. And the library designers don’t know what features were explicitly exploited by the application design.

And that is complicated by what Emmanuel said about the original designers of the library no longer being accessible. The same goes for our application project. It’s more than 20 years old and those designers have also moved on.

So I’ll take each lead anyone can provide about the FileChooser functionalities and follow where they lead.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.