Screen Area Editor Tabs #117954
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
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
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
Viewport & EEVEE
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Asset Browser Project
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
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
Module
Viewport & EEVEE
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Severity
High
Severity
Low
Severity
Normal
Severity
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
5 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#117954
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
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?
We have talked about this for a while so I wanted to write down some of my thoughts and results of experimentation regarding this.
Currently our Editors and the Areas they inhabit can be thought of as one and the same. We change Editors, and we split, join, and close them. These are separate things under the hood, but since we only ever see one active editor per area there is no real user distinction. Having editor tabs in areas is not a huge change for our underlying code, but it would be a large change in how users interact with them. There are many advantages, but these don't appear to be possible without user interaction disruption.
The Problem
Lets consider the following wireframe of a tabbed area.
The function of the editor tabs within the area seems to make intuitive sense. We have two tabs with one obviously active. It makes sense that the "plus" will add another tab, and closing a tab with the "X" is something we see all the time. Clicking the little square would allow you to change this editor to some other type.
But this runs into trouble when we start adding our current area split and joining using the corner action zones. What does it mean to split this area? Would you instead want to split an editor? If splitting the area, would you end up with two areas, each with the same two editors? If the area contained many editors then that would require a lot of cleanup afterward.
Similarly what does it mean to join that active editor to some neighboring editor? That can't happen without disrupting other tabs. Does this mean we can't split or join editors, but can only do so for areas? That can make some sense to us, being used to our current area maintenance, but is a more difficult thing to communicate to users there would now be a difference in acting on editors versus the areas they are in.
Consider the relatively simple problem of the placement of our corner action zones. At the bottom-left and bottom-right they would be inside the editor bounds even though they would act on the area. And it would create a mess to have both an area outline and editor outline in order to differentiate between those bounds. Something that is already obscure, hidden, and difficult for new users becomes even more so.
The Solution
The only solution I have found is to replace our current corner action zone area functions at the same time as (or before) changing to a tabbed interface. This involves embracing the tabbed interface itself, by using tab docking as the primary means of area maintenance and removal of the corner zones entirely.
The user disruption comes from the difference in how these two methods deal with the same problems. Lets consider the following, changing from the vertical arrangement of two areas on the left to the horizontal arrangement on the right:
Currently you have to formulate a multi-step plan based on what your final objective is. You start from "I want this to be there instead" and have to think of ways of making that possible. In this example it would probably involve splitting each of the two areas and then joining the resulting top and bottom pairs, with those the joins moving in opposite directions. So your thought that "I want this to be there instead" becomes a list of four destructive operations to accomplish what is a simple move.
But this sort of operation is easy and intuitive with docking. The following shows this operation with PR #104665. You simply drag that thing you want to move to where you want it to be:
With a tabbed interface we are moving something that is unambiguously singular among areas that can contain multiple. This means that dragging an editor tab into the body of a different area has to split that area.
Docking Rules
Dragging an editor tab within a row of tabs (the "tab well") in its same area reorders the tabs.
Dragging an editor tab from one area onto the tab row of another area moves the editor. It creates a new tab in the destination and removes a tab in the source area. If there is only one editor in the source area then that area also closes, and is subsumed by neighboring areas. Clicking on a tab name to start this process should make the editor active in its area, but dropping it into a different area should not activate it there.
Dragging an editor tab to another area within the body (so not to the tab row) will split the area and move the editor to it. Where this split occurs depends on where it is dropped, similar to what we see in #104665. If you drag to the left side of an area that contains three tabs you will end up with a new area on the left containing the dragged editor only, while the three other editors are in an area to the right.
I should be able to extend the above in interesting ways. For example if the drop target is near an editor edge it could do a docking join with the neighboring area. Under the hood a splitting of both areas followed by joins, so you end up with a new area that contains space from both.
Dragging an editor tab outside of the Blender window entirely would create a new window
What happens to "split"? Dragging an editor tab within its own area would work exactly the same as dragging to any other area. The area would split in two and you get a new editor alone in an area comprising a portion of the original. Note that although this behavior might seem close to our current behavior it actually feels a bit "reversed". Not that either way is right or wrong, but the two methods feel opposite. This proposal keeps consistency with all the other drag operations, but would need adjustment for those used to the current splitting.
How about "Join"? This is where this change of paradigm becomes most apparent. Like the "move" illustrated above, our current "join" is an odd thing. It is an "I want to remove this area by making this one take up its space" that was born out of our inability to simply close an area. But we have had "close" for a while now, just not surfaced to be very visible. A very visible "close", combined with the ability to move editors anywhere you want - including spanning multiple existing areas - is all we need. This should all make intuitive sense as long as these potential operations are previewed to the user before committing. So while dragging you see potential docking targets highlighted that you can choose from.
Context Menus
The context menu of an editor tab could include
The context menu for the empty portion of the tab well:
Tab Names
We should provide a way to create good default tab names for the editors that include subtypes and modes. It might be nice to allow custom naming of tabs. Especially since we can allow multiple copies of the same editor in the same area, for example one View3D in Object mode and another in Edit mode.
Optional Behavior
Showing tabs requires some vertical space. It is possible to only show a tab row when there is more than one tab, but this does cause a large change when we go from one tab to two. It should be possible to allow users to select a user preference for this:
The above is similar to what we saw with browsers when they first brought in tabs. The nice thing about such an "Auto" setting is that Blender could look roughly the same as now by default, with each editor taking up the exact same vertical space and not showing any tabs. And it would only show a tab well when there are two or more. This would need some thought though to support enough features when there is only one editor, so probably a visible "+" at header left and a visible "X" at header right. This makes tabs just discoverable enough without being intrusive or stealing screen space from those who don't want them. One downside being the large visual change when changing from a single editor to two tabs, but this is addressed by selecting the "Always" preference (which is what we eventually got used to with browsers).
Misc
It might be nice to support a "dirty" (*) indicator for tab names, for Text Editor, Image Editor, etc.
Docking is something I can't wait for, and as its shown in your PR is perfect imo, but I'm not sure about tabs. While in general they're great, and its Blenders quirk to not have them basically, because everything else does, there is screen real estate problem in Blender that needs to be considered.
Editor headers contain a LOT of information, much more than in any other software. Adding tabs would mean adding new row of header, because you cant fit that now, what we have already doesnt fit. And by adding second row of header into every editor you're really shrinking usable screen-space by a lot.
In other softwares that is not the problem because headers usually are really thin text of menus, and occasionally couple of buttons, but nothing else. Blender, on the other hand, has data-block selectors with long names, editor mode toggles, filters and etc. And headers are big too.
On one hand, this might reduce number of editors per Workspace, and save space that way, but in other examples having two separate rows of header (one in 3D viewport, one in Timeline) is more limiting.
I still think we can (and should do) docking separately first. Its (possible) use later when dragging tabs was the reason that the docking PR settled on using a simple drag rather than needing any modifiers held down for any operations.
For sure. But in a way tabs allows reusing the same real estate by its overlapping nature.
When we first started talking about this I had high hopes that there could be a solution where an area with a single editor could be shown and operate as it does today, and only take more vertical space if more than one tab. Unfortunately, as described above, I'm not seeing that a hybrid could work.
A possible way to do both would be to change area maintenance stuff first. So corner action zones are all removed, except for one at top-left corner and it gets a visible icon that signifies movement, like the grabber dots we use for panels. Then do all operations using docking as described above. Basically the one editor grabber would behave like a single tab.
Doing that before supporting a tab interface means that an area with a single editor could look like it does now with no extra vertical space. But then add a second editor and it then shows tabs and you do the docking by dragging the tabs.
Harley Acheson referenced this issue2024-04-28 03:11:47 +02:00
Example of tab progression.
Top Image: with tabs option set to "Never" the UI could look identical to current code. Middle: tab option set to "auto" and with only one editor in the area - just the addition of a "+" and vertical rule. Bottom: With multiple tabbed editors in the area:
Notes.
The rounded edge of the editor border is kept at the same location, with tabs above that. So tabs appear to be inhabiting the border/gutter space.
When transitioning from a single editor to multiple tabs the current editor icon moves up while keeping the same horizontal location, to help reenforce that this is one thing moving and not something being replaced.
In order for the active tab to include the dropdown for selecting different editors, while inactive editors do not, this means the inactive ones are off-center. Otherwise the icon will move when clicked on. I think I'd make the tabs even a bit wider to increase hit space. Perhaps they could have both a horizontal minimum and maximum and be dynamic.
This example shows the active tab as lighter, attached to the editor body, and slightly proud of the others. The small difference in height should give some hover feedback without animation required. But we don't have height differences in our current tabs.
Is it possible to round the bottom part of the active tab towards the header? Maybe it helps stand out the active one.
If there is enough space maybe we can add left padding for tab icons to appear centered, at the expense of visible tabs if the editor is too narrow though. I don't have strong feelings either way.
That does look nice. We can almost get that affect now as we do similar with tool headers, although without the outline.
Oh, just add padding on the left equal to the size taken by the dropdown on the right. The only thing that looks a bit funny is that it makes the inactive tabs centered but the active one less so:
If the tab widths changed between active or not then they'd move.
Edit: Maybe if we don't show the dropdown arrow unless your mouse is hovering the tab? That is a bit weird for pen/tablet users though.
Edit2: My captures here don't include the "x" we need to close tabs. :-(
Indeed it now looks funky in a different way
True, showing on hover only would be nice for mouse users, not so much for pen/tablet.
Following that principle maybe we should also always show the close X as well then. Maybe if it replaces the dropdown arrow on the inactive tabs it will somewhat balance it out visually?
Edit: Here is a crude mockup
Maybe it all needs a but of padding, but I think I like the former "off-centered" version better.
Wouldn't be better to have the option of closing the tab at a right click/long press menu? This way, you don't risk closing the tab accidentally.
Oh that is a good point. I was thinking about browser tabs, but we probably don't need/want them to be that easy to close. Still needs something not too hidden, works with pens, and touch too though.
Maybe a "kebab" (vertical ellipsis) menu? It would also add a zone to grab the tab more easily, imo.
Not entirely sure what practical problem tabs solution is supposed to solve.
Such a solution better fits something like GIMP, where UI is solved as lots of pallets with different local specific purposes.
In blender all the editors are pretty solid, so you are not expected to switch between then or rearrange them too often, even using layout tabs concept that was supposed to bring a bit more dynamics into editors handling via providing quickly accessible personalization is easily avoidable (it saves something like milliseconds per hours in total in comparison to list solution, most of the time they idli occupy the screen space).
As a result editor tabs will mostly steal precious screen space most of the time in my opinion.
Blender editors aren't that different from palettes in Gimp/Krita, the bigger difference I think, is that Blender treats canvas-like "main" editing areas like the 3D View or an Image Editor like any other more "dependent" editor (like the Properties Window or an Outliner, while image editors have a more explicit fixed "main" area that is the canvas.
I'm also on the fence about the usability of tabs, technically workspaces should already solve the problem of quickly switching between editors in a click. Just like you click an editor tab you could click an equivalent workspace with the same layout.
However workspaces are a much more "heavy weight" solution, they can have their own enabled or disabled addons, different settings and switching can be slow.
The main issue would be that switching workspaces can be disorienting. Since there is no relationship between same editors across different workspaces a 3D View may have a different shading mode, different editing mode, different point of view, even different object visibility. You can easily get totally lost and break your focus.
Switching a tab will be a lot less disruptive, and can help people with small displays or low resolution monitors overlap editors that aren't frequently used simultaneously. Say have a tall narrow editor along the right edge of the screen that can switch between an Outliner and a Properties Window, or have a wide and short editor along the bottom that has tabs for both a Timeline and a Graph Editor.
I'd definitely prefer editor syncing between workspaces, this will also complicate Python API access to layouts and editors, but I think there are people out there that could benefit from this.
As this proposal states, and my mockups show, this is optional behavior that does not steal any precious screen space if you don't actively add tabs to an area.
Yes, it just gives the option of using them in a different way. Want to have an editor quickly available yet take up no screen space, then add it as a tab. Want to operate exactly as you do now? That remains an option. Want to work with just a single huge area, but have every other editor as a tab you can get to instantly? That is an option too.
Blender is flexible and this would just add more flexibility. It doesn't force you to work one way or another but gives new options.
Thats pretty massive functional difference.
Well, for small displays or low resolution monitors current solution fits the best since tabs handling rows takes space quite expensively. Tabs solution is definitely for a large screens.
Yes that was one of the functional flaws of workspaces - "where am I?" problem which occurs during switching workspaces, especially when you have to work with files made by the other person (for example, we succeed to resolve at least different point of 3d view problem with a syncronizing addon), but I am not sure what is the proposed tabs-based solution to that. Like having the need for 5 simultaneous visually equal tabs of a same editor just for a different visual setups sounds more like a design flaw of an editor.
After all, any additional flexibility (for example, in personalization) comes at the cost of a more cumbersome manageability (for example, during collaboration)
I just want to make a friendly reminder that in Blender (unlike GIMP or Krita) the UI layout is transferrable between users via project files.