Toggling a window from Tiling to Floating and then to Tiling doesn't restore it's previous position

Thanks for the report and the video.

Right now, when a floating window is toggled back to tiling, it looks for the nearest node and joins that. So in this case, if you drag the floating window a bit to the right before toggling it back, it should join the right tab group.

For the tab order, newly tiled windows are currently added to the end of the tab bar. So toggling back to tiling does not restore the previous tab position. It just adds the window back into the tiling layout.

Ok, now it makes sense on why it works sometimes. I feel moving back to a window’s last known tab group instead of the closest tab group is the better UX.

I think if Wrapper creates a robust layout system with apps per tab group it would naturally work that way in the future. But to reason about it today, now that we have dedicated dropzone for tab groups, maybe floated windows that were unfloated before should just return to that state in whatever group it was in? I know it's an exception to the rule but feels more intuitive, but that's just our opinion and maybe others would disagree. I can see it working both ways.

Yeah, in this case, restoring it to the original spot does feel intuitive.

The tricky part is the more complex cases. For example, if the floated window was moved, should it restore to where it came from, or join the nearest node? Or if it was floated from a tab group on another screen and then dragged to the current screen, should it go back to that original screen's tab group, or attach somewhere nearby?

So for now, treat floated window as a new window, one behavior: join the nearest node. It keeps the logic simpler and more predictable.

Yes, complexity wise, it does makes sense to reduce the amount of conditional logics to keep the code clean. But if it is compromising the UX then it is a different story I feel.

Here is another example. The setup have 2 windows in left tab group and 3+ windows in right tab group. I made a window floated from the left tab group. Now my expectation is it should go to left, but it goes to the right tab group since it was closer to that node.

Now if I need to get back to my inital setup, I have to 1. move window to the left. 2. then change focus to the first window 3. then run toggle Tabbled/split layout shortcut. 4. change focus back to my target window.

I know that this can be bit more simplified if I just drag the window I want to tab but this is lot's of friction for a mode that is primarily keyboard focused.

Maybe we can find a middle ground where as long as the floated window was not moved restore to previous tab and once modified fallback to the nearest node logic.

This case makes things more complicated. Restore means finding the window on the left and rebuilding the tab group. I need to figure out a better way to meet your needs while keeping the logic as simple as possible.

yeah, good luck.

I've been pretty heavily reliant on the tabbed layout feature since I use a 27inch monitor. I guess if it was an ultra-wide, then split would have been the default for sure.

Curious, what is your typical setup and how do you handle such cases right now?

I use a mouse and sometimes use control option cmd + arrow key for window split/tabbed.

Been testing out the beta and it seems to have solved all my pain points reported here!

Awesome work! 🎉