On Fri, 12 Aug 2011 22:37:07 +1200, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
Basically you just need a way to store the app state and to restore it.All the other stuff like session management and profiles can be done usingthis functionality. For example, you could develop your own profile manager on top of it.That's where you're wrong. To support features like storing/restoring onlywindows on certain workspaces, an interface that only allows to store/restore the whole state isn't sufficient.
The workspace should be no problem. In the worse case you open the app on the
wrong workspace and then move it to the desired one.For the position of the windows I don't know if this really makes sense to do it at all. I can imagine that you want to open a profile on a different workspace but why change the position?
Anyway, managing the window position is not that straight forward becausethere is nothing like a window id. Thus the application has to keep track of
the windows by it self. Scripting a window by title does not works because in general the title is not unique. In general the session manager does not know enough about the windows in the application to send them anywhere.If you really want to do that there must be some protocol to identify windows in an application...
The API should provide ways for the application developer to conveniently store/restore the data. A single BDataIO for the whole application statecertainly isn't convenient. E.g. for an application with multiple documentsit might be helpful to have a BPositionIO for each document. There could also be cases where multiple BPositionIOs per document would be even more convenient. I would keep the API flexible in this respect.
thats already possible, you can have as many BPositionIO as you like :)
For the api, I'm thinking about to give mmu_man's idea to use the BArchivable Archive(BMessage* archive, bool deep) method to store the state another try. It looks more consistent to me but we still need an extra restore hook...While I'm not opposed to involving the archiving API (Haiku's is already alot more powerful then BeOS's), IMO it is far too "literal" to be useddirectly. E.g. one might want to store a window's state, but archiving thewindow would store the complete object hierarchy. This is not only unnecessary, it is also a compatibility issue (think app updates).
yes right that might be to much info. Isn't the deep flag the flag to specify only the first layer? That would probably be okay. By the way KDE and android also just save the state in a BMessage like container *). Regards, Clemens *) http://developer.android.com/reference/android/app/Activity.html#onRestoreInstanceState(android.os.Bundle) http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKMainWindow.html#a4c7a6c395eec0bb245cd9ad6c884f897