Page MenuHome

File Browser UI
Open, NormalPublic

Tokens
"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

Type
Design

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
William Reynish (billreynish) changed Type from Bug to Design.Mar 26 2019, 3:10 PM
William Reynish (billreynish) triaged this task as Normal priority.
  1. 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:

Committed rBee0d8426ab6 to use dynamic size for the operator settings region. From my tests this actually works totally fine.

I'm not sure if this is the right place, but since one or two days ago, the "recents" tab is collabsed.

I use recent almost every time I open the file browser. So now I have to click twice every time.
It doesn't seem that the layout is saved when I expand the recent tab.

It's a small thing, but what it's worth I find the 'parent directory' item (...) really handy for navigating : no need to move the cursor over the address field, it's right there... I had this thingy on my Fedora's file browser (I think it might have been Dolphin...) not so long ago - any plans to replace it with clickable breadcrumbs, or some other contraption...?

Re: .. to go up a directly.

We are still emulating Windows 3.1 here, which is... yikes.

This is used by github/gitlab/bitbucket, while these are not file selectors, the .. convention is still in use in other modern UI's.

No strong opinion here though.

Current state of the implementation looks like this:


I'd say it's close to being ready. No bigger TODOs are left on my list.

Regarding .. item:
In the screenshot you can see that this item is close to the navigation buttons now, which also contain a 'up' button. I'm not too worried about exposing the .. convention (even if you don't know what it means, it's easy to figure out), it's that having the same item displayed slightly different so close to each other is bad redundancy. For the impatient ones (like me), there's the P shortcut triggering the same action.

Current state of the implementation looks like this:

The new file browser works as a floating window now? If yes, that's great. 👌

@ThinkingPolygons (ThinkingPolygons) Yes, in the branch it opens as a new window.

IMO we should make this a single preference for all temp windows (render, prefs, file browser) to open as a window or replacing the UI.

@Julian Eisel (Severin): Re. the branch, this is coming along well. Before we could merge it with master, we'd need to address a few things:

  • The 'active' button has lost the blue indicator, so you know what happens when you press Return
  • The Open/Cancel buttons in bottom right should have a fixed size, as in master. Otherwise they will scale and you cannot read the text.
  • The Open/Cancel buttons in your branch are reversed, so the bottom rightmost item is Cancel. Since your eye is then drawn to this as the main action button, I think they should be flipped. Alternatively we can keep them swapped for Windows only.
  • We should allow for clicking the column headers to sort ascensing vs descensing.
  • We should merge Date and Time columns, as you cannot sort by Time anyway. Currently it seems like the column header button doesn't work.
  • We should clean up the hidden old header
  • Still think we should remove the '..' buttons, as modern file browsers and other apps don't do this. We have an 'Up' button right above anyway, making it redundant.
  • Display Size should not truncate text inside the columns. This should only affect icon view. Text should truncate when there is not enough space, not at fixed arbitrary lengths
  • Icons for column view and list view are swapped
  • Search (and maybe also Display Mode) should be a top-level item, otherwise it is very impractical to use. To make space we can make this area region span the entire width.
  • Search should also work, even if you don't have Filter enabled. We made the same change for the Outliner.
  • Filter Popover is missing the triangle
  • In list view, it would be very nice to support shift-clicking to select in-between, ctrl to extend selections. (According to @Nathan Craddock (Zachman), code cannot be shared from the Outliner for this, because it has to work a bit differently)

I'd vote to keep .. for parent directory. I understand the reasons for removal, it is a dying trend from an ancient era, frequently absent in modern UIs, but it is very convenient and fast to use.
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.

Even modern breadcrumbs ()which I totally approve of and would make a very fine addition to Blender file browser) don't really replace it, because you have to hunt around for the parent directory in the list, and it's place shifts with string length.

Adding more options to the preferences window is generally frowned upon here, for fear of feature creep and "butonitis", but I'd see this as a worthy entry.

  • In list view, it would be very nice to support shift-clicking to select in-between, ctrl to extend selections. (According to @Nathan Craddock (Zachman), code cannot be shared from the Outliner for this, because it has to work a bit differently)

The only code I could see being shared is the preconditions for range select, namely:

  • The active item is not selected
  • No item has been activated
  • Active item is selected and under the cursor

In these cases, a range select does not occur and a single item is activated. This behavior could possibly be generalized, but I think it would be more trouble than it's worth. I could be wrong though :)

In list view, it would be very nice to support shift-clicking to select in-between, ctrl to extend selections.

This already works. Shift selecting extends, Shift + Ctrl fills. I guess the extra Shift is needed because Ctrl only is used for renaming. I guess we could check if there's already a file selected as better differentiation.
All in all the selection could use some rework. E.g. you still need to use RMB to select folders. Can do that after this redesign.

I vote for keeping ".." at least until (if) we get an active breadcrumb.

My wish list would include having "Volumes", "System", and "Favorites" in one single list, with the items in that same order. There's really no need to keep them separate and it would be so much more convenient to have them together.

There is another thing I'd love changed,. The items in the "System" list are each added to the list as only a path (fsmenu_insert_entry). It would be so much better if they used both a path and a named descriptor to show in the list. Ideally it would be those and an icon_id so we could show different icons for different types of paths (desktop versus documents). But just having the name separate means that "Desktop" could be a translated word as these thing don't always align. Someone's Documents folder could the root of network drive for example, but we'd still want to show it as "Documents" in the list. Or "Meine Dokumente" if in German.

The operator settings on the bottom left sometimes contain only a few items, but particularly for exporting, they have the potential to contain dozens of different settings. We often see these bunched up into a tiny area, with its own tabbed interface even. This is not good. Settings should be presented to the user proudly and be visible at a glance.

I suggest moving operator settings either to a column of its very own on the right (which would correspond with Blender's current convention to have various settings in a column on the right in its various editors), or to follow OS convention and have them in a horizontal area between the file list and the execute button.

The operator settings on the bottom left sometimes contain only a few items, but particularly for exporting, they have the potential to contain dozens of different settings. We often see these bunched up into a tiny area, with its own tabbed interface even. This is not good. Settings should be presented to the user proudly and be visible at a glance.
I suggest moving operator settings either to a column of its very own on the right (which would correspond with Blender's current convention to have various settings in a column on the right in its various editors),

Yes we could do that. Only issue with that is that in some cases there are only one or two controls, in which case that looks quite silly. But it may be ok to do that anyway.

or to follow OS convention and have them in a horizontal area between the file list and the execute button.

There's no great way to fit loads of controls this way that I can think of. I tried playing with this idea several times, but could never find an acceptable way to show all the controls we have for our importers and exporters.

Just to keep you updated on design discussions with @Julian Eisel (Severin), here are some updated UI bits and pieces:

File Browser top bar:


Search is back, but separated from Filter. Display and Filter are split into two different popovers.

Display and Filter popovers open:

We can make the Display popover only display options relevant to the current display mode:

Concerning that last screenshot, I'd like to suggest making the filter toggle a button of its own, with an arrow for expanding the popover, similar to how overlays and shading popovers work. Simply toggling the filtering is then more straightforward and it doesn't take much more space.

In list view, it would be very nice to support shift-clicking to select in-between, ctrl to extend selections.

This already works. Shift selecting extends, Shift + Ctrl fills. I guess the extra Shift is needed because Ctrl only is used for renaming. I guess we could check if there's already a file selected as better differentiation.

Nice! We just need to re-configure the keymap then, which is easy.

Current keymap:

Shift: Extend/toggle selection
Ctrl-Shift: Extend and select in-between
Ctrl: Rename

This should be changed to:

Shift: Extend and select in-between
Ctrl: Extend/toggle selection

This change would make it consistent with the Outliner branch

Rename we can add to a contextual menu instead. We *could* also keep a different way to do it, such as Ctrl-Shift click.

Current progress, in the branch:

It uses standard hotkeys so you can hold Shift and press other items, and it will fill the selection:

Popovers:

Right-click Context menu:

Todo:

  • The Open/Cancel buttons in bottom right should have a fixed size, as in master. Otherwise they will scale and you cannot read the text.
  • Still think we should remove the '..' buttons, as modern file browsers and other apps don't do this. We have an 'Up' button right above anyway, making it redundant. Also, it doesn't make a lot of sense with the keymap changes, as you have to double-click to use it.
  • Search should also work, even if you don't have Filter enabled. We made the same change for the Outliner.

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.

Column View (Miller Columns)
A NextStep-style column view that allows users to traverse the file system hierarchy. Anyone who has used a system like this knows how simple and nice a way this is to navigate a hierarchy.

Better workflow for import/export
Currently you have to select the file type ahead of time. We could make it so the importer changes depending on the file type you select. So, if you select an obj-file, you see the settings related to OBJs, and importing will then use the OBJ importer.

This is much cleaner, and nicer, because you don't have to decide ahead of time which formats you wish to import. Same could be done for exporting also.

Operator settings placement
Currently we place the operator settings in the bottom left as a sub-region of the source list.

This is not always super nice, as it covers the source list, and is also a bit inconsistent.

Here are some alternatives I could think of:

Current placement:


Doesn't really eat any space from the files region, but does overlap with the source list

Sidebar:


This is nice for importers & exporters with loads of settings in particular. We could use actual panels here, and it's a bit more consistent to use a sidebar.

Downside is that it takes space from the file list, and also that it's wasteful for cases where we only have one or two options.

Probably we would need to ad a prominent button to show/hide the settings.

Along bottom;


This is the most standard solution. If we added the settings here, we's probably need a visible toggle to show/hide this.

The difficulty is displaying lots of options here. We could use multiple columns, but it is harder to scale.

i got a question, it might be out of the scope of this task but just wondering about selecting files by typing the first letter like OS file browser? i know blender have few keys mapped to some functions but do people really use them that much?
there aren't that many and could easily be freed by adding modifier keys or just putting some in the context menu...i would argue that's would be much better.

@Zino Guerr (Zino) Yes that would be nice, and in fact the shortcuts thing isn't even an issue, we can simply use modifier keys for those.

The main issue is just that it needs development, but it's a good suggestion.

@William Reynish (billreynish) that's great to hear, hopefully in the future then .

One important issue that should be resolved along with this overhaul us that currently, File Explorer fills the name text field with the folder name if you click on a folder. This issue is not visible in default Blender's keymap configuration, as it opens folders on "Press" action, but when the keymap is changed to more OS standard Double-Click to open folders, the first click fills the name field with the name of the folder. The name field fill should be ignored when clicking folders, and only used when clicking files. Currently, I am unable to make the autofilled name stay in the name field if I want to browse to a different folder.

@Ludvik Koutny (rawalanche) in this branch, we use click to select an double-click to open. This will become the default behavior, so if there are any issues with this, it will have to be solved.

@Ludvik Koutny (rawalanche) in this branch, we use click to select an double-click to open. This will become the default behavior, so if there are any issues with this, it will have to be solved.

Yep, there is, this one:

So I guess it should be added to the list :)

Current progress:

Todo:

  • Cancel/Execute should not scale proportionally to the area region
  • Probably we should make a single preference for all temp windows to open in a window or replace current UI.
  • For HiDPI display, we ideally actually need 2x larger icons for the data icons. We could auto-generate higher res ones from our SVG.

Icons needed:

  • Desktop
  • System
  • Zip file
  • Network Drive
  • External Drive

Large icons:

  • Drive
  • Network Drive
  • External Drive

Looks great. Is it possible to include a zip filter(+icon)? This would be very useful when installing zipped add-ons.

@Peter Fog (tintwotin) : Is it possible to include a zip filter(+icon)? This would be very useful when installing zipped add-ons.

I think we'd need a new icon to represent compressed files. Good idea. We could use something like ICON_UGLYPACKAGE in the mean time.

I would like to see more files with icons, even some that blender does not seem to directly use, since we can't always guess what type of files might be used by an addon. Things like ICON_CONSOLE for .bat and .cmd. Maybe ICON_CURVE_DATA for svg files.

Right now FILE_TYPE_BTX, FILE_TYPE_COLLADA, FILE_TYPE_ALEMBIC are all using file type icon of ICON_FILE_BLANK. But this looks like a little document and so looks funny inside a larger document. Might be nice to use something like ICON_FILE_3D for some of these instead. Maybe FILE_CACHE or FILE_VOLUME for some, etc. Would like to see other image files using ICON_IMAGE too, like Gimp xcf files.

Looking at the capture above while appending from a blend file it looks like we need to hook up ICON_WORKSPACE to workspaces.

Drive; External Drive; Network Drive; Desktop; Zip File; System:

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"

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

It seems like the file browser interface could be a good candidate for using the system's file browser interface. Then, as the operating system is updated, Blender would have a file selection interface that matches what other applications are using. So the user wouldn't need to learn how Blender's file browser interface works. Also, lots of little pieces of functionality would be build for Blender for free, like proper file icons, search, animations, etc.

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?