Feedback Wanted on Area Docking Ideas

I just updated the patch and set that to 0.4. Removed the blue tint from all the highlights to see if we like them better as grays. I also put back in all the rounded corners of those highlights. It does feel a bit more… Blender, but I kinda miss the color.

Oh yeah! It’s a weird detail but that is actually a different operator running if you start with ctrl pressed. I will update that too, but probably not until this is approved in some form.

1 Like

The rounded corners made it quite a bit better. Thank you for that update.

I decided to retest the blue you had in the previous version of the patch, but with rounded corners just to see if I wasn’t liking the blue due to the lack of rounded corners. And… I still don’t like the blue with the same reason as before (too pale), but it is nicer now with the rounded corners.

The reason I say the blue appears “too pale” is because it’s paler than the other main blue used in the Blender user interface. But using the “Blender blue” as the colour for this operator also doesn’t look right in my personal opinion. It’s too dark.

So if I was to personally change it to be a colour, then I would probably have this criteria: it should be blue and it should be somewhere between the pale blue you’ve picked and the default blue used commonly in Blender. But once again, all just personal opinion. I still personally prefer the “gray highlights” over a blue, simply because I haven’t found a blue that “just works” for me yet. But this is all personal opinion.

Examples of the blue commonly used in Blender that I feel like the blue highlight should tend towards:


Just out of curiosity. Should all “highlights” have an outline? In the example shown below, some parts of the UI have an outline while others don’t. I’m not 100% sure if I prefer all operators having an outline or just some, but I just thought I would bring it up to see what you and others think.

Would immediately executing the operator on hover (while the mouse button is still held down) be an option? That way the feedback is literally the result instead of a graphical abstraction. Not sure how that would work exactly or if it would be too resource intensive.

Otherwise I’m a proponent of the theme selection color at .4 or lower opacity. (Sorry, couldn’t find Blender cursor icons to add to the mockup)

Unfortunately not, just too resource intensive. And it would only show part of the process anyway. I can highlight where you want the source to move to, but the end result can be hard to predict when the source is closed afterward.

I tried that and wasn’t too happy, mostly because the default selection color is so low-energy. I have just updated the patch with a compromise we can ponder. It uses a lower opacity for the fill but full color for the outline.

DockTheme

2 Likes

This will probably be my last comment on user feedback for visual design as I don’t have much useful information I can provide.

I personally agree with you, using Blenders “selection” colour in this operator is too “low energy” for the default Blender theme. However, a subtle variation on this colour in combination with the other smallish changes in the Blender UI can make it look really nice.
Here’s what the latest iteration of this patch looks like with my user theme (I personally think it looks nice):

For anyone wondering what my “Selection” colour is, it’s this:

So now I’m convinced, having a colour for this operation can look nice. The issue is still finding the right colour that pleases a wide range of people with the default theme.

One request I have: If you continue with keeping this colour, please keep it themable. Subtle changes to the colour of this operator can make it look good, or “meh”. If the colour is hardcoded, that’s also not great for theme makers as a hard coded colour like blue can diminish their theme that’s heavily based around a different colour.

I just realized something. Every time I’ve been using this patch, I’ve been “reviewing” the patch, not “using it”. As such I haven’t acknowledged some of the downsides of the usability of this patch.

The one change I’ve found to be a downside is the extra functionality offered by this patch makes the closing of simple editor layouts more difficult. Take a look at this example where I’m closing a “simple editor layout” with the timeline comparing Blender 3.0 and this patch:

This behavior can be worked around by moving the mouse to a different area than I was showning in the video, and it might just be something I need to get used too, but I feel like this adds extra complexity to what should be a simple task and could confuse new users.

I feel like when the editors are perfectly aligned (see image below) then the behavior of joining/closing areas should behave identically to how they are in Master (Join the two areas, don’t try any “half joining” or anything else). Every other situation where you’re joining editors far away from each other or they’re not “perfectly aligned” or something else can follow the new behavior introduced in this patch.

Example of “perfectly aligned” and not perfectly aligned editors:

Sorry if this doesn’t make sense. I’m not sure how to exactly describe this in words as I’m not sure what the correct terminology is to describe a lot of stuff.

1 Like

Yes, it could be that perfectly-aligned immediate neighbours shouldn’t be allowed to dock to. Although there are many times I like that. Maybe it is more like only allowing those internal docking targets if over a certain size. Not sure. As the rules get complex it becomes less obvious when you can, or can’t, do something. Needs a think.

That seems to me like a theming issue. Should we set yet another variable specifically for “Area Docking highlight color/border color”? I personally think it would be good to stick with existing colors from other UI selection/highlight elements.

Or maybe you’ve been staring at the same thing for too long and got desensitized? I personally experience the big blue overlay as quite dramatic already.

Can the border be inset? It currently cuts off at the edges of the window. It would also make the current black gaps the same width as the black gap of the operator when splitting its own editor shown in your gif. I’m also still on the fence about if the border is actually necessary. It’s making the UI even busier than it already is.

I’m looking at other UI elements for inspiration. Your small blue border is similar to the modifier selection, but I don’t see that style of UI anywhere else in Blender. I tried to make it similar to the node selection style with a .1 white overlay. I’m not opposed to this. I’m afraid the bright blue overlay might be too in your face. Also added some variants for completeness.

Variants



5 Likes

Just updated the patch. Now with a much more subtle highlight using greys.

I am also now restricting some operations as the areas get too small, too narrow, etc. Turns out that the highlights and cursor changes communicate all this quite well.

An example showing join and split highlighting:

DockSplit

23 Likes

I just updated the other approach to this, so we have two to compare.

One approach is the one primarily shown in this thread, ⚙ D14173 UI: Multi-Window Area Docking, which basically combines splitting, moving, joining, docking all together and started with a regular drag of a corner action zone.

This other approach, ⚙ D14166 UI: Multi-Window Dupli Docking, leaves existing splitting and joining as they are now. Instead it extends the “duplicate into new window” operator. So shift-drag on an action zone allows you to tear off new windows, drag between windows, dock, etc.

The first represents a reduction in code, and unifies most operations into a simple drag. But it also has the most change from current behavior. The second approach is less change but that certainly has advantages.

2 Likes

I’ve already had no complaints with how the system works prior to these patches. Even in earlier versions like in 2.80 it was really good and allowed quite a lot of flexibility to organize the workspace once you get the logic of the system. Then there were some patches that improved it even further allowing for even more flexibility. I was pretty happy with that.

The proposed patches are great but for me personally the second version with less changes makes more sense. It makes sense to use Shift key modifier to tell Blender to tear off the panel. I personally don’t need it but can imagine a healthy number of people could use that for the second monitor and the second patch accommodates that really well for that subset of users. But for me using Shift for swapping panel could also be proven useful.

I hope all this development will lead to tabbed interface/panels eventually. This is something that I would really love to see.

1 Like

I just thought I would report a bug related to D14166.

When running the new operation from the edge of a window, the operator doesn’t work unless you move the mouse inside the window before moving out. The same issue sort of issue as this:


If you want to know my opinion on if I prefer D14173 or D14166. I’m not really sure.
Campbell Barton has valid concerns with regard to D14173 that probably need to be addressed. However I’m not sure if they can be address by “using it and getting used to it”. Or if it is something that needs to be changed on the code side.

D14166 is nice, it leaves pretty much everything the way it was meaning people don’t have to relearn. And it adds functionality to the area it’s changing. But I don’t know if this or D14173 is “better” overall.

Yes, that can happen with D14166 if you don’t drag enough to register as a drag before you leave the window. That doesn’t happen with D14173 though so I probably could fix that if we ultimately go with that approach.

I still quite prefer D14173 but it might be hard to explain. I like it precisely because it puts everything together on a simple drag. First it is all just easier to tell the story to users if you can leave out all the hidden “and this other thing happens if you press Shift and this if you hold Ctrl”. And for operations that seems like “move” I’d rather they work with simple drag…

