I have a “work in progress” patch that adds the ability to dock areas (move Blender editors to any location, including between multiple windows).
D14173 extends the “Join Areas” operator. You just drag out from a corner zone and you will be presented with multiple dock locations along with possible joins. A (small) downside is that we lose the ability to reverse join directions while mid-operation, but doing so also simplifies things since you are always operating on a single source area. Split Area operation changes so that it only do so on mouse release. This allows for seamless transitioning between docking, splitting, and joining and you should no longer get any accidental splits.
The following shows seamless transitioning between area joins and vertical and horizontal splitting:
The following shows how dragging with your mouse gives you options for joining and docking in multiple locations:
The following shows creating a new window by dragging outside the window:
The following shows moving areas between separate windows:
Note that I am looking for people to actually test these patches (this is the Development site after all) and to give very specific feedback that is related to these operations and how they could work within the current Blender interface. Comments like “This shouldn’t be so hard, just look at XY software”, or “here is a link about Visual Studio docking” are not useful. I know how docking works elsewhere, but I’m searching for an intuitive way to add this type of operation to our existing systems.
Note that there is also an alternative to this patch that keeps existing Split and Join as they are and instead extends the “dupli” operator (shift-drag from action zone): D14166.
My vote goes for the for the first version - extending the Duplicate Area operator. It’s just less error prone.
I don’t think it’s generally a good idea to use existing bugs as downsides when comparing feature designs. All it means is that the bug (finally) needs to get fixed. But reluctance to fix existing bugs should never become constraint for design of new features.
I prefer your first version as well. I don’t like the idea of being locked into an operation if my pointer crosses a line, better to keep both operations separate and deliberate. Pretty cool idea ! it really shines when used between different windows.
Now, I haven’t tested your patches because I still haven’t taken the time to figure out building Blender, but on paper, this looks like a good improvement.
My two cents : maybe it would be nice to give the user a slight hint for dropping the area : since there are five different possibilities for dropping (four sides + center), maybe draw lines that show where to place the pointer for the desired effect. Sometimes the borders are not obvious, especially for areas that are very uneven this could be of help (a tall outliner, or a wide dopesheet for instance). Something similar was talked about for the pie menus : ⚓ T56949 Pie menu design improvements
I tried custom builds for both diffs. Normally I would arrange Blender via splitting and merging. But d14166 is much more agreable.
d14173 feels less controlable. Instead of changing something about the arrangement of the areas the current area just splits. It took some time for me to figure out that I ‘consequently’ had to drag the cursor away from the area. And even after I got some rearrangements done, I still did several accident splits.
I barely used “Shift” to create a new toplevel window for Blender. I was not aware of this one. And now, I think, I would not miss it. The other way of using shift prevents accidental splits. Arranging areas feels much more controllable in D14166. Imo … there are better ways to create new Blender Windows.
Yes, for this discussion “splitting” is dividing an area into two parts. I tend to use the words “join” and “merge” interchangeably to mean combining two neighboring areas into one. “Docking” is moving an area to a new location.
This is why I’m not giving up on D14173. The interference with splitting could be fixed by only previewing split when hoving and only commit to it on release - in the way that split now works when selecting it from a menu. That way you could safely move your mouse into and then out of an area without harm.
Thanks for supplying that bug report; I’ll take a look at it. I experienced that a lot while implementing this.
I’ve just updated both patches to incorporate code from D14085 & D10236, the first fixing the issue where you can’t immediately drag a new window when you create it, the second fixes the issue where modifier keys (like Shift & Ctrl) are not recognized on first click of an inactive window.
I also greatly improved the visual feedback of D14173 so it is easier to tell what area is being acted upon and what changes are being proposed.
The more I play with both of these it seems like the only solution that actually makes me happy would require a change that would be hard to do at this point in time: change how split is initiated from the action zones.
If Shift-drag was used for Split, then regular drag could be used for docking, joining, and creating floating windows. Not only would it help with doing docking here, it would eliminate all the current “I keep splitting when I don’t want to” reports from new users.
But I doubt such a muscle memory-breaking change could be done at this point. Although there might be a way to make such a change more bearable. Move our current split to Shift-drag, as mentioned, but also allow regular drag to split:
Drag into the same area and it would highlight just like the docking previews but these would be for splitting. As in drag down and into an area and the top half would be highlighted, let go of the mouse and it would do a horizontal split. This would work from all four splits and the center highlight would still be used for “New Floating Window”. It would turn splitting into just another area option that can be done along with docking, joining, etc. The split wouldn’t be as immediately usable as it is now, but for that we’d have Shift-drag.
Patch D14173 has been updated as mentioned above. If you move your mouse into the first area you will be presented with highlighted options for splitting that you can accept with mouse release. This allows seamless transitioning between docking, splitting, and joining. And you no longer get any accidental splits.
Yeah I agree that a shift + drag to split would be very much appreciated as a newb. I think the behavior is a bit better in 3.0 but still I accidentally split when I want to join etc. quite frequently. So much so that I right click oftentimes when I want to join. So I’d definitely appreciate adding a modifier to that to create a split.
Or it could be the other way around, that adding a modifier to join and the other non-split operations would be good too.
Basically a modifier that splits (pun intended) off split from the join and other commands or visa versa would be very much appreciated especially as a newcomer.
Playing with D14173 now, it feels really nice to have split, join, and dock all behaving so similarly and just all being alternative changes that are always offered and available.
There is another potential advantage of all three things working together without need for a modifier key. It means that we could potentially change to using something else as the drag source instead of the corner action zones. For example if we move to having multiple tabs per editor, we could do all these things by just dragging from the tab. Or dragging the editor type icon itself, or similar.
But… although the change to splitting in D14173 feels logical, it is still a big change. Different enough that we probably couldn’t tolerate this amount of change in a point release. And not sure I can wait for 4.0 to get docking functionality.
Following shows transitions between potential joins and docks, ending in a split:
Hi, looks promising. I think an improvement would be the ability to cut vertically. The video below shows in red what happens horizontally. Can this be implemented? Also a way to “Swap” left to right and up and down would be terrific, thanks! Note: I changed the colors a bit because I thought they were a bit too bright. Thanks again!
Your video is only exploring features that I already added to Blender 3.0, not anything introduced or changed by this patch. At 0:03 you show a join where the target area has overlap that has to be cut off. At 0:08 it is the same. But the last one you attempt has two areas that line up exactly with no overlap. I’m sure there could be some new feature considered but it is unrelated to these patches and the proposed changes.
Yeah, I remember those patches, and a couple of them actually have been/are being covered by Harley already. What I’m personally waiting for is this one ⚙ D7946 [Scr-ops] Drag resize operator
Anyway good job @Harleya with this! Multiple tabs per editor sounds like a God sent. Mixing the customizability of other software in arranging various editors/tabs/menus (and basically create are own “editos”) with the smothness of Blender’sUI sounds really promising!
Okay you have to trust me, but I have now abandoned my first attempt in favor of my second.
There just too many advantages of treating Join and Docking similarly, while there isn’t as much that Dupli and Docking can share. And there is much added utility in having more operations that do not require that a modifier key be held down.
If I make the split operation work more like it does now when selected from a menu, we should end up with a version that has similar enough interaction that we should be able to consider this for 3.3. That’s the plan anyway.
I’m testing it a bit, that’s already amazing @Harleya !
OK, I’ve noticed that you have updated the patch from yesterday evening while I was writing this, so the first part below it’s not up-to-date. Maybe though it’s still worth it to keep it, so here it is:
I’m wondering about a couple things:
I’m not sure it’s worth it to keep the “duplicate in new window” thing in the same operation, I feel like that should be done from a right click menu on the editor instead (to be honest though, every time I needed a new window I did it from the menuWindow -> New Windowso I might underestimate the need of a quicker way to do it).
somehow related to the point above: sometimes I think it would still be useful to have the current behavior, where you can immediately choose the size of the new area; maybe that could be mapped to Shift + drag
in your current patch these two operations (see video below) have the same result and to me it seems a bit unpredictable, especially when merging lateral, smaller areas (ex. the outliner)
So basically you already addressed my first two points, at least partially (the shift+drag to create a new window still feels really strange to me though).
Instead the third one I think it’s now a bit worse, it’s really difficult to predict what would happen when you “move” an area on top of the other one (with the second one completely highlighted).
I’m wondering if that operation should swap the two areas instead.
Yes, there are actually a few operations that overlap, depending on the situation. In this capture, all six options shown between Properties and 3DView will do different and useful things. But at an extreme, like a window containing only two areas, there would be some join and docking options that end up with the same result since there are actually few different results possible.
I think I’ll get another chance to visit this soon as I have to block some operations if the areas get too small. Imagine an area that is wide but not high at all: it could be possible to dock to the sides but not to top or bottom. Not sure how weird it would be that we’d then have a variable number of target zones. I’m hoping that it will become clearer when I get there.
I had been assuming that this type of operation would be used a lot: “move this area over there, replacing that other area”. But maybe it isn’t important since there are so many other docking options, and it is already so easy to just change the editor type now, and to close any. Or maybe it requires some different highlight that makes it more clear? If that became “swap” then I’d need some other mouse cursor for “move” too. Interesting.
That isn’t changed with this patch, but has been standard Blender behavior for ages - just relatively undiscoverable. I love having the option on the Header context menu, but I’d like to keep a hidden power shortcut of simply dragging the action zone off the window. The big change from now though is that it should create it at that new location - though complicated by the fact we have action zones at all four corners to placement of the new window is not trivial.
And if you drag out the last area from a non-main window it should close that window too. That should get us a bit more symmetrical with the dragging to create a new window.
Ouch! I just realized there was an error there and it was not doing what I intended at all. I can see why it was confusing. Now fixed and should make more sense.
It is now creating floating windows as I wanted. Dragging outside the window creates a popup at the mouse position and closes the original area:
Of course you can still create new windows with the old methods, by right-clicking on the header or by Shift-dragging, but this is a nice fast shortcut to putting windows exactly where you want them.
