Page MenuHome

File Browser UI
Open, NormalPublic

Tokens
"Dislike" token, awarded by capnm."Love" token, awarded by bnzs."Doubloon" token, awarded by madminstrel."Love" token, awarded by hjrabi."Love" token, awarded by amonpaike."Love" token, awarded by ace_dragon."Love" token, awarded by xrg."Love" token, awarded by jendrzych."Love" token, awarded by Jaydead."Love" token, awarded by Zino."Love" token, awarded by duarteframos."Love" token, awarded by dark999."Love" token, awarded by Tetone.
Assigned To
None
Authored By

Description

This follows on from T37982 (all the way back in 2013!) which included several plans and UI designs for updating the File Browser layout and interface.

As discussed with @Julian Eisel (Severin) on IRC, we were going to follow on from that old topic, but decided to create a fresh File Browser design task instead.

Issues

Currently, the File Browser has a number of issues:

  • The general layout doesn't communicate the hierarchy well
  • The execution button (Open/Save etc) is in the top right
  • The header is overcrowded and not easy to read
  • The operator settings take up too much room, even when it's not needed
  • The sorting is separate from the data-view columns

References

As it turns out, the three main platforms we support use a surprisingly similar layout for Open/Save dialogs:

Mac:

Windows:

Linux:

Things they have in common:

  • Execute buttons in bottom right
  • Ability to sort items by clicking on the category headers
  • File path at the top, file name along the bottom
  • Source list on the left
  • Display buttons at the top
  • Search in top right

By following the basic common design and layout, Blender will fit in more nicely with all three platforms.

Mockups & Diagrams

Back in 2013, we made these mockups, to visualise what an updated File Browser could look like:


(Disregard the UI styling here, it's not related to this task)

With recent work related to the Asset Browser, we made updated UI diagrams:

Notes

  1. We could make it open as a new window by default, which makes it easier to close again, and is more consistent with the Preferences window
    • Currently, using the File Browser takes over the whole window, with a small 'Back to Previous' button.
    • In this state, you still see the active scene and the active view layer, as well as tool settings, all of which make no sense
    • This could be made a single, consistent option that applies to all temporary windows (File Browser, Preferences, Render window)
  2. Might be a good time to remove the '..' buttons to go to the parent directory
    • It's no longer a convention in any of the OS's we support
    • We are still emulating Windows 3.1 here, which is... yikes.
  3. We could make shift-clicking select all items in-between
    • Same thing is needed for the Outliner, could be solved similarly
  4. We should handle deleting data better
    • Deleting files or folders via the File Browser currently hard deletes it without even using the system Trash
    • This is highly error-prone and dangerous - better to just remove the ability to delete from the File Browser, or use the system Trash for Mac, Windows & Linux.
  5. The operator settings region in the bottom left often has the wrong size, and is way too big.
    • We could make the area size dynamic, based on the number of options:

Details

Differential Revisions
D5601: File Browser GUI Redesign
Type
Design

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Other things that would be nice to address related to the File Browser:
These things could be considered out of the scope of this task, and could be handled separately, just noting them here anyway.
Operator settings placement
Currently we place the operator settings in the bottom left as a sub-region of the source list.

I think this has to be solved before the new file browser UI can go into master. The available space is much too small for common exporters. Placing them on the right hand side seems the most straightforward solution, and there are other 3D apps that do the same.

Trying to fit them along the bottom is too complicated I think, we have a standard single column layout almost everywhere in the UI and making an exception for this case is too much work for us and add-on writerts to be worth it.

@Brecht Van Lommel (brecht) I can see the advantage of that for sure. It’s also a lot simpler to do the layouts for that solution.

Right now IO scripts use clumsy enum buttons to jump between IO sections - if we used a sidebar for this they could simply use panels.


One could imagine this being laid out in a much simpler way, using panels instead of the enum, and using single column layout, which would make this a lot less wide, like so:

Yet another big issue with current file browser is how random and wrong the persistence of save settings is. For example, export settings do not survive file reload, they only stick during the file open session. Render output save settings on the other hand do not even persist during file open session, and are immediately forgotten every single time file browser is closed. This creates a huge space for error.

For the IO settings, we think we'll solve it this way:

Add a sidebar with regular single column layouts:

An Options toggle will then show/hide it more easily. This way we can keep the Options sidebar off by default, certainly for simple Save As and Open:

I think you're overcomplicating it. There's plenty of space in the file dialog since it's fullscreen anyway, unlike most system file browsers. Just keep the options visible and consistent.

@William Reynish (billreynish) IO scripts options are operator options, those are never spread across several panels currently, afaik. Not saying it would be impossible, but think that would require quiet some work first? Unless sub-panels can already be used inside operators draw functions?

Also, this looks promising and all, but would have been nice to be notified of this project earlier. Afaik, I am current filebrowser maintainer, and 'owner' of the whole File & I/O module, at least as per the module page, and it also closely touches the asset project... Just found out about that task & branch this morning, kind of by random discussion here at the studio... Would be nice to avoid such communication failure in the future. :/

guys, I don't know if it is related or if it is more a thing for when the asset manager arrives ... but it would be very useful to have the preview of the objects, mesh, tecture etc ... viewable when we search a blend file through "append"

@noki paike (amonpaike) : you can already do this if you generate previews first, see https://docs.blender.org/manual/en/dev/files/blend/previews.html

Thank you so much! I was not really aware of this function ... even if I have to tell the I don't see it very intuitive ... my logic would have expected something like: "append..." enter in the blendfile and in the objects folder, "I find in the browser the button that generates the previews ... or if i activate the visual mode Thumbnails, the previews are automatically generated at the moment ...
Of course, I'm talking about not knowing how the mechanics work, maybe it would be expensive at proccess level?

Now the IO operator controls are moved to the right sidebar, which now display all the IO controls in a consistent way:

If now uses the same layout system as the rest of Blender 2.8, and all the default UI scripts use the same panels now for consistency. These layouts are in the filebrowser_redesign addons Git.

Probably these are the last issues needing to be addressed before a merge/review:

  •  Fixed width Cancel/Execute and Options buttons (requires changes in layout API)
  •  Option for temp windows to be full screen

With the Import settings fully visible in the Sidebar, maybe the Sidebar could also be used for a preview of text/code files, that would be very useful for ex. the python templates, which are very hard, as a user, to understand what solutions a template actually contains when just reading the filename. If this was added maybe the hard to navigate Templates menu in the Text Editor could be removed, and instead the Menus entry could just open a file browser in the template path?

Here's the text preview on Windows:

I know Blender doesn't have a multiline widget(except from the Text Editor), but maybe a label pr. line could be used, like in this example(from another attempt at a more friendly python templates navigation):

A note on the dots (..):

Here are the reasons you shouldn't remove the dots:

  1. There's no harm in keeping them in addition to a button in the toolbar. A little bit of redundancy never hurt anyone.
  1. Anyone who has ever used a command line will appreciate them
  1. Blender uses relative paths very often. For new users unfamiliar with the concept for some reason, the dots in the file browser might help form a logical connection with the weird series of dots and slashes in their paths, so this is a valuable learning tool.
  1. The dots allow for easy and intuitive keyboard navigation without having to know any extra shortcuts.

The dots don’t work with the new keymap, because the default single click behavior is to *select* not open.

They don’t fit with how the File Browser works anymore.

Besides, there isn’t a need for it now that we have a more prominent real Up button.

I don't see how that's an argument against the dots. There's nothing wrong with opening the parent directory on doubleclick.

One thing I forgot to mention is that the dots also facilitate good old keyboard navigation.

I don't see how that's an argument against the dots. There's nothing wrong with opening the parent directory on doubleclick.
One thing I forgot to mention is that the dots also facilitate good old keyboard navigation.

The dots are old MS DOS concept :) I don't think we should have it sticking around. Keyboard navigation should be possible without them too. These days, standard in most file browser is Backspace key for going one folder up. Unlike the dots though, Backspace as shortcut for up button would not require you to first move your highlight cursor onto the dots and then hit enter. You can move one folder up regardless of what's currently selected in the file browser. Dots require you to first select them to go up.

