[haiku-development] Re: Suggestion for Stack and Tile
- From: Stephan Assmus <superstippi@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 13 May 2010 11:28:23 +0200
On 2010-05-13 at 07:27:22 [+0200], Ryan Leavengood <leavengood@xxxxxxxxx>
wrote:
> On Wed, May 12, 2010 at 8:46 PM, Clemens Zeidler
> <clemens.zeidler@xxxxxxxxxxxxxx> wrote:
> >
> > At least Axel wrote that he thinks SAT is a way to rough at the moment. Do
> > you had something special in mind?
>
> A while ago when I was more deeply involved in the WebKit and browser
> project, I read a suggestion on the Haiku forums that using stacked
> windows instead of tabs might be an interesting way to organize a
> browser. At first I did not think it was a good idea but the more I
> thought about it the more it made sense for a Haiku browser.
>
> For this to work nicely there would need to be the following:
>
> - An API to create stacked windows, so that an "Open in New Tab" menu
> item could actually create a new window in the current stack.
> - The removal of the zoom button except on the last window (which you
> already mentioned, though in your case you want to leave it on the
> first window.)
> - A way to render favicons in the window decorators (this one could be
> tricky to implement, though icons on window decorators is not unheard
> of on other systems.)
> - Shuffling of tab order when using shift-drag on the window
> decorators (basically an extension on the current shift-drag "sliding
> tab" behavior.) I don't think the current Stack and Tile handles this,
> but I'm not sure.
> - Maybe fixed tab/decorator sizes, and tooltips to show the full title.
>
> All the above might be a lot of work, though most would be fairly
> useful in general. But there is no guarantee it would be all that much
> better than what we have now in WebPositive. In general I'm beginning
> to think tabs in browsers can cause more problems than they solve.
> I've had various ideas on how to deal with some of the use cases
> people have for tabs by replacing them with other things (and I'm not
> alone on this, there is a lot on the web about it.)
>
> I think besides the browser that at least the Terminal application
> "tabs" would be better implemented using stacked windows than the
> current tab system.
IMHO the best thing about stacking windows versus using a tab view, is that
the window <-> document relationship is maintained. The window management in
the Deskbar stays effective as actual /document/ management.
In terms of "better integration", I think that there needs to be the feel to
Stack&Tile that it doesn't only combine existing window management features
like window resizing/positioning and tab sliding, but that there is this
"solid" feel to it, like it's not something on top but something completely
integrated. For the most part of this, I think the solution is completely
cosmetical. Windows do need to stay their separate objects within the
app_server, but they need to be moved together, there can't be the
possibility to zoom them individually, they always need to be locked in the
same window depth... it's been a while when I last tested S&T, but I think it
was possible to zoom Tracker windows individually or something. Also, the
rendering of the window borders and decorator should be improved. These
windows need to /visually/ form a unit.
As far as persistency goes, I believe this problem was already solved by
assigning IDs to stacks and (re)storing these. It needs to be adopted in more
applications, only Tracker does it at the moment.
Introducing an API for displaying icons in the window title should not be a
problem at all.
I would not worry about the other decorators for now.
Best regards,
-Stephan
Other related posts:
