Am 04.09.2010, 22:08 Uhr, schrieb Stephan Assmus <superstippi@xxxxxx>:
Don't forget that KDE has this as well now. But it will be nice to make this a feature with persistency (i.e. add support for it in all apps that ship with Haiku, at least where it makes sense).First thanks for all your bug reports! will target them in the next iteration. Yes persistence and session manager are more or less the same problem and I really like to make Stack and Tile group persistence. Anybody already has some good idea how to store a state of an application in the best way?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
This works only to restore the decorator settings of an application, e.g. restore tab position. You can add SAT specific stuff like a window id to identify closed and reopened windows but this is not exactly what I want to do. (Previous SAT implementation stores an id into the decorator message, the tracker window store this message and restore the decorator including the id when the window is reopened)
I like to safe a SAT group state, e.g. into a file. This file then can be used to restore the complete group, start applications if necessary, open window in a application e.g. the playlist, and stack and tile everything together. (Sometimes there will be conflicts when e.g. a window of a single instance application is in another group. In this case Stack and Tile can only restore a group partial.)
I need a way (and this is also what a session manager would needs) to get the state of an application via something like GetWindowState(BMessage& message) or GetApplicationState. This function would store all necessary information into the message, e.g. the playlist window would store which playlist(s) has been loaded, tracker would store the directory path. This message can be sent to an application to restore the state.
playlist support. WebPositive can display multiple websites in one window, most of them will not correspond to a persistent object. It's
What do you mean? I think its valid that the browser can store the list of open pages.
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?
Yes the application should be responsible to store the settings but I think the existing mechanism does not work because it only works in one direction, restore the decorator not the application.
Regards,
Clemens
