Hi, as tracked in tickets #4088 and #6014, there are two situations where the user can loose data inadvertently:
- user shutdowns from the system menu, - laptop shutdowns unexpectedly because the laptop runs out of power or the user pressed the power button. Most activities are saving their state in the background when the user switches to another activity, so in most cases the data loss will be limited to the current active activity, since the last explicit or implicit save. But this is probably not enough, as exposed by the reporter of #6014. In order for activities to save their state before the system cleanly shuts down, we could use XSMP. We really don't need all that is in that spec, specially the stuff about local and global state (our state is always global). http://www.xfree86.org/current/xsmp.pdf We would need a session manager that synchronizes how clients save their state and exit cleanly before the shutdown happen. That session manager, be in its own process, matchbox (if there is already one in there) or the sugar shell. We could use an existing implementation of XSMP like gnome-session, but people seem to agree in that its code is horrible and a complete replacement is needed. http://svn.gnome.org/viewvc/gnome-session Follow two tentatives at rewriting gnome-session: http://svn.gnome.org/viewvc/gnome-session-manager http://svn.gnome.org/viewvc/msm Also, there has been some discussion in freedekstop lists about ditching XSMP and establishing a new standard based on D-Bus. Has been suggested at some point that activities save before suspend. Is this really needed? Do we want to make longer the time we need for suspending? If OHM would wake up when the battery reaches a critical level in order to initiate a clean shutdown, then we wouldn't need to consider this as an special case. Summarizing, I see three possibilities: - Adopt a full-fledged implementation of XSMP and ask activities to support just the save-on-shutdown part of it. (Giving a nice wrapper at least for python activities). - Implement a subset of XSMP in a new session manager implementation. - Add a couple of D-Bus methods and signals to OHM/HAL, the sugar shell and the activity service enough to support what we need. Note that I'm talking about the short term here. What we should aim for given the scarce resources we have, not what we ideally would do. Comments? Thanks, Tomeu _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel