File Browser options minor UI improvements #37982
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
15 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#37982
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?
I had a few ideas on some re-organization for the file browser options Here is the proposed changes (just the section highlighted in green)
Right now, every section is separated with panels. Is this needed? I am curious to see what other people's file browser looks like. Does it really get that long for some people? Panels create a lot of stuff ( lines, corner sorting thing, triangle), so I thought removing them would make it a little cleaner. People can always scroll if they happen to have a ton of stuff. Scrolling is easier than clicking in my opinion.
The system and system bookmarks list can't be edited (to my knowledge). Combined them to show their relationship better. Moved section operations to the bottom and made them a little more descriptive.
The goal is just to simplify this a little. Nothing too major.
Thoughts?
Changed status to: 'Open'
Added subscriber: @scottyp
Added subscribers: @brecht, @billrey, @JonathanWilliamson
I don't agree that the panels are much an issue. In fact, it may often be useful to hide, say, the System drives list. If everything was all in one panel, you woudn't be able to do that. Some Import/Export formats also display a rather long list of settings in the bottom 'operator' panel. You might want to hide other panels to give this panel space.
There are things we could do to make panels nicer and clearer throughout Blender, but IMO that's a separate issue.
However, I think there are things we could do to make the file browser clearer. For example. the huge buttons to add bookmarks is not needed, and the fact that system bookmarks are separate from Blender-bookmarks is also confusing.
Also, the fact that the Open command is in the upper right is not that great. There's a reason logos are often in the bottom right: it mirrors how we read (from top left to bottom right) It also matches the workflow to have it in the bottom. You first navigate to the file, then you press Open.
Here's a quick sketch of simpler buttons for adding bookmarks, plus the Open button in bottom right:
@billrey Some good points.
Some of the exports have pretty long export options. I didn't realize they got that long.
I do like the Open and cancel buttons on the bottom with the file name. I wonder why they ended up on the top? Apple, Windows, and Linux OS all seem to have those actions on the bottom. System and system bookmarks aren't manageable (add, delete), so maybe that is why they are separate from Blender bookmarks? I like moving the file path operations ( back, forward, up, refresh) closer to the filepath field. It shows their relationship better. Moving all of the filters and create directory closer to the files also seems to strengthen the relationship as to what you are filtering (pretty much moving everything from the header).
@billrey Could you provide a more fleshed out mockup with your ideas? My task just outlines one section, so maybe it would be good to close out this task and create a new one dealing with the entire file browser. I think just doing a little re-arrangement is all this area needs.
Added subscriber: @PauloJoseOliveiraAmaro
Maybe it's helpful to update the lists layout to the new lists layout of Blender (i.e. used in UV map list), to include the max height delimiter and the filter options, putting the buttons aside the list.
Or, as suggested by @billrey, also to merge System and System Bookmarks painels:
@PauloJoseOliveiraAmaro:
Yes I think it makes sense to use the re-use the same list UI here. It's also a good idea to combine System and System bookmarks. Conceptually they are the same thing - system paths.
Added subscriber: @simonrepp
Just a quick interjection from my side: @PauloJoseOliveiraAmaro's suggestion to update the lists to the new list style could possibly already be happening in the course of my work on #37881 - File Browser renaming of bookmarks . I'm still mostly reading through the code and assessing the situation, but so far my understanding is that the lists in the file browser are all coded in pure C and all fancy, new lists that allow renaming and such utilize the bpy.types.UIList python template. Thus a rewrite of the file browser sidebar layout in python might be a necessary and/or favorable decision for the sake of a good and DRY implementation.
I will further follow this conversation before going into any actual changes, and in any case I will need the python rewrite plan approved by a module owner, not sure about all the implications.
Aside that I have a question on the "System Bookmarks" - What data does this feed on if it's not user editable inside Blender?
I somehow assumed it would maybe import data from the OS-native filebrowser, but at least on my Ubuntu installation I don't see any resemblance between what "System Bookmarks" my (Nautilus) file browser shows, and what's showing inside the Blender File Browser.
@simonrepp: Yes, the System Bookmarks is meant to reflect the bookmarks in the system-native file browser. It works on the Mac and afaik also on Windows, so that any folder added to the sidebar in Finder (or Explorer) also appears in Blender's System Bookmarks list.
Don't know about Nautilus and all the flavors of Linux and their respective file browsers. Perhaps some of these are not supported? In Linux you have loads of file browsers, and supporting all of them is likely more of a hassle.
The issue with the System Bookmarks is that it adds an extra category that's not needed. You end up having too many panels of bookmarks inside Blender. I think it's better to have System (drives and system bookmarks), Bookmarks (Blender bookmarks) and Recent.
@billrey I think those are mostly good changes but I would be hesitant to merge the System Bookmarks and Bookmarks. Bookmarks serve as a way to add a custom shortcuts to often used areas and as such need to be editable by the user (from within Blender). You can't do this with the System Bookmarks but you can with regular Bookmarks. And so if you were to merge them then it would be a confusing mix of editable and non-editable.
That being said, I agree that it seems unnecessary to have both. I would be more inclined to simply remove System Bookmarks, and then add a little startup script that detects the OS level bookmarks and creates them in Blender the first time Blender is started (if the user does not have existing preferences).
@JonathanWilliamson: I don't think we should merge Bookmarks with System Bookmarks. I think we should merge System with System bookmarks. :) That way we have a clear separation between System stuff and Blender user stuff.
Here are some updated mockups for improved File Browser design.
The issues:
Suggested outline:
With Graphics:
file browser options minor UI improvementsto File Browser options minor UI improvements@billrey nice mockups. This looks nice! I agree with your points in yellow with the first attachment. This is the direction I would go as well.
There are a few options that I don't see in the mockup (incremental savings -- +/- by the file name). I don't see the "show hidden" option, but that seems like it should be a filter grouped with the other ones.
I think opening this in a new window is a good idea. With the current implementation, having the Info bar on top doesn't really help at all since they aren't relevant. The whole "back to previous" doesn't seem to add any value (maybe it did at some time).
@scottyp:
Yes, I think the Filter options (+ Show Hidden) could appear in a second row when Filter is enabled, like so:
The +/- buttons should only appear when saving files I think. Doesn't really make sense when opening I don't think?
When saving, it could look like this:
Nice work @billrey. I think each of your points, in particular opening in a new window and the reading direction are spot on. I suspect "Opening in a new window" will present some extra problems to resolve (such as auto closing the window) but I can't imagine they'd be too much.
If you're willing, would you care to take your mockups and apply them to Export as well? Exporting will have some additional options applicable to the chosen file format. A good test case would be Collada. Currently these options show in the bottom left panel, but this breaks reading direction.
I actually quite like the fact that Blender opens the file browser full screen and not in a smaller window. When you've got directories with many files or .blend files with many datablocks it's quicker to browse and find the right files. With a smaller window you also get less space for operator properties and more scrolling there.
I know the standard is to have these smaller modal dialogs, but I feel that for 'serious work' what Blender does is better than these. With a big file browser and the file name at the bottom the design doesn't work so well, but I would rather solve that another way than adding more scrolling.
I will add that while I think opening in a new window is a better idea, I have never had a problem with it opening fullscreen in the current window. The Info bar does add some confusion, but I think it's secondary to the other issues (such as overall organization and layout).
I agree that the modal window is a slightly better option since you don't have to worry about the info bar. It is one of the few instances when info bar isn't relevant to what you are doing (user preferences being the other). It isn't a major issue though. The non-overlapping aspect is a little cleaner with leaving it in its space. The file name on the bottom isn't that critical either. It is on the top on Mac OS, so it isn't that odd to have it there. I think as long as the filters and operations are in close proximity to the respective fields, that is most important.
I agree to @brecht. Full screen for open file window is a need when working with sequence strips, when you have to control the selection of a long image sequences. Not only Blender uses it but also another applications, like Adobe Lightroom. As was said, for serious work, it's very needed.
@brecht: Yes, it's true that we perhaps loose a bit of space this way. But you could still maximise the dialog if you want, so not sure it's really an issue?
Most Open/Save dialogs waste a lot of space at the bottom for options which makes the area. In Blender we place those objects in the list on the side which saves lots of space for files and folder, so we already have more space compared to most apps.
Alternatively, we could make the Open/Save/IO dialog be completely full screen. The Info header, and Editor Type drop down is confusing here. It makes the process unclear as there's no real separation between the Info bar and the rest of the UI. Aperture also uses a full screen browser. The way it works is that it animates in and out in a way that makes it clear that it's on a separate layer.
I still think a separate window would be clearer, because you can clearly see that it's a temporary dialog (the rest of the UI is seen below). At the moment that's not well communicated.
I don't think expecting users to maximize it is a good solution, many will not think of doing it because it's unusual. I also think we should do the better thing by default, to me there just doesn't seem to be enough space in such a small dialog, in your mockup the system folders are collapsed and many importers would only show a few buttons.
I agree the info header does not need to be there and certainly not editable, it should be properly modal.
We could open a file dialog that is almost the size of the window, with some 20 pixels padding on the sides to show the rest of the UI greyed out below it, so we have both a big dialog and show that it is above the rest of the UI. That can be in a separate window or something inside the same Blender window, as long as the rest is greyed out it should be clear.
@brecht: Agreed, makes sense, would be a great solution.
@JonathanWilliamson:
I didn't propose a difference to the way we display IO options, but we could make them more compact by using tabs, like so:
Added subscriber: @GregZaal
Created a proposal for improving the current bookmarks panel, allowing you to give each one a name (in the case of multiple folders with the same name) and move them up and down the list: http:wiki.blender.org/index.php/Dev:Ref/Proposals/UIFileBrowserBookmarks
Added subscriber: @Januz
@billrey - I am personally not in favor of having tabs by the options. Exporting options are usually done as a separate step in most applications. You pick your file to save as one step, click save/export, file browser disappears, then a modal window shows up up with additional options for exporting format.
@GregZaal - We also need the delete functionality by bookmarks. Is that what the red x is when editing. I am worried this proposal might make managing bookmarks too complex. Is managing bookmarks at this level something that most people need? If it is the minority, I would rather lean towards leaving it simple (unless maybe if there were more advanced context click options which don't exist now).
I modified @billrey mokup a little with a slightly varied bookmark management. The "X" by the Recent panel will be confusing for Windows users. That communicates "delete this panel" - since X's to the right of a header means close in Windows. Instead of clearing, could we make it consistent with the other bookmark removal and have an "X" by each option?
Deleting isn't a primary action with opening files, so I think making them more subtle would make the UI feel less cluttered. The icons could turn white when they are hovered over.
@scottyp Agreed. The red 'X' was for deletion, but that whole proposal is really just a big bandage. I'd much rather it be more hidden for advanced folk, such as ctrl+click or double click to rename, and a simple drag+drop to reorder.
Added subscriber: @ZsoltStefan
@billrey - good proposal, especially moving the selected file name and Cancel and OPEN to the bottom. And X-es as in the mockup from @scottpetrovic.
@brecht - I know what you mean, browsing through large directories of files is good with a fullscreen dialog. I would still rather have Open file and Save file in a separate window, like user preferences currently. I don't see why resizing a window is unusual, we don't need to assume that computer users don't understand resizing. For serious work it's just one click to maximise it. I resize open file dialogs in Windows regularly, the only problem is if it always reverts to the old small size, so we simply need to always store the last size and position of the window.
Added subscriber: @PawelLyczkowski-1
Added subscriber: @BartekMoniewski
Added subscriber: @lsscpp
Any chance to have a preview area in the file browser?
@lsscpp - that is a good idea, but that might not fit in with what this thread is about. That feature already kind of exists. If you are opening a file and go into grid view, it will show you a preview as the thumbnail. Is that good enough?
@brecht - Are we close enough with this direction that we can start doing changes? I think the direction we are heading is pretty good. I could try to start doing these code changes. Not sure exactly how to do it, but I can worry about that when I get in the code.
For the full screen vs. modal debate. It sounds like we need a lot of space. If someone clicks the "Open" button, that is what they want to do - so I think it is would be fine for it to take up the whole space to do what needs to be done. Maybe just update the info bar to take away some of the confusion.
Yep thumbnails are better than nothing, but often i feel the lack of a good (big) view of textures (Not to speak about the time needed to see all the thumbnails in a crowded folder.). So I have to reach the folder via system and search the images with an external app (a trivial viewer). Having a view that is fullsize and scrollable would be a gift. A thought this because Blender already has its own viewer
I am going to go MIA on this for a little while. I was starting to spend some time getting this all re-arranged in C (was struggling with externalizing everything Python). There is another open source project I that has my heart right now and need to switch gears to for a little bit (Krita).
Added subscriber: @mont29
Added subscriber: @Blendify
This may be a work around for this bug #42754
Will merge this task into #62971. No reason to keep both open at this point.
Closed as duplicate of #62971