I’d guess that the auto-raise patch might make it into 3.3 if we can agree it is an improvement.
2 Likes
It would be a massive improvement.
The best thing about blender to me is how it feels like one giant work surface while at the same time each editor area feels like its own program because they each can have their own shortcuts.
I would love to have a single massive Blender window stretch over both of my monitors. Unfortunately Windows has issues with windows stretching over multiple monitors of different resolutions and font size settings. So the 2nd best option is multiple Blender windows but then you lose that sensation of working on a singular work surface because you need to click to activate each window before your keyboard shortcuts can work.
Also ctrl+space is often annoying spread over 2 monitors, it works best with 1 window per monitor.
And the pop up message about closing without saving tends to appear right at the boundary between 2 monitors if they are arranged vertically 
- very hard to see.
And most annoyingly you can’t drag an object from the outliner of one window into the geometry nodes editor in another window.
For sure, but we have one spoiler, the Render window. After I refactored the win32 window creation code we had some complaints about that one so I had to backtrack and leave that one as “parentless”. Unfortunately those don’t play well with auto-raising as it just dives under others when an overlapping window gains focus. That patch tries to deal with that as best as I can, but makes approval less certain.
Add Parentless Window and Parented Window as options here and that should fix all complaints.
The few people who would be using multiple Blender windows and activating the option for auto-raising (I prefer making things optional as much as possible to avoid the wrath of vocal minorities) would not have a problem switching this option from New Window (Parentless) to New Window (Parented). Even though I hate the other options in there I would live with any of them with them if I meant I got the auto-raising feature. I also don’t have a problem with opening a render window and permanently placing it over on a 3rd monitor to not ever have to worry about it overlapping other windows and diving under.
To be honest, that never occurred to me.
@Harleya I asked a relatively new Blender user about their thoughts on D14173.
One thing they really liked about it was that they can change direction in the middle of an operation. So you can start a split, then change to a join. They haven’t “used” D14173, I just showed it to them and asked “what are your thoughts on this?”
I also wanted to point out another thing. D14173 breaks a certain thing some add-ons do. I’m not sure if an update to the add-on could fix it or if it’s something you want to address on the code side.
The thing some add-ons do that are now broken is this:
- You press a button to invoke the operation that’s now broken.
- The add-on saves the current editor type.
- It changes the current editor to something (E.G. Preferences for the add-on)
- It then splits the Preferences editor into a new window.
- It then changes “old” Preferences editor back to the original editor type.
It’s broken because the “Splits the Preferences Editor into a new window part” operates differently from how it does in master.
Here is the python code from an add-on. The code is of the function called after pressing the button:
def execute(self, context):
#save current 3dview area
old_context = bpy.context.area
old_area = bpy.context.area.ui_type
#change current 3d view to new type
bpy.context.area.ui_type = 'PREFERENCES'
#then dupplicate into new windows
bpy.ops.screen.area_dupli('INVOKE_DEFAULT')
#restore viewport with old area
old_context.ui_type = old_area
return {'FINISHED'}
And here’s a video show casing the issue:
That seems solvable. That looks to be a complex way to get around a missing feature…
Right now when you “Duplicate into a new window” the old area remains as it was, which I’ve always found sucky. I don’t want a duplicate of the thing made, I want that thing torn out and made free.
That script segment is using that behavior to make a new window of a specific type. Change any area to the type you want, call dupli, then change the old one back. It fails after my patch because the old one is removed.
You could just alter the script by doing a Split first. Or call the “new window” function instead and then change the editor type in the result. But it is probably better for us to just allow the “new window” call to take an editor type as an argument so you can do it in one line.
I had someone ask for a related thing recently. He wanted the “Window” menu to include a submenu with all the editor types. So you could select something like Window / New / Preferences to get a new window containing that editor type. That seemed a bit unnecessary when he asked to be honest, but I’m wrong a lot. LOL
1 Like
All these window management improvements are very nice. I do a lot of multi-monitor work, especially since I recently bought a small external touchscreen monitor with stylus, so I really appreciate you working on these workflow fixes.
One thing I noticed is that if you right-click on the header and do “duplicate into new window” (Which I do a lot as I still haven’t found out how I create a 3d viewport with white background for greasepencil except by duplicating the existing one 
) the created window doesn’t have a maximize button. Which is kinda annoying as the first thing I want to do with it is move it to my other display and maximize. Luckily it is resizable, so I can manually ‘maximize’ it ;-). Is this on purpose? Or is it just a glitch in gnome on ubuntu maybe? Or just a small oversight which would be easy to fix?
Where would I need to look to look into this? Somewhere in the GHOST code I guess?
Side note. If D14173 stays the way it is, then “Duplicate into New Windows” should probably be renamed. It’s not “Duplicating” anymore.
That might be fixed already (3.2). The window behavior is supposed to be the same as what you’d get with Window / New Window, but I made a mistake when I was refactoring that code (2.93?) which resulted in them being treated as “modal”. I didn’t notice because we do nothing special with this on the Windows platform. But Mac users complained so I fixed that recently.
I might not like the way the space occupied by the old area is filled in by randomly rearranging the other areas.
If I remove the asset browser will the outliner get taller or will the properties get wider or will something awkward happen with the 3d viewport or the shader editor?
I’d prefer to make a duplicate of the asset browser and then change the old area to a 3d viewport of exactly the same size.
He wanted the “Window” menu to include a submenu with all the editor types. So you could select something like Window / New / Preferences to get a new window containing that editor type.
That would be nice. I’d like the shortcut to be shift+clicking in the editor list
Amen.
Hm. Please please keep the ‘duplicate’ functionality as well. I use that a lot. With my multimonitor setup I have one smallish touchscreen and a comfortably large color-calibrated normal monitor. I often like to have the same view open on both monitors while working, switching back & forth between mouse and stylus between 2 different monitors. I can imagine a ‘tear out’ function would also be nice to have, but both have their use.
This is also something I don’t really see a good solution for. It’s very easy to change the type of window after the duplicating, so for me the remaining of the original window is a non-issue.
With D14173 (my preference) that might be possible - shift-drag could remain as-is, but you could tear out with a drag. But I don’t think that would work with D14166 or you wouldn’t be able to dock.
Also not a fan of “tearing out actually removing and rearanging the remaining workspaces”. That seems very intrusive. I also rather think of it as a quick way to duplicate a viewport to a secondary window instead of eliminating the old one.
If that is desired then it would be a secondary hold action key.
2 Likes
Moving, instead of duplicating, is why this is possible:
6 Likes
I think using a modifier key for duplicating the window, and the defaut being a tear-off makes more sense as it’s a paradigm a lot of software, including Blender, already uses.
4 Likes
Yes, but there is a difference in logic when dragging something to another space in the UI or dragging it away. But I guess that would be inconsistent again as the default behaviour is different depending on where you drag the workspace.
Modifier key for duplication would actually be more sonsible - agreed.
1 Like
I’ve been following these patches for a while now and some things are bothering me…
I don’t mind radical changes if they’re for good but it’s hard to measure how good this new system is.
I like the notion that D14173 is simpler in code. Simplicity is almost always better from my point of view. But something bothers me about this patch. I think it’s the visual complexity. The interactions seems “noisy” visually. Like a lot of things happening at the same time.
My preference is gravitating towards D14166 patch. It’s familiar with perks of added functionality for those who needs it.
I’m perfectly fine with D14166 functionality where you can click-and-drag the area to quickly rearrange your layout. But I believe it’s very much expected to use modifier keys to change the behavior of the operator. Shift for tearing out the area and Ctrl to swap areas.
Yes, there could be issues for new users with introduction to the keys as Pablo said. But it should be solved through UI queues (cursor changes on modifier key press) or tool tips which are underutilized in Blender. Like in this particular case as soon as you activate the operator (start dragging the corner) there should be a hint in the status bar that you can use modifier keys like Shift to tear off the area and Ctrl to swap areas.
Cramming all the functionality on one action seems like an overload to me. I’m against it.
And I also hope D7946 patch never comes in. It’s so intrusive and bad for UX. I can see a ton of issues it can cause. I have no idea why Pablo would want it.
I also support this notion. It’s not the behavior I would expect when tearing the area.