[haiku-development] Re: session manager
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 16 Aug 2011 16:22:34 +0200
On 2011-08-16 at 00:21:34 [+0200], Clemens <clemens.zeidler@xxxxxxxxxxxxxx>
wrote:
> 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.
You might have missed part of the discussion. I'm referring to operations like
storing/restoring all Tracker, Pe, and Terminal windows of workspaces 3 and 4
(which
e.g. comprise a development "session" for some (sub)project) while ignoring the
ones
on other workspaces. If something like this should be supported, either the
application needs to organize the stored data in a well-defined way (so the
session
manager knows how to cut/extract them) or the programming interface needs to
define
what windows shall be stored/restored or, possibly, both.
> 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?
[...]
Not sure what you're talking about.
> >> 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.
I don't think so. E.g. one probably wants to store things like divider and
scroll
positions and selection, which aren't properties of the window and thus
shouldn't be
stored with deep = false. Archive() has a specific semantics (literal and
object
centric) while for session management one would want to store the "essential"
information of the whole hierarchy.
CU, Ingo
Other related posts:
