Yes, but how and where would that be exposed? If not ctrl-z I wouldn’t remember it. And if not an easy-to-remember thing it needs to be on a menu, but where?
Would it be per-window or global? So if you broke an area out into a new window does this close that window?
Would you really need more than just the ability to do a single undo?
Is there a point when such an undo point would no longer be valid?
Do this only involve the size/position of each area and its type, or is anything else involved? Resizing the window itself probably wouldn’t a part of this. But what about a simple resizing of editors within a single window? Or are we just worried about splits, merges, and moves?
to keep things simple as possible id make it global and have a submenu in the Edit menu just like the undo history. the shortcut can be anything, we just need to learn it once.
closing already opened windows seems overkill
pretty sure sometimes one might need to go several steps back. so yeah
this would have a limit i think, just like the regular undo. or you mean something else?
id be happy with all of it (splits, merges, moves AND resizing of editors)
changes to the window itself is not needed yea
Yes, completely separated. maybe Ctrl-Alt-z ? Preferably with a few steps of undo, though you probably don’t need as much as for modeling. But the amount of times I have accidentally screwed up my UI layout and would have liked to undo just that while being sure it would not influence the actual data I’m editing is large (I’m clumsy ;'-) ).
To me it would feel strange if this sort of UI layout was intermixed with ‘actual’ undo steps in the same undo stack, as they are conceptually quite different things. And I’d expect it to be simpler implementation-wise as well, though I could be very much mistaken there because in the end it’s all datablocks of course.
As I was testing, I had the urge to use my scroll wheel to select what type of editor the new window would be after dragging it out. I wonder if this kind of functionality has been considered. In other words, if you click and drag out a new editor area, and scroll-wheel down before releasing the click, it could cycle through the options of editors. Not scrolling would give you the default result of duplicating the window it was dragged from, but scrolling would result in a new editor of the selected type.
One thing I noticed is the lack of an indicator for how remaining editors will fill in the void. This is not always immediately clear.
No, but in a lot of cases it isn’t really possible to give feedback on the immediate operation (what you are moving) and the final result at the same time. In simple cases I could probably do something, but a lot of times even if I knew what was going to move it would be hard to show it as a meaningful feedback while it is proposing docking targets. But I can see what what I can do to improve that. I just wouldn’t want that to delay getting this out of Experimental since that is an issue we have now without docking.
I’m also still a fan of small “this area is interactive” indicators in the corners.
If we can get this Docking out Experimental then we will finally have the ability to perform any operation from any corner. This means we could explore ideas of making one special, like showing a dot or gripper.
Is the overlay themable? It won’t work well with light themes.
It works well on the official Light theme. The divider line is using the theme color for “Editor Outline” while the info at the cursor is using the tooltip theme. Yours is using white between editors and is using white as the tooltip background, so it appears to showing as I’d expect it to. Feels okay though.
I remember this from the previous threads, but I never understood the rationale behind having one special corner. It just seems like a quirky - which would be on brand - inconsistency to me.
That makes sense. Otherwise the most meaningful interaction would be displaying the end result immediately while still dragging, right?
The official light theme is more of a grey / high contrast theme. With an actual light theme (I’m using Piano White) the fixed white transparent overlay doesn’t create enough visual difference between non-impacted areas and the area you’re hovering. The issue is that the area you’re hovering becomes the primary focus of the user and the cursor becomes secondary. You could go as far as hide the cursor and the feature would remain nearly perfectly functional. So having this primary focus stand out enough is important.
A solution could be to use one of the text colors as the overlay color with a fixed transparency of 10% or so.
I’m not sure what you mean here, so perhaps I explained it badly.
Currently, before docking, we have four invisible “action zones”, one at each corner. You can’t do all operations from any of those zones. For example you can only join two areas by using a zone that is between them. This means we cannot add a gripper or some other mark to the top-left one to make it more visible.
With this docking enabled any action can be completed from any of the zones. This opens up possibilities like making a zone visible, having only one, dragging by the header, etc. You can even run this from a single shortcut if you like.
To clarify, I think it’s not perfectly transparent that all corners are interactive when only a single corner has an indicator.
The biggest issue with the current (4.2) implementation is that the functionality is barely discoverable due to solely a cursor change on a small invisible hotspot. The second biggest issue is that not a single new user can figure out that the corner hotspot is actually two. One for each editor corner. (This is mainly due to the cursor change persisting on the edge instead of purely on the editor’s corner. But that tiny area can use every pixel it can get.)
These issues will persist with area docking, though they have little to do with the actual function itself, so I understand wanting the feature in there asap and worrying about ux later.
I’m all for a shortcut. (I dream of a single-key one that invokes on the downstroke and confirms on the upstroke. Though that would pose issues with cancelling. )
For sure. But to be honest I’d rather move toward a single visible widget that all operations can be done from. Especially when that can become (possibly) just a drag of any area header.
This is mainly due to the cursor change persisting on the edge instead of purely on the editor’s corner.
I did that. Because these (dumb) areas are hidden there is no real way to direct people to the ideal place to drag. So a very common complaint was new users aiming for the space right between editors rather than at their corners. Those complaints were lessened by having the action areas extend slightly over the edges, eliminating the dead spot between them.
With a visibly indicated space, like a vertically-aligned “gripper” at the left of the editor header, then the action zone space can move back from the edge and extend down to the bottom of the header. So both visible and larger.
I understand wanting the feature in there asap and worrying about ux later.
It is more that these changes have to be done in a number of steps. I worry about UX always.
I’m all for a shortcut. (I dream of a single-key one that invokes on the downstroke and confirms on the upstroke. Though that would pose issues with cancelling. )
With docking enabled, F3, search for “area_join”, right-click on it and assign a shortcut. It is magical.
I hope this feature will become non-experimental soon.
BUT: Since a few days (can’t tell exactly when it started) the cursor doesn’t change shape at all when hovering over an area where I could start a split.
In the non-experimental splitting / docking I get a cross-shaped cursor, with experimental the cursor doesn’t change at all. Splitting and docking itself works flawlessly, though.
I’m under Linux Mint 22 with Cinnamon DE, not using Wayland.
EDIT: Just tried on Windows → everything fine there.
For docking while on Mac, Pablo wanted to use the OS-supplied hand cursors. So while hovering over that corner it shows them an “open hand” cursor, and when you press down you see the “closed hand” cursor.
On Windows we don’t use hands, and we don’t have two different cursors that match like that. So when not on Mac it is showing our WM_CURSOR_MOVE while hovering over the corner and during the operations. On Windows this cursor define shows a cursor that looks like a four-headed arrow. I’m assuming that this define on Linux (at least your flavor) shows a regular arrow.
It might make sense to put the old hover cursor back to how it was. So hovering the corner it shows WM_CURSOR_EDIT, which looks like a little plus sign. And keep the rest the same. So on Windows it would change into that four-headed arrow when dragging, while on your Linux you would see that arrow pointer while dragging.
)