Indeed we can easily do keyboard navigation without the dots, in fact it works better without.

The dots don’t work with the keymap, because it makes no sense to be able to *select* the parent directory. It’s non-sensical.

It seems to me that selecting the parent directory is logically exactly the same action as selecting a child directory. You're just selecting a link to a given directory. Like eg. single clicking on a shortcut on the windows desktop.
Anyway, I don't have any preferences either for keeping or for removing the dots, just wanted to say that they have worked well with keyboard navigation for years, for example in double-pane file browsers.

Dots are not an "old" MS-DOS concept. They are a filesystem concept in active use wherever you use relative paths. This is bread and butter for anyone who has ever written a script, an html page, or linked in a texture.

Using Backspace to go up is fine for what it's worth, but it's not intuitive, you have to know about it first. There's no reason we can't have a button in the toolbar, backspace for a shortcut, and the dots all at the same time.

Riddle me this: do you know use case where they are somehow detrimental? How is blender better without them? It seems to me like you're hellbent on removing a useful thing for no good reason.

dots are not used in path and in script to create relative or absolute paths?

@Piotr Adamowicz (madminstrel) removing them is better, because it makes the mental model simpler. What you see inside a directory then, is a list of that directories' contents. If the directory contains 7 items, you see 7 items, not 8 items as you'd currently do. Right now you always have to do a mental subtraction of one to get the correct number of items.

Next, exposing the parent folder as a folder *inside* the current folder adds confusion. All your files and folders have names you or the system have picked. But how is one to know that '..' means 'go up in the hierarchy'? There's nothing about .. that communicates moving up.

Then there's the fact that the keymap doesn't work well with it. With the keymap changes, the first thing that happens when you click, is that an item is selected. This makes sense for a file or folder - there are operations you might want to do on them - rename it for example, which you do in the right-click context menu, or via a shortcut. These things won't work with the '..' folder selected, because it isn't a real folder, which you cannot rename, cannot delete, cannot move, and so on.

