[haiku-development] Re: session manager
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 12 Aug 2011 12:37:07 +0200
On 2011-08-12 at 00:31:35 [+0200], Clemens <clemens.zeidler@xxxxxxxxxxxxxx>
wrote:
> On Thu, 11 Aug 2011 18:54:21 +1200, Stephan Aßmus <superstippi@xxxxxx>
> wrote:
>
> >>> *push* did this actually reached the list last time? there have been no
> >>> messages on this WE, was freelist down?
> >>
> >> Your message made it through, but I guess no one responded. My opinion
> >> is to commit your change.
> >
> > All I remember is that the original proposal raised some substantial
> > discussion. When I saw the new mail, I was wondering how it could
> > address the raised issues, but didn't have time to look at it closer and
> > I don't remember all the concerns either. I would not commit it if it
> > doesn't take the discussion back then into consideration much. Perhaps
> > it would help me and other people with very little Haiku time right now,
> > if you could outline the changes made to the code in reference to (a
> > summary of) the issues raised in the original discussion.
> >
>
> 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.
> For simplicity, I would not differentiate to much between different use
> cases like profiles or deep session states.
That's really the wrong way around to implement a feature. Without
considering all the requirements it's virtually impossible to create an
interface that will respect them. Various ideas have been brought in the
discussion. I guess a first step would be to develop a consistent vision of
how things should work (from a user perspective).
> I think its already a bit
> annoying for the standard application developer to implement save and
> restore functions especially if they are not essential for a usable
> application. Because of that there should only the option to save the
> state as good as possible and to restore a saved state as good as
> possible. The only differentiation at the moment would be to provide a
> BApplicationState object that optional provides access to a session
> specific BIOData storage.
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.
> 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).
On 2011-08-12 at 00:57:07 [+0200], Clemens <clemens.zeidler@xxxxxxxxxxxxxx>
wrote:
> On Fri, 12 Aug 2011 03:52:41 +1200, Ingo Weinhold <ingo_weinhold@xxxxxx>
> wrote:
> >> If session management is disabled on the default I see no problem to
> >> commit into trunk,
> >
> > Yeah, and we know how well that worked with the locale kit. Now we have
> > an
> > implementation that is far from being ready for prime time, thus being
> > another blocker for R1, since we can't really remove it anymore. I'm sure
> > the same will happen with any somewhat working feature, regardless of
> > whether it is really ready.
>
> but it involved many people to work on haiku who would not have been
> involved otherwise.
> Theoretically we could just remove the local preferences from the images
> to disable the local kit again and fix the R1 blocker ;-)
Technically that would be feasible. Politically it isn't, particularly since
so many people were involved, who would, understandably, be disappointed.
CU, Ingo
Other related posts:
