Koder uses that feature too.
Yes, there is an API for stacking windows. However, it sounds nice at first until you try to use it for a serious web browser. With dozens of stacked tabs, and no icons visible, it becomes not that practical after all. So, we probably need some UI improvements here, before we feel confident in using this more massively.
2 Likes
I don’t really see why a modifier is needed for stacking. If you drop one tab on top of another, they should just stack by default, I think.
Tiling is a different matter though, as you would not want your windows to tile with each other as you drag them around.
1 Like
As the window borders will still light up when they’d be tiled on dropping the grabbed window, that too would work IMO. Of course putting windows very close together without having them being tiled would’n be possible… I guess I could live with that, but it would have to be tested to be sure.
Un-stack&tiling could be done with right-dragging.
One disadvantage: currently, if people don’t know about S&T, they most likely won’t do it accidentally. With the discussed change, they’ll be S&Ting all the time and may not discover that they have to right-drag to unS&T.
1 Like
You could have them be a bit sticky - so that you need to drag the mouse a certain distance away before they pull off of the stack, then you wouldn’t need a modifier at all.
Edit no wait lol, then you wouldn’t be able to move windows so that’s a fail!
Yes, that’s why there is a modifier currently. Breaking the basic “I just want to move windows around quickly” use case is a bad idea. And the “quicky” part is important here.
In Haiku, it’s expected that you will have a lot of windows open all the time. That’s how the OS is designed to work. So that means a lot of places where you could stack things together, especially because currently the zone where you can stack things is indeed a lot larger than just the tab (allowing for easy stacking without aiming too precisely). If we disabled the modifier, I guess accidental stacking would happen all the time, especially around the screen edges (where you move windows when you want them out of the way).
1 Like
It would still be quite nice to stack without a modifier when a tab is dropped on a tab, IMO, but I agree it should not happen over a wider zone than the tabs themselves.
@humdinger’s suggestion of right-drag for un-stacking/tiling would also be nice, and doesn’t interfere with other functionality AFAIK. Perhaps right dragging to (un)stack/tile would be a nice way to make the feature a bit more accessible without also changing anyone’s current workflow?
I guess there could be other things you could do with mouse gestures too, e.g. if you ‘shake’ a window a little bit it could break off of the stack/tile. IDK, just throwing ideas around.
2 Likes
It’s needed to prevent it from happening accidentally, doesn’t matter how slim the chances are for that to happen. If it can happen, it will happen and then the OS makes an avoidable bad impression.
What you can do is have S&T work with a modifier by default and offer an option in a S&T-settings window to do it without a modifier in the way you suggest.
The tabs were actually already present in Smalltalk back in 1976.
5 Likes
As S&T was developed at the Auckland University with many controlled usage experiments, maybe @czeidler or @christof can give us some input.
Did they explore using no modifier key to invoke S&T? If so, what were the issues that convinced them to go with a key after all?
How about allowing D&D on to tabs (like Mac Finder tabs or Chrome tabs): dragging and dropping on to the stack tabs title area (either to bring that window to the top of the stack and/or to drop into that window (which in stacked Tracker tabbed windows would move the file from one window (source folder) to the other window (destination folder).
Would that be hard to implement?
see “Move Files between Tabs” on this page: https://www.takecontrolbooks.com/resources/0184/site/chap06.html
No we didn’t considered a solution without modifier key.
Personally, I think the issue of accidentally stacking or tiling something would result in a bad UX. Furthermore, how would you un-stack and un-tile? I guess to be consistent you would not require a modifier key for this either but how would you move the whole group then? I can imagine that for new user that could become confusing.
Not saying that there isn’t a nice solution though but we haven’t really thought about it at the time…
Hi Clemens!
The forum informs that you’ve been absent for 7 years. Wow! What’s going on? 
My idea was that dragging with the right mouse button would unS&T. But I also agreed that auto-S&T would be confusing to unprepared users.
Therefore, a setting to forego the OPT key and do auto-S&T, as suggested by @Meanwhile, would be best.
I’d prefer to have the window pop to front (after 1/4s or something of hovering) instead of copying/moving blindly. I even filed ticket #15480 for that thinking about it recently.
Oh, seems like X512’s recent change solved the un-stacked scenario of a partially obscured window not popping up. I’ll update the ticket.
Maybe you’re right, but I don’t know if I agree about the bad impression: If I drop a tab directly onto another tab and it stacks them together, I’d think I’d discovered a cool feature, not a problem. How often do you want to place windows directly on top of each other in almost the same position, and in the case where you do, wouldn’t having them stacked be useful?
In the end it’s down to what the devs consider the best default behaviour, and given that the aim is to have defaults that everyone likes over configurability, they might not want to have an option to change the behaviour. But anyway it’s food for thought…
Shake the stack? 
I do love S&T the way they are, but if there is a way to make it more accessible/discoverable it would be great too!
We can implement it for experimenting but I’m fairly sure it will be triggered by accident a lot more than you’d think. You just want to move some window out of the way, you carelessly drag it away, and it stacks with something (and is resized, which is hard to revert).
It’s hard to tell without experimenting, I think. So maybe let’s do that and see what happens?
1 Like
Good call: You’re right, I have no idea. I’m glad that you think it’s worth pursuing though.
I created ticket #15727 to track this enhancement and hopefully catch the attention of a dev that is interested to give it a try. 
3 Likes
Thanks for adding / modifying that ticket.