Yup. Double dots are currently used TODAY in file system paths and web URIs. So not just some old-school thing but current and necessary features of file systems, even if hidden from users on OS X.

Selecting "parent" folder is just as valid as selecting any other folder.

If I am in C:\Harley\Test\ I should be able to select the "parent" folder as easily as selecting any other folder.

I could click something inside that folder and get a path like "C:\Harley\Test\Folder". Selecting "parent" should result in "C:\Harley\Test\.." which a perfectly valid path that is the same as "c:\Harley"

Like or not, ".." remains part of paths even if you remove the button. I can enter ".." at the end of the path string and then hit "Enter".

Relative paths to images will be stored in your blend file as strings containing "..", sometimes multiples.

@Piotr Adamowicz (madminstrel) removing them is better, because it makes the mental model simpler. What you see inside a directory then, is a list of that directories' contents. If the directory contains 7 items, you see 7 items, not 8 items as you'd currently do. Right now you always have to do a mental subtraction of one to get the correct number of items.

Good point. Adding an item count in the status bar should solve this nicely. In fact it would be better than removing the dots because counting folder items manually is just not a task for a human, and very slow for more than 10 files or so.

Next, exposing the parent folder as a folder *inside* the current folder adds confusion. All your files and folders have names you or the system have picked. But how is one to know that '..' means 'go up in the hierarchy'? There's nothing about .. that communicates moving up.

Also true. Can easily be solved by continuing to display an icon with a small upward arrow on the left, next to the dots, like Blender currently already does.

Then there's the fact that the keymap doesn't work well with it. With the keymap changes, the first thing that happens when you click, is that an item is selected. This makes sense for a file or folder - there are operations you might want to do on them - rename it for example, which you do in the right-click context menu, or via a shortcut. These things won't work with the '..' folder selected, because it isn't a real folder, which you cannot rename, cannot delete, cannot move, and so on.

As several people have noted, it is just as logical to be able to select the link to the parent folder as any other link. Not being able to rename the dots has never been a problem in any of the file managers that use this convention, and I don't see why it should be a problem in Blender. I've searched through the tracker for any complaints about not being able to perform operations on the dots, but I've come up empty, so this leads me to believe that this isn't a real problem people have.

voxel9 added a subscriber: voxel9.Aug 29 2019, 1:18 PM

A nice alternative method to go up one level which I like a lot in some file managers is the ability to double-click in the empty space of the list. The big advantage is that you don't need to move the mouse to find a specific spot/button to click to go to the parent folder. Could this be an improvement?

Speaking of consistency, the updated Outliner is using (like most of the file managers), Shift+click for contiguous selection, Ctrl+click for non-contiguous selection and Ctrl+Shift+click to mix the contiguous with non-contiguous selections. Shouldn't the file browser and Append > Advanced Filter use the same convention?

A nice alternative method to go up one level which I like a lot in some file managers is the ability to double-click in the empty space of the list. The big advantage is that you don't need to move the mouse to find a specific spot/button to click to go to the parent folder. Could this be an improvement?

This isn't discoverable, why would I double-click on an empty space? I see the same problem with the backspace idea. It is nice and fast to use when you know the trick. But we also need to have this function prominently visible, the two dots with the up arrow were for example great for this.

Speaking of consistency, the updated Outliner is using (like most of the file managers), Shift+click for contiguous selection, Ctrl+click for non-contiguous selection and Ctrl+Shift+click to mix the contiguous with non-contiguous selections. Shouldn't the file browser and Append > Advanced Filter use the same convention?

Yes I agree!

Guys, I don't know if this problem has already been solved with the new file manager, but in case I show what happens currently with drag and drop (from the vse workspace configuration)
please check.

A nice alternative method to go up one level which I like a lot in some file managers is the ability to double-click in the empty space of the list. The big advantage is that you don't need to move the mouse to find a specific spot/button to click to go to the parent folder. Could this be an improvement?

This isn't discoverable, why would I double-click on an empty space? I see the same problem with the backspace idea. It is nice and fast to use when you know the trick. But we also need to have this function prominently visible, the two dots with the up arrow were for example great for this.

As it could be an alternative, it is not excluding the visible solution (the two dots with the up arrow). So it doesn't need to be discoverable at the first glimpse. But for the users knowing the trick (accustomed to this method as well as with the backspace from other file managers) this might be a pleasant surprise. So I do not see it as an inconvenient. On the other hand, Blender, like many other applications, is full of hidden tricks which are able to make you smile when you discover them. Just my 2c...

@voxel9
I'm quite against this: I can already imagine bug reports about that "hidden feature".

Testing this file browser in the VSE Workspace I noticed a few things:

  • There is no (right)sidebar.
  • There is still the extend area from below in the left sidebar - but it is empty.
  • There are no file type options. Movies, sounds and images can be imported, so those options should be available(in a (right)sidebar?).
  • Why not have the footer exposed? (and remove Cancel and Rename "Okay" to "Add".
  • Right click on a file icon - and the only option is "Edit Source"?
  • Ex. "Rename" should maybe be exposed in this case ^ And not exposed in the general Context menu.
  • Increase/decrease isn't that a save option and not an import option, and therefore shouldn't be exposed in the import browser context menu?
  • In Thumbnails view the filenames takes up far too much space, if less text space another line of thumbnails could be visible.
  • Why no thumbnails in Vertical/Horizontal view?
  • There are several operators exposed in the Context menu - but they're not exposed in the header menu, and they should.
  • Would it be beneficial to have the Filebrowser area wider, so ex. import options could be exposed?
  • The column width is locked.
  • There is no (right)sidebar.
  • There are no file type options. Movies, sounds and images can be imported, so those options should be available(in a (right)sidebar?).
  • Why not have the footer exposed? (and remove Cancel and Rename "Okay" to "Add".

The way the file browser currently works, internally and hence externally, is that the action to perform with it (open file, save file, import image, export object, ...) has to be selected prior to opening the browser. If the file browser is opened as regular editor, no such action was selected. Thus, we can't determine what options to show in the sidebar, what's supposed to happen when pressing Okay (or Add as you suggest), etc. This can be improved, and should be at some point, but requires bigger internal changes that are not in scope of this.

  • The column width is locked.

Not sure which column width you mean?

  • Right click on a file icon - and the only option is "Edit Source"?
  • Increase/decrease isn't that a save option and not an import option, and therefore shouldn't be exposed in the import browser context menu?
  • There is still the extend area from below in the left sidebar - but it is empty.

These are bugs and should be fixed before merging.

Hi,

not really sure if it's in the scope of this task but I'd say so since it's complete File Browser UI overhaul. Could we also include finally ditching the New Folder confirmation popup?


It appears when creating new folder via shortcut, and makes process of folder creation quite clumsy. Creation of new folder is not dangerous or destructive enough operation to require error prevention in form of a popup, and it's also inconsistent with clicking icon, which does not require popup confirmation.

@Ludvik Koutny (rawalanche) absolutely. There's no reason for this. It's a holdover from when Blender used to have confirmation popups for everything.

@Julian Eisel (Severin) so you prefer to do this as part of the branch or separately?

@Ludvik Koutny (rawalanche) absolutely. There's no reason for this. It's a holdover from when Blender used to have confirmation popups for everything.

I'm not sure this is a good idea. Every time you misspell a folder (where you want to navigate to) it would create an empty folder without asking. Or if you mess up something when copying/pasting a path.

I removed it last week, rBea94cade2991.

Ahh, ok, too late. Could we get an informational popup like "Directory not found. Created."?

@Zsolt Stefan (zsoltst) This is regarding the operator to add new folders, via this button in the UI:

Previously, it would spawn a confirmation popup each time you would attempt to create a new directory.

@Ludvik Koutny (rawalanche) absolutely. There's no reason for this. It's a holdover from when Blender used to have confirmation popups for everything.

I'm not sure this is a good idea. Every time you misspell a folder (where you want to navigate to) it would create an empty folder without asking. Or if you mess up something when copying/pasting a path.

The prompt popped up before you started typing the folder name, not after :)

@Zsolt Stefan (zsoltst) This is regarding the operator to add new folders, via this button in the UI:

Sorry, I misunderstood, was thinking of the popup when entering manual input in the file path.

Of course, this makes sense!

@Julian Eisel (Severin) Thank you for looking into those so quickly.

I found a few more in the VSE Workspace:

It is very hard to see the pattern for when it is doing Box Selection and and when it is doing Drag and Drop(I would expect it to do box selection when dragging from an empty area, and drag and drop when click drag in a highlighted area):

Clicking in an empty area doesn't deselect as I would expect it to, but instead it keeps the selection and scrolls to the top:

Next one is maybe related to your answer above, but double clicking doesn't add selection from the VSE Workspace File Browser, as it does in pop up mode.
(When drag and dropping it seems like it does know how to distinguish the file types, since the mouse cursor text changes according to the file type)

Here goes a quick brain dump of the current file browser in master :)

More like a bug: ".blend" is not automatically added when typing in the file field. For example, typing "BLABLABLA", hitting Enter and then "Save" will save file without .blend extension.

Previously, it was possible to use numpad +/- practically anywhere in the file browser. Now it doesn't work when the mouse is over the file name entry.

The fact that corresponding buttons are removed from the interface makes this great feature practically undiscoverable.
Some rumors says this is available via the context menu, but i didn't find it in there either.

Text entries and buttons are huge. Not sure why is it so, and why there is a need to be different size from the rest of the interface.

The file window is taking over window used by preferences or by the render result.

"Options" button shouldn't be in the opposite side of a window from where the actual options are.
Hiding options by default for Ctrl-S but not for Export is somewhat confusing. Why not just to show options by default no matter what?

