Redesign FileSystem header

[AdriaandeJongh]

Problem or limitation

The FileSystem panel could use various usability improvements but many are on hold because the panel lacks options for extendability.

Proposed improvement

Split View	Min Width, No Split

List of changes

• Remove the file path input field. The point of a filesystem GUI is so that you do not have to type out a path. I suspect 99% of people have never touched this input field. If users want the path of a file, they can simply copy the path of a file from a file's context menu. If users want to navigate to a specific file, the ideal workflow is already to search for it using the filter.
• Move to 1 row: History, Filter, Sort, View Mode, Split Mode. More vertical space for files, and it looks slick.
• Make the history buttons a bit more square. They're weirdly thin buttons now, making the design look less slick.
• Make the filter icon a button that spawns options. It should still be inside search field visually, and could maybe get a small caret (although the sort button next to it also spawns options, but doesn't have a caret).
• Add the clear filter button (the 'X') left of the filter button instead of the current behavior where it replaces it.
• Move the List / Icon toggle to the bottom. Already implemented by Add various FileSystem QoL features godot#119103.
• New Filter options:
  • Checkbox: search currently selected folder only. This is something my team and I desperately need in a project with folders containing hundreds of assets.
  • … to be determined. There are various proposals (a quick search yields: filter by type, toggle fuzzy search, match case, show matching folder contents, etc) for filters and filtering that could potentially use this options dropdown now.

Proposal review

• Yes, this proposal is highly specific and actionable.

[AThousandShips]

Move to 1 row: History, Filter, Sort, View Mode, Split Mode. More horizontal space for the content that matters the most is a win.

More horizontal space in what sense? There's less horizontal space for the filter input

Also I'd be careful about making this wider by default, or sacrificing the width of the filter input, many users have limited horizontal space to work with, the editor is already a bit finicky to work with on laptop screens as it is and you often have to make the side docks unhelpfully narrow to have any useful main screen space to work with

Remove the file path input field. The point of a filesystem GUI is so that you do not have to type out a path. I suspect 99% of people have never touched this input field. If users want the path of a file, they can simply copy the path of a file from a file's context menu.

It does take up a relatively large amount of space with limited use, but I'd say it still serves a useful function for navigating very large projects when you have the path already, not having to go through several levels of folders if you have an error for example, maybe it could be hidden behind a button or you could switch between filter and path for the same input field

[AdriaandeJongh]

My mockup is quite wide, but the panel doesn't have to! Added a quick edit of the mockup in No Split mode with less width to the OP.

Regarding removing the file path input field and it's usefulness in larger projects: I think copy / pasting paths is extremely uncommon, and I think the workflow we're aiming for is for users to search / filter for the name of a file or folder.

[AThousandShips]

But the filter is pretty unusable when that narrow I'd say, it'd be significantly more useful with the same total width of the panel with only one button next to it, and I'd say that vertical space is far less at a premium in the editor than horizontal space, especially when taking eye movement into account, i.e. that using very tall interfaces isn't necessarily very useful as you have to do a lot of vertical focus shifting to get to useful places

I agree that it's uncommon, but I think completely removing ways to navigate the file system dock with a path would reduce usefulness, so I think having it be something yo can switch to would alleviate that while still achieving the more compact and focused layout

Edit: It could be interesting to have the filter field expand when focused, so that it hides the button and takes up all the available space, that would alleviate that problem

[AdriaandeJongh]

Hmm, unusable may be a bit of an exaggeration haha. I don't think it's unusable being that narrow. The majority of my searches is under 10 characters wide. And... I would also think that the majority of layouts make the FileSystem panel wider than the absolute minimum. For example, this is the width I generally have when doing actual work, and the new design would work with no compromises in such a setup:

I think the absolute minimum should be fully functional and agree that a squeezed input field is not 100% optimal, but perhaps I am of the opinion that under the absolute minimum width, we don't have to expect it to be. Regardless of whether it's 80% optimal or 100% optimal, what you get in return is a clean, compact, focussed design :)

It's an interesting idea to expand the filter field when focussed. I probably wouldn't expand the filter field over the buttons to the right of it, because you may want to touch those while you're searching for something. There have also been suggestions / proposals about hiding the filter field entirely and having it pop open with Ctrl + F, but in the case of the filesystem I think that adds unnecessary friction. In a large project, you search constantly. I think the filter field should always be present – at least in this panel.

[AdriaandeJongh]

If godotengine/godot#119103 is merged, then in the horizontal and vertical split views (but not the no Split View) the list icon moves to the bottom of the panel.

Edit: I updated this proposal to include the button position change from godotengine/godot#119103:

and

[KoBeWi]

btw the header is already unified in horizontal layout (i.e. at the bottom):

[NathanLovato]

For an input point, I'll share what we do and have seen with students. Starting with the listed file path: I've never witnessed a student use or ask about it. We plain ignore it in learning material.

That's because as Adriaan said the context menus cover the need + there's also drag and drop.

We tend to teach people to use the context menus because they're nicely organized and people can find important options with keyboard shortcuts listed. From what I've seen, learners use and like the drag and drop features a lot. You can drag and drop a file into a matching inspector slot, drag and drop it onto a script to get the path (or a preload line)...

This behavior is already fairly consistent between the scene dock, the file system dock (and the inspector). People really like it when they can do these sorts of things consistently across multiple editors.

And one thing I'll say is the less you have by default in the user interface, from an onboarding/teaching perspective, the easier it is for people. A single bar in itself may not seem like much but across the editor this attention to detail with having less lesser used options shown by default (but still accessible for power users, through shortcuts, the command palette, UI customization...) makes a big difference to help people stick with it.

And I'm thankful for you guys discussing and working on these things!

[passivestar]

Remove the file path input field. The point of a filesystem GUI is so that you do not have to type out a path. I suspect 99% of people have never touched this input field.

Agreed, I never understood why it exists

It does take up a relatively large amount of space with limited use, but I'd say it still serves a useful function for navigating very large projects when you have the path already, not having to go through several levels of folders if you have an error for example

Pasting uids into the filter field works, maybe pasting paths could work too

Make the history buttons a bit more square

#14012