[haiku-development] Re: session manager

  • From: Clemens <clemens.zeidler@xxxxxxxxxxxxxx>
  • To: "haiku-development@xxxxxxxxxxxxx" <haiku-development@xxxxxxxxxxxxx>
  • Date: Tue, 16 Aug 2011 10:21:34 +1200

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 using
this 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 only
windows 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 because
there 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 state
certainly isn't convenient. E.g. for an application with multiple documents
it 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 a
lot more powerful then BeOS's), IMO it is far too "literal" to be used
directly. E.g. one might want to store a window's state, but archiving the
window 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

Other related posts: