File Browser UI #62971
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
35 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#62971
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This follows on from #37982 (all the way back in 2013!) which included several plans and UI designs for updating the File Browser layout and interface.
As discussed with @JulianEisel 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:
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:
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
Added subscriber: @WilliamReynish
#37982 was marked as duplicate of this issue
Added subscriber: @JulianEisel
Committed
ee0d8426abto use dynamic size for the operator settings region. From my tests this actually works totally fine.Added subscriber: @DanielPaul
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.
Added subscriber: @hadrien
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...?
Added subscriber: @ideasman42
Re:
..to go up a directly.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 {nav P} shortcut triggering the same action.Added subscriber: @ThinkingPolygons
The new file browser works as a floating window now? If yes, that's great. ?
Added subscriber: @natecraddock
@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.
@JulianEisel: Re. the branch, this is coming along well. Before we could merge it with master, we'd need to address a few things:
Added subscriber: @DuarteRamos
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.
The only code I could see being shared is the preconditions for range select, namely:
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 :)
This already works. {nav Shift} selecting extends, {nav Shift + Ctrl} fills. I guess the extra {nav Shift} is needed because {nav 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.
Added subscriber: @Harley
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.
Added subscriber: @MadMinstrel
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.
Added subscriber: @0o00o0oo
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.
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 @JulianEisel, here are some updated UI bits and pieces:
File Browser top bar:
{F7628093, size=full}
Search is back, but separated from Filter. Display and Filter are split into two different popovers.
Display and Filter popovers open:
{F7628097, size=full}
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.
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:
{F7633394, size=full}
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:
Added subscriber: @dark999
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.
Added subscriber: @Znio.G
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.
@Znio.G 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.
@WilliamReynish that's great to hear, hopefully in the future then .
Added subscriber: @Rawalanche
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.
@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:
2019-08-03 19-21-12.mov
So I guess it should be added to the list :)
Current progress:
{F7659491, size=full}
Todo:
Icons needed:
Large icons:
Added subscriber: @tintwotin
Looks great. 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.
Added subscriber: @jendrzych
Drive; External Drive; Network Drive; Desktop; Zip File; System:
Added subscriber: @nokipaike
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"
Added subscriber: @lichtwerk
@nokipaike : you can already do this if you generate previews first, see https://docs.blender.org/manual/en/dev/files/blend/previews.html
Added subscriber: @brentcas
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.
Added subscriber: @brecht
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 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.
Added subscriber: @mont29
@WilliamReynish 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. :///
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?
Removed subscriber: @tintwotin
Added subscriber: @hjsrabi
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:
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):
Added subscribers: @scottyp, @ZsoltStefan, @Blendify, @simonrepp, @Januz, @BartekMoniewski, @PawelLyczkowski-1, @JonathanWilliamson, @PauloJoseOliveiraAmaro, @GregZaal, @billrey, @lsscpp
A note on the dots (..):
Here are the reasons you shouldn't remove the dots:
There's no harm in keeping them in addition to a button in the toolbar. A little bit of redundancy never hurt anyone.
Anyone who has ever used a command line will appreciate them
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.
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.
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.
Removed subscriber: @simonrepp
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.
Removed subscriber: @scottyp
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?
@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.
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.
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.
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.
Added subscriber: @voxel
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?
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.
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.
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...
@voxel
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:
Added subscriber: @tintwotin
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 {nav Okay} (or {nav 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.
Not sure which column width you mean?
These are bugs and should be fixed before merging.
Fixed mentioned bugs:
2356f60c62, 99acf30edd, aa0db0038e.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.
@Rawalanche absolutely. There's no reason for this. It's a holdover from when Blender used to have confirmation popups for everything.
@JulianEisel so you prefer to do this as part of the branch or separately?
I removed it last week, ea94cade29.
Thank you! :)
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.
Ahh, ok, too late. Could we get an informational popup like "Directory not found. Created."?
@ZsoltStefan 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.
The prompt popped up before you started typing the folder name, not after :)
Sorry, I misunderstood, was thinking of the popup when entering manual input in the file path.
Of course, this makes sense!
@JulianEisel 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)
Added subscriber: @Sergey
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.
Yes this was a bug, now fixed.
This should be fixed
It's certainly in there.
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.
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.
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.
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.
Yes, so that it will stay on top and not allow you to go back just by accidentally clicking outside the File Browser.
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
Yep, we discussed this. It's important to add this.
Exactly right, it's a preference, not a scene setting.
Any planned work on this topic?
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.
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.
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.
I find this OK as well.
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:
{F7716927, size=full}
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.
{F7717515 size =full}
Removed subscriber: @GregZaal
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.
Added subscriber: @ZedDB
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 elementsI'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:
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.
I think the changes here are fine, so no feedback here!
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:
What I like:
Neutral:
What I don't like or would change (minor points)
Really like the direction this took, congratulations, this is an improvement of what we had previously.
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: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
F2in 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
Removed subscriber: @JonathanWilliamson
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.
@ZsoltStefan Yes, the Options pane should be opened for image saving. Noted.
Added subscriber: @SecuoyaEx
+1 for renaming files to come back
Removed subscriber: @tintwotin
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:
Other things we should do - maybe less urgent but nice improvements:
@WilliamReynish or @JulianEisel, 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.
I think these must be solved for 2.81.
Further I think we should also:
..Added subscriber: @capnm
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.
Added subscriber: @Mets
+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.
@Rawalanche you can simply press P to go to the parent folder. This works for the default Blender keymap, just as it always has.
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.
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.
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.
I have been using that daily for quite a few years now across multiple alternative file browsers for windows like [FreeCommander ]], https:*www.xyplorer.com/ , [ https://github.com/tablacus/TablacusExplorer | 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:
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.
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.
Changed status from 'Open' to: 'Resolved'