[haiku] Re: Try it! Stack and Tile

  • From: Truls Becken <truls.becken@xxxxxxxxx>
  • To: haiku@xxxxxxxxxxxxx
  • Date: Mon, 6 Sep 2010 16:04:32 +0200

On 2010-09-03, at 07:13, Clemens Zeidler wrote:

> To activate Stack and Tile type:
> setdecor SATDecorator

Does this mean that if developers started to pump out decorators to theme 
Haiku, people would not be able to use them together with SAT?

Don't get me wrong. I think it's fantastic that the SAT code is now separated 
from the app_server. This makes things much cleaner and safer. I'm just 
wondering if this will hinder the use of decorators for actually changing the 

On 2010-09-04, at 12:08, Stephan Assmus wrote:

> If I recall correctly, the state can already be persistent, if an application 
> stores and restores the BWindow::GetDecoratorSettings() (?) BMessage. Only 
> Tracker does this as of now. I like this solution, since I don't think it's 
> the job of app_server to remember settings for each and every app you have 
> ever run and things can be complicated on the side of the application. For 
> example, a window may or may not correspond to another persistent object. In 
> Tracker, windows correspond to persistent folders (if you run the intended 
> spatial mode), or in Pe, windows correspond to text files. Their settings are 
> spatial and remembered per file. MediaPlayer is a different beast, because of 
> the playlist support. WebPositive can display multiple websites in one 
> window, most of them will not correspond to a persistent object. It's 
> difficult for app_server to do something smart here, that's why I think it's 
> better left to the application via the existing mechanism (persistent window 
> group IDs). What do you think?

I think you are right in that the application will be better at understanding 
what a window represents. That said, I'm not even sure I want persistency at 
all. What I'm more interested in is setting up rules for where different types 
of windows should go.

I want all terminal windows in one group, not a terminal opened in a specific 
directory to go where it happened to be last time. This could be possible on a 
general basis, but if you want to make the rules more complicated, they will be 
application specific.

In Web+ you might want to stack windows where the URL has the same hostname or 
resolve to the same IP address, or maybe where similar protocols are used. 
There is no way the app_server can guess this.

I also think different users will have different criteria on how to recognise 
window patterns, which is also a reason why simply saving the current layout is 
not sufficient. When saving the group id of a browser window, is it associated 
with the exact URL, the hostname, or something else?


Other related posts: