[haiku-development] Re: session manager
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 27 Jun 2011 23:25:43 +0200
Clemens <clemens.zeidler@xxxxxxxxxxxxxx> wrote:
> On Sun, 26 Jun 2011 03:15:39 +1200, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
> >
> wrote:
> > Clemens<clemens.zeidler@xxxxxxxxxxxxxx> wrote:
> >> here is short proposal for a session manager api. Had a session
> > > manager
> >> already working some time ago but there have been some feature
> > > requests:
> > Not just that, though. I think such a change would also be quite a
> > lot
> > to tackle before R1; if the feature cannot be implemented
> > consistently,
> > it shouldn't be implemented (see Gnome, where session management is
> > completely useless and annoying on top).
> what is the problem in Gnome? what does not work?
Not all applications support it, some don't support it correctly. The
outcome is that only some applications are restored on launch, and some
forget their window position and/or workspace, or contents.
> >> virtual status_t RestoreState(const BMessage*
> >> state,
> >>
> >> BSessionAppReadStorage* storage);
> > I don't get BSessionAppReadStorage/BSessionAppStorage besides that
> > the
> > naming is bad.
> right, not happy either, maybe merge both classes?
That would be something I'd do, yes. If the profile thing is getting in
there as well, the naming would need to be more generic, too. Maybe
something like BApplicationState.
> >> when leaving the SaveState method. HasBeenAborted indicates if the
> > > user
> >> cancelled the shutdown process.
> > This should rather become a two stage thing, I think. First make
> > sure
> > all apps are ready to shut down, then let them store their state.
> > Besides, if the app stores its state, there is no reason to let it
> > abort
> > the shutdown.
> Why not? if the user cancelled the shutdown also the save state could
> be
> cancelled. Furthermore, saving the state should be possible at any
> time
> not only when shutting down.
Session management is hibernation implemented in userland: it should
preserve the complete application state just as if you actually did
hibernate. IOW there is no need to let an application prevent having
its state written down (if it supports the feature). Also, this means
an application should always store its complete state including undo
history, etc.
Therefore, each application could be informed of a system shutdown, and
if it doesn't object, its state could be stored as a second step. A
reason to object could be a download in progress, a CD that is
currently burned, or whatever else that wouldn't like to be interrupted
this way.
I like the profile extension as well, but I fear it won't be easy to
get right, especially with making it persistent, too (ie. which windows
of Tracker belong to which profile? If you open new windows while having
two or more profiles active which is going to be the new owner of those
windows?). Having a strict per workspace policy for profiles might be a
good idea to solve those issues (which would reduce the options Ingo
proposed to "current" and "as saved").
Then, it would be nice to have half-state profiles, that just store the
open windows to be able to easily copy the state to another system. In
that light, it would be nice if the profile with all BApplicationStates
would end up in a single zip file.
Bye,
Axel.
Other related posts:
