Splitting and merging viewports is much harder to achieve in 2.8 #59856
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
9 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#59856
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?
Hi
I am finding that splitting and merging of viewports to be particularly much harder in 2.8 than the previous versions. Especially merging grabbing from the corner and pulling down ) most ofthe time ends up with splitting the windows further. I think that this is an isue of the grab/area area to be way too small to do this comfortably. This is expecially pain in the neck on laptop with with a touch pad. I have harder time with this when I am not using a Wacom pen. The precision required to get this going is a bit too demanding.\
Trying to get that "+" so one can do splits or merges takes minimum couple seconds for me. In 2.7 this si no issue because there is a visual (stacked diagonals) indication of where the mouse should press to initiate the action.
Just last night, I ended up with 10 unintended horizantal splits on my Laptop, and trying to merge all that back was even harder and painful.
Added subscriber: @kursadk
#60589 was marked as duplicate of this issue
Splitting and memrging viewports is much harder to achieve in 2.8to Splitting and merging viewports is much harder to achieve in 2.8Added subscribers: @brecht, @ZedDB
I think this is more of a feature request. @brecht is this anything we are planning to work on or is this more of a https://blender.community/c/rightclickselect thing?
Changed status from 'Open' to: 'Archived'
This was recently changed in D4033: Reduce Area Splitting Action Zone Size.
It's not really a bug, but if there are more users with this problem we can consider changing it again.
Added subscribers: @DanielPaul, @JacquesLucke, @WilliamReynish
These areas are really small for a frequently used UI element
Only some more pixels would make it perfect.
When the Editor Type Panel is centered above the toolpanel it would even look more symmetrical.
(Of course only when in single column)
@DanielPaul i think something like that would probably be fine.
@brecht ?
Added subscriber: @Harley
@Harley submitted patches for these recent changes, so maybe he wants to work on further changes here.
The wider clickable edges seems fine. The extra empty space everywhere is not ideal but I guess acceptable.
Maybe we should get rid of this dragging from 4 corners, and only allow dragging from the top right, with an icon and a bigger clickable area instead of this quite hidden behavior. Part of the reason accidents are more like is also that we changed from 2 to 4 corners, before it wasn't as likely to misclick diagonally
What I'd really like to do is discuss this a little bit. So I'd love someone to correct my following assumptions:
Step one: Make it so that the "move" zone does not bisect the splitter zones. The "resize area" zone is 3 pixels wide and is the full extent of every window edge. But that means that at a joint corner there is a move area between the splitter zones. So obviously splitting and joining cannot be done if your mouse is too close to the corner. This change would make it so that you couldn't resize an area at the corner, but I can't see that as an issue since the corners are for splitting/joining.
Step two: Increase UI_HEADER_OFFSET slightly, so moving the Editor-type menu to the right by a small amount. I can therefore make the splitter area slightly wider.
Step three: Increase the vertical size of the splitter azone. It is now square, but can be taller without interfering with anything.
Step four: Increase the width of the "resize area" zone. It is currently exactly the same as the visual gap between areas, which is 3 pixels. After step one we can increase this by one pixel on each side without interfering with anything. But that change from 3 to 5 will make resizing much easier using imprecise devices.
A rough visual of what I mean:
Note that I do not (currently) know how to achieve step one: giving precedence to the splitter over moving. Was looking at that this morning a bit...
And about the general behavior itself:
Right now we are using the drag direction in the azone to determine whether to do a split or merge. Because this area is so small there is no resting space in this action. This makes it really easy to do the wrong operation. We do immediatesplits, but only do a join after a confirmation. So the end result is that errors will almost always result in unintended splits.
By making the split zone much larger, and without the bisecting move zone, we might be able to allow for some resting space. So only start a split/merge operation if the mouse moves more than some delta.
@Harley This makes sense to me. And a nice idea to make the action zone take precedence over the resize zone in the corners.
@Harley Best solution so far. The resting zone does really not exist at the moment, you have to move immediately while clicking to define the direction.
It does seem like that, but isn't really the case once I dived into it. You actually do have a fairly wide resting area if you were to initially touch down in the dead center of the defined zone. But the closer to the edge of that zone (like closer to the corner, for example) the less dead space you have. This is because the action is initiated the very moment that your mouse leaves the zone you touched down in.
I have submitted a patch here:
https:*developer.blender.org/D4227
It makes it so that "resting space" is the same regardless of where you touch down. Basically you have to drag for half the width of the zone even if you touched down at the very edge of it.
It also makes it so that up/down/left/right drag must be a bit more precise, but still not very. With this patch dragging at a 45 degree angle will do nothing, instead of what it does now which is to incorrectly guess your intention half the time and give you an unwanted split. This should result in less accidental messes.
The patch also increases the zone by 50%. I have kept it the same width (the entire space between the edge and the change-editor menu) but have increased the height a bit. It feels a bit more like it properly takes up that corner. And does not interfere with other interface items as I had previously moved scrollbars and such away from the corners.
Give it a try (if you compile on your own) and let me know what you think...
Just to clarify my comment about limiting the allowed angles for drag. This patch will make it so that the drag illustrated below will be less likely to create a vertical split of the Properties menu, which is what it does now. The patch makes it so such a drag does nothing, rather than treat it as if you had dragged perfectly horizontally.
I am now testing a patch that pushes those corner action zones right into the corners, as I mentioned earlier. It does make it much easier to do these split/join operations when the two adjoining areas are not separated by the "move" area.
I'll wait until after my earlier patch is either accepted or rejected though as I am trying to keep these changes as atomic as possible.
Okay, the patch was accepted that added a (small) threshold of movement before action is taken, regardless of where in that corner zone you start at. It also makes the zone slightly taller.
And it restricts the angles of the drag so you have to be a more precise, which addresses the accidental split you can get as I illustrated above.
The next step is an optional patch I just submitted, which moves those corner zones right into the corners and so they are not bisected by the "move" edge. This makes it much easier to use since you no longer have a hidden area in the middle to avoid.
Whether or not that is accepted, the next step is probably to make the movement threshold longer as that in probably the nicest change. Right now it is half the width of the zone, but it gets much nicer as it approaches the full width. At slightly more than full width it then eliminates the chance of the type of accidental split that I mention earlier, so I can remove the angle restrictions. As the threshold gets just a bit longer there is then opportunity to make some cursor changes that can indicate direction and type of operation about to be performed. Ideally, you could start dragging into your own area and the mouse could change from the "+" to an arrow showing that direction, and then as soon as it left the corner zone it could change into a cursor indicating vertical split. Pull your mouse up and it would change into a join cursor, but move a bit further and that action would be taken.
@Harley Great. However, I though you included that already in your patch? Seems confusing to me to make the patches to atomic - I get a bit confused certainly of what is in which patch here. But in any case, nice improvements.
Can you clarify which patches are now needed for review on top of what was already committed?
Hey @WilliamReynish!
I've just been making comments on this task because I didn't know where else to comment since patches get closed.
The patch committed today just added made the corner slightly taller, restricted the angles a bit so you have to drag a bit straighter (a 45 degree drag will do nothing), and made it so that there is a threshold that is required before any action is taken. This last bit is the most important. Until this patch the behavior was that action was taken the moment your mouse left an action zone, regardless of how far that move was. Now there is a small amount of movement required, so this means that the drag can extend out of the action zone.
This patch is on its own because it really does work on its own. Making that threshold zero will give us the old behavior exactly.
The patch I submitted this morning , as far as a user is concerned, does only one thing: it moves the corner zones right into to corner so adjoining ones actually touch, rather than be bisected by the "resize" edge. But this patch is entirely optional. It can be accepted or rejected as a separate thing without affecting prior work or future plans. So it was easier for these to be two different patches rather an one big one then have us argue about the corner zone placement.
Once this patch is accepted or not, then I have some future plans to investigate. The first is evaluating the behavior of this as the threshold is lengthened. How long it can be can affect what kinds of things I can do. At one point I can actually remove the earlier angle restriction because the errors it was avoiding will be similarly avoided this way. And there might be some feedback I can add through custom cursor change, depending on how long that threshold value is.
Forgot to mention @WilliamReynish, that if things work out how I hope they will, then I might be making some new custom cursors.
Are there any other cursor-related issues? Are we missing any or could any existing ones be improved? I ask because it doesn't look trivial to make them so might as well do other things while I am there...
@Harley: Haha, I actually was also working on this. The issue is that our system for this is quite limiting because it's a 2-bit system. You only get transparent, black and white. It's quite hard to make nicer cursors using this system.
But yes, we could use many more custom cursors. Many of the active tools could use special cursors, for example.
Ideally, any tool that stays active, or any modal operation (such as color picker etc) should have own custom cursor.
I think we could generally use this approach. A small arrow for accuracy and a symbol below:
@WilliamReynish: I haven't found a cursor editor that directly supports this older format. Not that I mind the lack of color though.
I think I am just not very creative, as I can't really think of many times when a standard pointing cursor wouldn't work best. I do like when the cursor changes to indicate a status or state that we can't otherwise. Which is why I want one for "split vertical" and "split horizontal".
Somebody on a thread asked for a simple "dot" cursor for when sculpting.
Blenders source code itself includes a cursor editor. We should take this to Devtalk. Can you make a post there for cursors? Thanks.
Not to pedantic but there might be some things to think through with cursors...
Your example above make a few things spring to mind:
Color:
We are generally using icons that are white with black outlines for contrast. Were yours black on purpose or just to illustrate the "pointer plus state" idea?
Do we want to have black cursors as an alternative set for themes that are light? This might be not work as well as it sounds since (at least on windows) we use system-supplied cursors most of the time and we don't have control over those.
In cursors I have come across lately, they seem to be either all black (and no outline) or white with black outline. Our dark themes seem to preclude changing all to black.
Sizes:
It looks like the blender source supports having a small and large version of each cursors (although not many have a large version). I haven't yet examined when and how one is selected over another. Would we be making small cursors that try to fit well within 16 x 16 and then make a second version that is basically twice as wide and tall for the large version?
I don't have a retina display but when using one I imagine the system gives us a usable size, but then are our custom blender ones really small (assuming there isn't a large version)?
The 16x16 size is extremely hard to get something white with a black outline and then do what you have illustrated above. In essence you end up working with cursor parts that are 3 or 4 pixels wide at the narrowest so you run out of space quickly
My lack of some of these details and background are why I hesitate to start a devTalk post about it.
Added subscriber: @Positivity
Added subscriber: @Sombrero