This might be a macOS only issue because I couldn’t reproduce it on Windows.
When I have two monitors, and Blender is on the second monitor, if I split a editor out of Blender, it appears on the first monitor, not the second one. Here’s a video. Second monitor on the left, main monitor on the right.
Note: Second monitor is a 27 inch 2560x1440 monitor with 100% scaling. Main monitor is the built in display on a 14inch 2021 MacBook Pro with it’s default High DPi scaling.
On Windows I tried different combinations (2 screens at 2560x1440 and 100% scaling, 2 screens at 2560x1440 but one with 200% scaling. One screen at 2560x1440 and one at 1920x1080 with 100% scaling on both, or 175% on the 1920x1080 screen). But couldn’t reproduce the issue in my testing.
This is going to be hard to believe but with docking on it follows the current splitting rules. It is just that those rules are weirder than you think and non-obvious.
Using an old version of blender (or docking turned off), there are two different ways to do a split, just dragging from a corner or using the operator (right-click the gap between editors and choose it from the context menu).
These two methods differ in when the actual split occurs. When dragging from the corner the split happens immediately and then you are actually just moving the edge. With the operator you are dragging a split preview line and then it is actually split when you release the mouse.
Where the new area is added depends on where the split occurs. If the split happens in the top 50% then the new area is added above it, if in the bottom 50% then the new area is added below. This reasons behind this are commented in area_split.
Thanks for the explaination. I didn’t know about that since I’ve only ever used the “split by dragging on a corner” option.
Are there plans to adjust this behaviour in the new system to align with the “drag from the corner” behaviour from the old system? Or is it more likely that this will be left as is?
It seems that the landing zones are a bit off. I find it very hard to predict which split I will get based on where the mouse is. I tried to depict this in a video (with audio):
Apart from that, I find the current shortcut of Shift+Click to duplicate an editor in a new window a bit too disconnected from the other editor interaction shortcuts (drag).
I would expect either to:
Just click.
Click and drag (like 4.2).
Click and drag, but while continuing to drag, to resize the new window from the corner I’m dragging from.
Yes, as mentioned earlier in the thread (by Sean Kim and Alaska) there are problems with Mac on Retina displays. I should be able to get to this and figure it out fairly soon. We deal with high-DPI on Mac a little oddly compared to the other platforms with our stored region sizes needing to be scaled by monitor dot pitch.
Sorry, but I’m not following. Using Shift-Click to duplicate an editor into a new window is not changed here and is how it works in 4.2. Not sure how “just click” wouldn’t interfere with other operations. Can you elaborate a bit?
I hadn’t noticed this until you brought it up. To align this with that behavior I think would mean creating the new area based on where the drag started rather than where it ends. Might work, but would need to be done without changing the behavior of existing area_split operator.
Thanks! I hadn’t noticed this unintentional change. There is a small threshold of movement required before dupli and swap operations are initiated that was not considered when docking was turned on. I just committed a change so the threshold is back and the behavior is identical.
Okay, just committed a change that should get you areas arranged exactly as you are used to them. Always creating the new one above if dragging down, always below if dragging up, etc.
As for the Mac issues, are there any clues you can figure out about where the docking zones are for you?
As an example, when starting with the default layout and dragging from Properties into the 3D View, the docking positions are determined by diagonal sections with a spot reserved in the middle for “replace the entire space”. There is also a space between the two areas to indicate a join between them. So the zones look like this:
Are you able to move your mouse around on the Mac and figure out what the zones look like for you? Wondering if it is just all squished into one quarter.
I just realized that a drag to Title bar is satisfying .
A drag to TopBar could be a way to extract editor as a new Workspace.
I was thinking about selecting adjacent editors. So, like when editor is duplicated or extracted, dimensions of secondary window are corresponding to dimensions of editor’s area, ; result will be the same in new window. Just the area extracted would correspond to several editors but in same disposition relatively to each other, in new window, than the one they had, in main window.
The reciprocal would be used for merging back in.
I also noticed that that placement of the “Replaces editor” and “lines that dictate which merge occurs” shift as the properties editor window moves around. For example I shifted the properties editor down and now it feels like this:
And the rate at which this region moves is not 1:1 with the movement of the properties window (E.g. If I shift the window left 500 pixels, the regions shift left 500*something less than 1 pixels). But I’m not sure what ratio it is. Probably the display scaling ratio.
As expected, this issue only occurs on HDPi displays. So if I use the same 27inch monitor I use with my desktop on macOS, there’s no issue. But if I use the built in display there is a issue.
This issue does appear to be limited to macOS. I can’t reproduce the issue on Windows when setting my display scaling to 200%.
Oh, I didn’t think of trying that. I often change the scaling on one monitor when testing things but I don’t think I 've tried setting one at 200%. Although one of my monitors died and I am down to two - have just been too lazy to pick up another. Might have to do that tomorrow.
EDIT: This reply is a bit daft since it is the result of me mis-reading Alaska’s “I can’t reproduce the issue on Windows…” as “I can reproduce the issue on Windows…”. Might need stronger glasses. LOL
If you want any more information in the future to help track down this issue (E.g. information from a debug build), just let me know, I’m happy to help out.
I’d be willing to let you remote into my Mac, but there will probably be high latency because I’m probably on the opposite side of the world from you.
I’d be willing to let you remote into my Mac, but there will probably be high latency because I’m probably on the opposite side of the world from you.
I’m getting a Mac fairly soon (next couple of weeks maybe?). I’m on the opposite side of the world from many. I on Vancouver Island, off the west coast of Canada. Just above Seattle.
I said I wanted to test this change for a week before giving my vote. It hasn’t been a week, but it’s nearing the end of a typical work week and I thought I’d share my general thoughts.
Thoughts
Disclaimer: I haven’t spent much time in 4.3 over this past week because I’ve been doing a quite a bit of triaging work around the 4.2 release, and any “proper work” I do in Blender I generally do in stable releases (4.2). So my experience isn’t representative of everyday frequent use.
I will also be ignoring the macOS scaling bug for these thoughts.
Since the joining and spliting of editors in this new system is similar to the old system in terms of action, and this action is so common, I feel it’s important that no unneccesary change that messes with peoples muscle memory or expectations is introduced. The new interactive editor docking meets that criteria. It adds new functionality to these common actions without messing with muscle memory or peoples expectations when doing their usual actions.
Being able to grab a editor and rip it out of the Blender window to create a secondary window feels intuitive, and it’s more accessible/discoverable than Shift + Click and Drag (which I don’t know existed for a long time and thus didn’t use it for a long time).
Being able to grab editors from other windows and shift them between windows also feels intuitive and the user interface is clear on what will happen.
As for grabbing a editor inside a window and shifting it somewhere else in the same window, I don’t personally see myself using it. And I don’t recall a time where I’ve desired this functionality. The UI can also be a bit unclear when doing this action as the “This is your new layout overlay” sometimes doesn’t match what happens when you let go of the mouse if you’re shifting a editor onto a neightboring editor. But I believe we’ve talk about this in the past in previous feedback threads for this feature, and it’s hard/impossible to do in the current Blender system.
Overall, I’ve given this is Yes vote to the Should This Be Made Non-Experimental? pole. Some of the new functionality is great, and none of the changes negatively impact my existing muscle memory and expectations, which is an important factor for changes to features that are so common.
Docking should be working better on Mac now, thanks Jonas Holzman.
We’ll still have some issues when the source and target areas are on separate monitors. This is because we don’t currently support multiple monitors on Mac properly. We’ll get there eventually.
But Jonas fixed problems when tearing off and docking back into a window when within the same monitor. In a nutshell, the locations of potential docking locations needed to be scaled by the monitor DPI in order to work correctly on Retina displays.
As of yesterday the docking interactive feedback has been toned down a bit. It should be a bit calmer and hopefully it is a bit more clear where things are moving to.
