Re: The future of session management in GNOME



Bastien Nocera wrote:
On Mon, 2006-09-11 at 11:35 +0200, Rodrigo Moya wrote:
On Thu, 2006-09-07 at 00:25 -0400, Havoc Pennington wrote:
I do think the XSMP state-saving model is absurd and should be ignored, however, even if XSMP is used for logout notification.

yeah, I would even completely remove the state saving thing :-)

In fact, how many GNOME apps do the state-saving correctly (whatever
that means)?

I know quite a few that do, and I spent a lot of time adding the
feature, and fixing it in Totem. I don't think that removing it would be
a good idea, unless there is a way to recycle that feature into an
application-specific state saving.
I think it makes the most sense to do this on the application level and perhaps there's some kind of shared code that different applications could use to do this. If I remember correctly Evince looked at Gedit in order to get an idea of how the state saving system was used such that the page, zoom level and other properties could be kept. Keeping application state really makes the most sense to be done at the time you're interacting with the application. If you've edited a file just a bit and then forgot it in another workspace for a while, by the time you log out you'll have to recall exactly what you did to that file in order to make the correct choice of save / don't save. It's much better to keep the context of the situation when asking a question like that, or even better if you don't ask that kind of question. The problem isn't so simple, but it's a problem all of us deal with so we might as well try to fix it at least for ourselves.

In order to keep state properly in this manner a lot of applications that weren't originally designed to do this have to change how they interact and work. Often this is when architecture astronauts propose the database file system or RCS file system, and sure that could help the problem in some ways but you're also introducing new issues while still having to deal with the same situations as before. I would take a simple start by looking at how each application could keep it's state in a way that makes the most sense and form a common library around the applications that are doing this. Once we have this initial concept ironed out a bit we could move on to bigger and better ways of solving the problem later.

~ Bryan



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]