Screen Area Editor Tabs #117954

New Issue

Harley Acheson · 2024-02-07T18:17:58+01:00

Harley Acheson commented

2024-02-07 18:17:58 +01:00

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

Rename
Close
Close all but this (or "Close other tabs"?)
Close tabs to the right
Duplicate Tab
Float into New window
Maximize

The context menu for the empty portion of the tab well:

Close all
Reopen closed tab
Float into New window
Maximize

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:

Auto: Show tabs if needed (default)
Always: Show even single editors in tabs
Never: never show tabs

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.

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. ![image](/attachments/41d7b264-4d82-4781-8757-284ee4fe4e48) 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: ![image](/attachments/b235cdfa-d8e2-4119-831f-93be6388b1cb) 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: ![image](/attachments/d94d154c-9bd7-487d-90f6-3a6c9e52aa8f) 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. ![image](/attachments/0adf6bbf-546f-4a37-8ca0-a82d6a0eda99) 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. ![image](/attachments/d031dd3e-1a64-4f96-918d-5688e37eda10) 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. ![image](/attachments/29cc9400-4aed-4531-bfbc-07d6fa3d767e) 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. ![image](/attachments/df7d5805-e02a-48b4-bde7-5f42babbdec4) Dragging an editor tab outside of the Blender window entirely would create a new window ![image](/attachments/d9c1c195-1cb0-496b-97d8-3381954c7138) 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. ![image](/attachments/d6d13b6e-12f6-4650-95a9-c97589884b19) 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 - Rename - Close - Close all but this (or "Close other tabs"?) - Close tabs to the right - Duplicate Tab - Float into New window - Maximize The context menu for the empty portion of the tab well: - Close all - Reopen closed tab - Float into New window - Maximize ### 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: - Auto: Show tabs if needed (default) - Always: Show even single editors in tabs - Never: never show tabs 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.

image.png

8.3 KiB

image.png

3.7 KiB

image.png

6.3 KiB

image.png

8.2 KiB

image.png

3.4 KiB

image.png

3.0 KiB

image.png

8.3 KiB

image.png

4.7 KiB

DockingSwap.gif

722 KiB

image.png

10 KiB

image.png

3.9 KiB

👍 3 👀 3 ❤️ 5

Harley Acheson added the

Type

Design

label 2024-02-07 18:17:58 +01:00

Harley Acheson added this to the User Interface project 2024-02-07 18:18:01 +01:00

Nika Kutsniashvili commented

2024-02-07 20:26:41 +01:00

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.

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.

Harley Acheson commented

2024-02-07 21:06:27 +01:00

Docking is something I can't wait for, and as its shown in your PR is perfect imo...

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.

there is screen real estate problem in Blender that needs to be considered.

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.

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.

> Docking is something I can't wait for, and as its shown in your PR is perfect imo... 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. > there is screen real estate problem in Blender that needs to be considered. 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. > > 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.

Harley Acheson referenced this issue

2024-03-01 00:06:42 +01:00

Roadmap #118940

Harley Acheson referenced this issue

2024-04-28 03:11:47 +02:00

UI: Screen Area Docking #104665

Sign in to join this conversation.