The window does not use X11 hint to tell it's a floating window. making it very annoying to use in tiled window managers.
Should probably also set modality hint as well.

Why to have filter entry? Just type anywhere in the file list, make the cursor navigate there immediately.

This is also something where i really start thinking we need to a user preference to make non-overlapping windows a default behavior, which will be applied for render result Display Mode and file manager.
Having Display Mode stored in scene is not really helpful, since that is more of workspace organization. No matter where the file came from i prefer t to be rendered in the same window.
Same for the change like file browser. I wouldn't want more window to start appearing.

Here goes a quick brain dump of the current file browser in master :)
More like a bug: ".blend" is not automatically added when typing in the file field. For example, typing "BLABLABLA", hitting Enter and then "Save" will save file without .blend extension.

Yes this was a bug, now fixed.

Previously, it was possible to use numpad +/- practically anywhere in the file browser. Now it doesn't work when the mouse is over the file name entry.

This should be fixed

The fact that corresponding buttons are removed from the interface makes this great feature practically undiscoverable.
Some rumors says this is available via the context menu, but i didn't find it in there either.

It's certainly in there.

The file window is taking over window used by preferences or by the render result.

IMO that is very strange - but not strictly related to File Browser AFAIK. It's more a general quirk of how temp windows work in Blender. But I agree it's unexpected and confusing.

"Options" button shouldn't be in the opposite side of a window from where the actual options are.

Not sure where to put it though? We couldn't find a better place. On the right you have the Cancel/Execute buttons, and we don't want to add it there.

Hiding options by default for Ctrl-S but not for Export is somewhat confusing. Why not just to show options by default no matter what?

We could, it's just that configuration looks rather silly with such a big empty area, and for saving and opening, these options aren't as important.

The window does not use X11 hint to tell it's a floating window. making it very annoying to use in tiled window managers.

Yes, secondary windows should stay on top, if that's what you mean. In general, secondary windows aren't handled so well, would be good to improve this.

Should probably also set modality hint as well.

Yes, so that it will stay on top and not allow you to go back just by accidentally clicking outside the File Browser.

Why to have filter entry? Just type anywhere in the file list, make the cursor navigate there immediately.

Yes, would be great to make it so you could type 'T' and go directly to the items that begin with the letter T. This has some implications

  • Then we cannot use single-key shortcuts in the File Browser (which is OK IMO)
  • Ideally we should then also add this to other lists views like the Outliner

This is also something where i really start thinking we need to a user preference to make non-overlapping windows a default behavior, which will be applied for render result Display Mode and file manager.

Yep, we discussed this. It's important to add this.

Having Display Mode stored in scene is not really helpful, since that is more of workspace organization. No matter where the file came from i prefer t to be rendered in the same window.

Exactly right, it's a preference, not a scene setting.

The file window is taking over window used by preferences or by the render result.

IMO that is very strange - but not strictly related to File Browser AFAIK. It's more a general quirk of how temp windows work in Blender. But I agree it's unexpected and confusing.

Any planned work on this topic?

"Options" button shouldn't be in the opposite side of a window from where the actual options are.

Not sure where to put it though? We couldn't find a better place. On the right you have the Cancel/Execute buttons, and we don't want to add it there.

To me it's an unnecessary button, so best answer from me here would be "just remove it" =\
Is not how similar panels are communicated to user in the rest of the interface as well.

Hiding options by default for Ctrl-S but not for Export is somewhat confusing. Why not just to show options by default no matter what?

We could, it's just that configuration looks rather silly with such a big empty area, and for saving and opening, these options aren't as important.

Their importance is subjective to what your task is. For a TDs those are rather important.

It is also unclear how addons can communicate importance of the options. They might have a lot of fine-tuning knobs which are almost never used, or have a single property which is used all the time.

The window does not use X11 hint to tell it's a floating window. making it very annoying to use in tiled window managers.

Yes, secondary windows should stay on top, if that's what you mean. In general, secondary windows aren't handled so well, would be good to improve this.

Not here. The staying on top is more of the next point.

Tiled managers are following non-overlapping windows placement. So currently, when you hit Ctrl-S a tiled window manager will re-allocate placement grid and put file browser window next to the main Blender window.
UI frameworks such as Gtk or Qt are using special hint for window (window as in X11 window) used by file dialogs to tell window manager that those windows should be floating, and do not need space allocated in the tiled grid.

Why to have filter entry? Just type anywhere in the file list, make the cursor navigate there immediately.

Yes, would be great to make it so you could type 'T' and go directly to the items that begin with the letter T. This has some implications
Then we cannot use single-key shortcuts in the File Browser (which is OK IMO)

I find this OK as well.

Ideally we should then also add this to other lists views like the Outliner

I agree.

For the buttons to increment the file names, we will add those inside the file name field, just like to have buttons inside the search field:

Could the header's arrow be disabled/hidden? or maybe moved slightly to the corner, it overlaps with the button and
sometimes i accediantly click it....the Preferences Editor also has one but it's not as problematic as the File Browser.

I think it would be interesting if the letter shortcuts behaved like "search for initial letter files" like modern file browsers ...

When we are already talking about what is a preference vs what is a scene setting, Import/Export settings for various importers and exporters should be preference too. Despite being aware of it not being the case, it gets me every day and causes constant errors. Import and Export format settings are software-wide preferences in any other 3D software, for a very good reason.

Here is my feedback on the change (I also full agree with Sergey's points):

1. Removal of the .. folder.

I think this is a quite important feature. It minimized the required mouse movement when navigating folder.
It allowed the user to not leave the file list (or blender file content when linking/appending).

Now you have to move the mouse to the upper left corner and out of the file list to do this:


It only took up one entry of the file list and I used it all the time. I feel that keeping it will not really alienate new users.
Sure I could use shortcuts instead, but that would be slower as I have to either take my left hand of the home row or move my right hand off the mouse.
With the "back folder" I can keep my hands in place and not move my mouse around too much.

2. Double click to enter folders.

This is useful in file managers because this allows you to easily select folders and move them or delete them.

However Blender is not a file manager, it is file browser. You can now select folders as you can in file managers, but you can't move folder or delete them (or perform more advanced operations on them).

Previously, we had single click to enter folder, it was fast and simple. Especially when linking/appending content from .blend files.
Now we have to double click each time to enter folders even inside .blend files. This effectively doubles the amount of click we need to do without any of the upsides of this feature in file managers.

Please bring this feature back. Or perhaps single click on the folder icon would open that directory, while single click on the folder name would select it?

If we want to add more file manager features, I feel that double clicks to go into folders could be in a special mode.
Most of the time I spend in the file browser is to navigate to files, not modify file structures or delete folders.

3. General placement of elements

I'm not saying the the older browser layout was good. I am actually glad that some work is going on here to improve it.
I hated the placement of export/import options, so I think that is is good that we are moving stuff around a bit :)

However, I feel that with the new layout a lot more mouse travel is needed. In the older browser, it was mostly restricted to the upper left triangle.
In the new layout it has placed hotspots in all four corners of the browser (and thus maximizing the potential mouse movement):

I have broken this down further for illustrate my workflow and line of thinking with colors and number denoting the start and end of opening a file:

  1. When working with the file browser I usually start by inputting the file path or going to my bookmark.

In some cases I go to change the default folder display. With the new layout, this has been moved to the opposite side of the browser.
I wouldn't mind as much if these settings were saved. On the other hand I don't think that they took up that much space as icons either.
So if they were moved out of the drop down menu again, I think that the path field would line up a bit better with the file view.

  1. Here I use the file view to navigate further and when I arrive at the desired location, I might use the search of filter options to find the file I want.

I think the changes here are fine, so no feedback here!

  1. Here I finalize the load/save setting before I finish.

When saving files the previous layout was quite comfortable as the mouse was in most cases already near the top.
However, if I needed to change some load/save setting I had to move my mouse to the lower corner.
If the N-panel is now going to be on by default, this wouldn't be needed anymore as the setting would be a lot closer to the open/save button.

However, with the buttons now on the bottom, you have to move your mouse from the top of the window to the bottom.
If we instead move this up again, the hot spots of the browser would mostly be restricted to the top part of the window which would be very nice I feel.

I'll stop here as I don't want this to become more of a "wall of text" than it already is.
I hope that we can come up with something new that addresses these issue I have. I'm always open for iteration and discussions.

Here is my feedback to the new file browser:

  • Generally: a great step in the right direction! It is mostly what I'd expect from a normal file browser.

What I like:

  • Placement of file name and open/cancel buttons on the bottom. Mostly an industry standard. If you really don't want to move the mouse cursor so much, you can alway press ENTER to open or ESC to cancel.
  • Finally, sorting and reverse sorting by name/date/size more intuitive (clicking once on the header of the proper coloumn.)
  • Recursive folders list. Very nice!
  • Volumes list maximized as default.
  • Options list in the right hand panel: much more visible like this!

Neutral:

  • Double click to open. It does take a bit more clicking, but it is more or less the expected behaviour. If we stick with double click, then I would add some more possible operations on selected elements: rename with F2, delete, etc.
  • Options button bottom left. It is a bit weird that it opens options on the other side. But there is no place for the button on the right, so I guess it's okay.

What I don't like or would change (minor points)

  • Rename selected folders or files with F2. Pressing F2 to rename pops up a window, but it doesn't rename the folder, but the object that is selected in the 3D view. This is not clear and very confusing.
  • Writing a new folder name in the file path does not allow creating a new folder. Was there a reason to remove this function?
  • As others mentioned above: entering a letter (or more letters quickly) should jump to the filename beginning with it.
  • CTRL-scroll could change the thumbnail size in thumbnail view.
  • Show the given names of network drives (in Windows, don't know how this works in other OSs). I use these at work, and they show up like "SV20000007 (V:)" or "1950 (N:)" in Blender.

Really like the direction this took, congratulations, this is an improvement of what we had previously.

1. Removal of the .. folder.
I think this is a quite important feature. I minimized the required mouse movement when navigating folder.

Totally agree with Sebastian, the .. to go to parent it did reduce mouse travel and eye focus jumping around. Especially with Go to parent tucked in tightly between other buttons all the way up there, it requires a lot of aiming. As mentioned before:

Not only does it have a fixed position in the UI ( no need to hunt for it in toolbars or look around), it is also part of the file list, which is where yours eyes/attention is usually focused, making using it very fast because you don't have to shift focus to another part of the UI.

A breadcrumbs style bar could help a bit.

Double click to enter folders is very welcome IMHO, otherwise it is impossible to select a folder for actions like renaming for example.


Some feedback:

Bug/limitation: Currently pressing F2 in the file browser opens the Object Name dialog from the 3D View, which is misleading. It causes one to accidentally rename the active object while erroneously thinking it was a file system item. Either ideally make it rename the selected item, or if not possible disable it completely.

Anyway congrats, keep up the great work

The new file browser is doing strange effects to my head, it is convinced that it is an external file browser to blender,
And then I happen to perform tabbing operations, or navigate with the arrow keys, I even happened to want to do copy paste operations to move files to other folders, and to press shortcut to search for files based on their initial letters. but none of this exists.
Help!

I've found something that might be considered a bug. At least I can see it confusing users.

Saving an image with Shift-F pops open the new file browser, with Options turned off. You then cannot select the file type (image type). Having the options closed for Blend file open/save is OK. But not when you can save in different formats. Normal save file windows always have a file type selector (while other setting like JPEG quality percent are often hidden)
In addition, you cannot change the file type by typing in the file name. If you have "myrender.jpg" and type "myrender.png", it reverts to jpg.

@Zsolt Stefan (zsoltst) Yes, the Options pane should be opened for image saving. Noted.

+1 for renaming files to come back

Here are some of the items that, in my estimation and based on feedback, would be good to solve for the File Browser:

These we should probably do for 2.81:

  • Add + and - buttons inside the name field
  • Make the Options sidebar open by default when saving images
  • Add preference for each temp window to either open as a window or the old full window temp state. (also move Render window option to Preferences for consistency then)
  • Add click-in-empty-area-to-deselect to File Browser

Other things we should do - maybe less urgent but nice improvements:

  • Better handling of temp windows, so they don’t ’steal’ each others windows
  • Better handling of secondary windows so they always display on top
  • Ability to jump to an item by typing in relevant letters (also requires keymap changes)
  • Refactor Export so that you select the file type inside the File Browser, rather than the File menu
  • Refactor Import so that you select the file in the File Browser, and the relevant Import options are displayed depending on the selection
  • Smarter file path controls that work like clickable breadcrumbs, which also allow you to double-click to edit as text

@William Reynish (billreynish) or @Julian Eisel (Severin), please create a new task for tracking remaining file browser work, and set the Blender 2.81 milestone tag on it. It's becoming hard to track the status and decisions in this long task.

For things that have been requested by multiple people here that were decided not to be done, please also list the remaining open questions or decisions in that task.

Better handling of temp windows, so they don’t ’steal’ each other windows
Better handling of secondary windows so they always display on top

I think these must be solved for 2.81.

Further I think we should also:

  • Add back ..
  • Always show options and remove the "Hide Options" button.
  • Add + and - buttons inside the name field

! In T62971#770631, @Brecht Van Lommel (brecht) wrote:

Further I think we should also:

  • Add back ..
  • Always show options and remove the "Hide Options" button.
  • Single click to open folders.

I, perhaps an 'old-school' user, don't really like the multi-window feature, but I think all of these points would significantly improve the ergonomics of the new interface.

+1 for options panel always enabled, not just when saving images. If an operator has even 1 option, that option should be displayed. I'd rather have empty space in some cases if the alternative is having options hidden behind a button.
+1 for some way to bring back single-clicking.
+1 for always-on-top.
-1 for anyone talkin smack about popovers, I think they're fine. With the extra space, it can show options as text instead of an icon. Icons basically just means you have to wait for the tooltip to show up until you know wtf it's supposed to do.

  • Imo the top of the options area should have some kind of header, just saying "Options" or the name of the operator that created the file browser.
  • Might be known, but the top section of the file browser can be hidden but afaict cannot be un-hidden. I can submit a report for this if needed. Might be OS dependent.
  • In the Filters popover, the checkboxes being in between the icon and the text feel super weird. Checkbox should be on the left, then icon, then text.

I don't wonder that people are requesting double dot to come back when folder up action was mapped on Alt+Up Arrow. That shortcut literally takes two hands to execute, so one has to let go of mouse and use both hands just to go one folder up. That's incomparably worse to just clicking the double dot. If the double dot has to go away, then you need to provide a sane alternative to up one folder, which Alt+Up Arrow is certainly not. What's wrong with the Backspace key, which is the standard in pretty much every file browser out there.

@Ludvik Koutny (rawalanche) you can simply press P to go to the parent folder. This works for the default Blender keymap, just as it always has.

I don't wonder that people are requesting double dot to come back …

The double dot is ergonomically exactly right here.
In general, I think imitate bad design decisions from other tools is a step back, not a step forward in the current Blender UI.

@Ludvik Koutny (rawalanche) you can simply press P to go to the parent folder. This works for the default Blender keymap, just as it always has.

I always switch to ICK when testing 2.81, so I assume that industry standard in that case would be backspace :)

Also, since there's a plan to support finding file by typing the first letter, P would have to go away anyway, and combining it with any modifier key would again mean two-hand interaction.

@Ludvik Koutny (rawalanche) you can simply press P to go to the parent folder. This works for the default Blender keymap, just as it always has.

I always switch to ICK when testing 2.81, so I assume that industry standard in that case would be backspace :)

No, on Windows it is Alt-Up and on Mac it is Cmd-Up, for going to the parent folder.

I've enabled Cmd-up now for Mac users, so both will feel at home now.

@Ludvik Koutny (rawalanche) you can simply press P to go to the parent folder. This works for the default Blender keymap, just as it always has.

I always switch to ICK when testing 2.81, so I assume that industry standard in that case would be backspace :)

No, on Windows it is Alt-Up and on Mac it is Cmd-Up, for going to the parent folder.
I've enabled Cmd-up now for Mac users, so both will feel at home now.

I use computer since I was about 11 years old. I am now 28 and it is the first time I know about Alt+Up working in Windows. Everyone knows about backspace, which works in Windows too, by the way. Furthermore, it still doesn't solve the problem of the folder up hotkey requiring two hands to press, making it way inferior solution to double dot. If you want to remove double dot, you really need to provide users with at least remotely comparable alternative, ergonomics-wise. Otherwise they will keep complaining, for a good reason, since you've now taken something that was fast and easy to do, and replaced it with something harder and slower to do, with no gain in return.

voxel9 added a comment.EditedSep 19 2019, 2:24 PM

@Ludvik Koutny (rawalanche) you can simply press P to go to the parent folder. This works for the default Blender keymap, just as it always has.

I always switch to ICK when testing 2.81, so I assume that industry standard in that case would be backspace :)

No, on Windows it is Alt-Up and on Mac it is Cmd-Up, for going to the parent folder.
I've enabled Cmd-up now for Mac users, so both will feel at home now.

I use computer since I was about 11 years old. I am now 28 and it is the first time I know about Alt+Up working in Windows. Everyone knows about backspace, which works in Windows too, by the way. Furthermore, it still doesn't solve the problem of the folder up hotkey requiring two hands to press, making it way inferior solution to double dot. If you want to remove double dot, you really need to provide users with at least remotely comparable alternative, ergonomics-wise. Otherwise they will keep complaining, for a good reason, since you've now taken something that was fast and easy to do, and replaced it with something harder and slower to do, with no gain in return.

I know I'm repeating myself but ... did anyone try for a while to see how double-click in the empty area to go to parent folder works? I'm using it in LinuxMint Nemo and it feels very comfortable. no need to move to ".." or to the up button, no need to move the hand to find a key on the keyboard ... Anyway, just thought to mention it again.

Did anyone try for a while to see how double-click in the empty area to go to parent folder works?

I have been using that daily for quite a few years now across multiple alternative file browsers for windows like FreeCommander, XYPlorer, Tablacus and it is quite convenient; I'm a big advocate of this navigation method.

I recognize however that it is relatively "non standard" and obscure, and would be very hard to discover for new users. I don't think it would be a fitting replacement for having .., nor even something to include in the default keymap (can confuse users), but I would certainly welcome keymap support for the ability to set it up manually if one wanted to.

If you think that some additional feedback could be useful:

  • it would be nice to remember the size and the placement of the window
  • I liked a lot the single click to enter a folder
  • I feel weird that the Options button on the left side of the window is opening a panel on the opposite side
  • personally, I'm switching a lot between the display modes. The fact that they are now one more click further in a menu instead of the main toolbar is slowing me down a little.
  • it would be nice a "Select All" checkbox only for the Filter Blender IDs list (maybe instead of the small Blender icon)

Did anyone try for a while to see how double-click in the empty area to go to parent folder works?

I have been using that daily for quite a few years now across multiple alternative file browsers for windows like FreeCommander, XYPlorer, Tablacus and I I'm a big advocate of this navigation method.
I recognize however that it is relatively "non standard" and obscure, and would be very hard to discover for new users. I don't think it would be a fitting alternative for having .., nor even something to include in the default keymap (can confuse users), but I would certainly welcome keymap support for the ability to set it up manually if one wanted to.

The way I'm learning the shortcuts in a new application is to read to tooltip (if available) or the shortcuts displayed in menus. So I wouldn't worry too much about discoverability but about unintended side effects.

did anyone try for a while to see how double-click in the empty area …

I hold a mouse click in an empty area for a wrong UI concept. There isn't always (or mostly, depending on your work) an empty area to click available.