File/folder opening dialog is missing a title bar

[spotlesscoder]

Prerequisites

• [X] I have searched open and closed issues for duplicates.

Describe the bug

I was editing some files in Visual Studio Code. Then I wanted to open a complete folder to edit some more files. I was not sure whether I clicked the correct menu item in VS Code which allows to open either to open a single file or a complete folder.

So I looked at the title bar of the opening dialog but it was empty.

Expected behavior

Folder opening dialog should have window title "Open folder" Single file opening dialog should have window title "Open file"

Platform Information

Please check what applies: -->

• [ ] I'm using the latest version from git that I've manually compiled
• [X] I'm using the latest released stable version

[jeremypw]

From your picture it looks like VSCode is not opening the elementary filechooser. However, the elementary version probably has the same issue as it only modifies the Gtk Filechooser with respect to mainly the pathbar (at the moment).

[jeremypw]

The Gtk filechooser (and therefore the elementary filechooser) dims out files that are not folders when in "Select Folder" mode and they are not selectable. However, I agree it is not obvious, especially if there are no normal files in the view. It would make sense to modify the button label to "Open Folder" maybe. I guess the elementary filechooser could hack the Gtk FileChooser even more that it already does to achieve this, although the intention is to move to using the NativeFileChooser portal in future to replace the entire thing.

[spotlesscoder]

Yeah I recognized that too but the first look is likely to go to the window title bar as this should always give you some context of what you're looking at.

[jeremypw]

Title bars are kind of deprecated in elementary as a waste of space - elementary apps (and the filechooser) use that space for headerbars with widgets. In the case of the filechooser that space is taken up by the pathbar so there is not really room for a title.

[PJ-Singh-001]

We are experiencing a similar issue in Cubic as well.

https://bugs.launchpad.net/cubic/+bug/1887219 (Please see the above Launchpad bug for screenshots).

The application uses the GtkFileChooser with GtkHeaderBar.

Is it possible that this Issue and Issue #1303 are caused by the pathbar taking all the available horizontal space (or overlaying all the buttons) in the file chooser header bar?

[jeremypw]

#1303 is not really related - there is no intention to provide different views in the Filechooser. The filechooser module actually removes the existing widgets in the headerbar and replaces them with the navigation buttons and the pathbar. Elementary design dictates that additional action buttons should be added at the bottom, not in the headerbar. Programs like Geany do this.

In future I expect the current filechooser module to be replaced with the NativeFileChooser portal which will limit how apps can interact with the filechooser.

[PJ-Singh-001]

OK.

Could you suggest a way to programmatically determine if the modified FileChooser header bar is being used? Using this, I can provide a different FileChooser (with buttons on the bottom) if the user is running Cubic in Elementary. (Idealy, I'd like to avoid hard-coding a check for Elementary OS, specifically, because the application is intended to run on multiple Distros).

Regrading the future "NativeFileChooser portal", I presume the new file chooser will natively provide Cancel and Select buttons, and will emit the button clicked events for these buttons?

[jeremypw]

Could you suggest a way to programmatically determine if the modified FileChooser header bar is being used?

Not sure, maybe you could check the types of the child widgets in the headerbar?

Regrading the future "NativeFileChooser portal", I presume the new file chooser will natively provide Cancel and Select buttons, and will emit the button clicked events for these buttons?

My understanding is that it will be possible for Files to provide this Dbus service and therefore have full control over the dialog UI (so could provide different views and sidebar) but it will be restricted to the specification of the portal as what public methods and signals are provided and the app will not be able to modify the appearance of the dialog beyond that spec.

While the API of GtkFileChooserNative closely mirrors GtkFileChooserDialog, the main difference is that there is no access to any GtkWindow or GtkWidget for the dialog. This is required, as there may not be one in the case of a platform native dialog. Showing, hiding and running the dialog is handled by the GtkNativeDialog functions. See https://developer.gnome.org/gtk3/stable/gtk3-GtkFileChooserNative.html .

[jeremypw]

There is no indication in the headbar whether the dialog is for Opening Single File, Multiple Files or Folder(s). This is the design of the Gtk file chooser but the elementary one could in principle be modified to do so.

[spotlesscoder]

I would appreciate if this is changed ;)

[jeremypw]

At least added to a project now so improved visibility.