An illustration of this, and how it could impact future options: Imagine we remove all the corner action zones except for one. We can do that with D14173 because it allows all operations from all zones, unlike today. Now we can make that one visible. And there is one really obvious way to do that:

image

The above looks like “drag me to move this”, and if you do that it will with D14173.

Now imagine that we can have multiple editors in the same space. Now the top left corner would look like tabs of editor icons. The active tab would be wider, so you can change the editor type, and also include that grabber.

The other inactive tabs would just show an icon - so you’d have to click on it before you could change editors. But you could just drag that tab itself to move it elsewhere…

I don’t think we can get to anywhere quite as nice when “move” requires a hidden modifier like Shift.

That was mostly about dragging into the same area to split it but then wandering outside the area or window. I don’t see as much of an issue since the operation doesn’t actually execute until you release your mouse. So, unlike today, if you wander outside the area you can just bring it back in again and continue without harm.

3 Likes

This would save me so many crashes. Resizing a 3d viewport in the middle of cycles trying to render it is really painful even when it doesn’t crash.

All of the videos in the first post look perfectly intuitive to me.

This drag indicator is desperately needed. Completely separate from everything else, this is needed. Once people know that corner dragging is a thing, it won’t be surprising to find out you can drag any corner to do the same thing.

1 Like

I will just throw this here :sweat_smile:
I love this idea, I htink it is selfexplanatory, but what if the “drag me to move this” we have it on the right hand of the “toolbar” to have harmony between the panels and the editors, something like this:

And maaaybe on the left side the split one.

The problem right now is that they all aren’t the same in that you can’t do all operations from any of the four corners. For example you can’t join upwards from an area’s bottom corner. But D14173 fixes that by having Split only commit on mouse release. So then it does make sense to show one as special and visible.

The reason I’d prefer to have these drag operations beside the editor icon is that could help in further future ideas. It could allow us to do “tabbed” docking, where more than one editor is using the same area space. As in you drag one editor onto another editor’s header and when you release you get a new icon tab in the header for that editor. Might work, or not, or it might not matter where that drag icon is. But having the main drag icon near the editor identifier leaves more possibilities for an eventual solution that would be a smooth evolution rather than a jarring change.

2 Likes

The reason I’d prefer to have these drag operations beside the editor icon is that could help in further future ideas. It could allow us to do “tabbed” docking, where more than one editor is using the same area space. As in you drag one editor onto another editor’s header and when you release you get a new icon tab in the header for that editor.

Out of curiosity … how difficult would some kind of “grouped area spaces” be?
Currently it’s a rather destructive process when dealing with split 3D views for example. Say, you want to have one workspace open for the render cam with cycles in preview mode and work in a viewport next to that to place lights, geo etc. - then you realize that you need an expanded viewport for more detailed placement for some time while still having access to all the remaining panels like outliner or timeline.

Currently there is either “maximize entirely” and getting rid of all other spaces or merge together destructively, having to recreate it later. Or a complete new workspace - but when you make layout changes to one workspace then the other one doesn’t reflect them, which can happen rather quickliy after a few hours of work shifting around editors and such.

Say, you have this sort of working layout and want to have the three prominent windows grouped into one…


… so that you could maximize a window only in this group without expanding it to the whole screen.

(edit) - And sorry for off topic tangent. Just wanted to know if this is something that’s even in the realm of possibility with how the UI currently works.
I’ll delete it if it generates too much noise in your thread.

1 Like

My workaround it so take advantage of multiple blender windows.

There is a setting in windows that automatically activates other windows as soon (but not soon enough :frowning: ) as you put your mouse over it, saving a click.

I’ve got a patch to auto-focus Blender child windows on hover: ⚙ D13951 Win32: Auto-Raise and -Focus Windows on Hover

6 Likes

Oh - now that’s cool. Unfortunately on my current machine I don’t have multiple monitors any more but that is very welcome as that extra click always bothered me in the past.
I just tried it with two separate windows and it’s really nice. At least means that I can now work two monitors with Blender at work as soon as 3.x LTS is out. Thank you so much for your work on these UI things. They make a lot of difference. :smiley: