[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
decors.
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?
-Truls
Other related posts:
