I have a different idea for tabs in R2/Glass Elevator. We have Stack and Tile built-in now, what if we were to change the way tabs work in WebPositive and Terminal so that when you open a new tab instead of opening the tab inside the window it would create a new window and add it to the window stack? This would give us more featureful tabs that could be taken out of the tab group and added to another one and rearranged. Each tab would be in its own thread which would isolate a problem (e.g. runaway javascript) to a single browser tab.
1 Like
I wondered about why that wasn’t the case, especially after trying Koder. Seems like a rather natural way to go about having tabs in Haiku programs. Tbf though, the current implementations of tabbing for both WebPositive and Terminal do allow for nested tabbing in a way. A possible usecase would be having two web browser window tabs; one for work-related browser tabs and another for everything else.
That would be too easy 
Unfortunately due to the way WebKit is designed, it would not solve that problem, because everything (javascript, network, rendering, …) is done in the main application thread. The window is just running a very simple code that receives a BBitmap and displays it. So, it does not matter if you create many window threads, because they will all be blocked waiting for the main application thread to finish its work.
The way to fix this is known, it’s webkit2, which splits the work into multiple threads precisely to avoid this problem.
NetSurf uses native tabs, if you want to experiment with how that UI feels. It’s missing some features, in particular, the tabs can’t have a favicon, and this setup doesn’t work that well when there are a lot of tabs open.
Hold on, does that mean that WebPositive just uses webkit1? Are there other web browsers on Haiku that do use webkit2?
Yes, currently it’s WebKit1. Note that WebKit1 and WebKit2 are the same codebase and rendering engine. WebKit2 is just splitting the work accross multiple threads and processes. It does not help with handling modern websites better, for example. (just wanted to make this clear because the use of version numbers can be a bit misleading).
3 Likes
Oh man, as a Mac & Be fan, this is really interesting! Thanks for sharing this! 
I’m not sure who was first now that I see this. Taligent definitely does look like a twin of BeOS, including a dock on the right side, and what I can tell from reading Wikipedia, Be Inc. was around at the same time the functioning prototype was made…
So, yeah, you could be right that Be might’ve “borrowed” the idea. Or maybe the two just had the same 
idea at the same time. I really don’t know; both the timeline and the tab feel are really close!
And I guess since we’re talking tabs and classic Mac OS… I find it curious that the final iteration of 8.0 “Tempo” still retained the tabs idea (albeit scaled down) in the form of ‘pop-up windows’, but then, after 9.2, these pop-up tabs were done away with. I kind of like these… and the only reason I can think of for this feature being wiped off the face of Mac OS 10.0 onward is the Dock (which didn’t have folder tabs). And to illustrate (just in case for anyone not familiar with Mac history), pop-ups worked by dragging open Finder folders down or choosing ‘as pop-up window’ from View, where they’d become folder tabs and could pop in and out at will:
Maybe Haiku could revive this idea? It’d obviously not be that high on the priority list, but hey, since we’re all talking 
Glass Elevator or “R2” ideas, why not? 
1 Like
This is quite the logical next step. I’ve thought about this myself.
1 Like
I think there is already a partially implemented API for this… from what I recall. Netsurf uses it I think?
1 Like
I figured it would be in the works. It just makes sense.
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