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? KDE sm is working ok. I would make the session manager optional for now anyway, so it would have enough time to mature. Think, implementing the app functions is a good beginners task to get their hand dirty :)
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?
Each application has a private storage pool assigned where data can be saved by name identifier in a BDataIO object (BFile).I'm not sure if something like that is needed; why not let the app let store its state on its own? We could have a default location for this similar to config/settings.
Thought the same in the beginning. Think Ingo had the idea with the BDataIO and it makes sense to be able to redirect the storage path. For example, it would be possible to store one special configuration and let the session manager always load this state on start up instead of the last shutdown sate. In this way multiple states can live beside of each other. See also the reply to Fredrik's mail. Furthermore, its more convenience for the developer, he does not have to delete old files or think about a path where to store additional files.
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.
Regards,
Clemens
