On 5/10/06, Nicolas Roard <[EMAIL PROTECTED]> wrote: [snip]
So... here is my try to show a possible technical path, please, comment it ! For actually getting those projects working... we need to to add the notion of "belonging to project(s)" in the application itself, simply so that we can send a distributed notification to all running applications, for a particular project, and get the complete list of applications. We can perhaps start with adding some methods in NSApplication for that (or in an eventual EApplication subclass, but you get the point). Then, if we can properly discriminate which application is in which project(s), we can implement the first part: stopping them by sending the quit message, and save the list of running application in our hidden metadata directory. Now, we can implement a tool that will be able to take a project, read the metadata, and restart all the applications. When that works, we have a standard session-saving management, and we can move on more interesting/difficult things: saving/restoring the state. For instance, we can use specific methods warning the application to save its state instead of using the generic quit notification. And that's where we hit other difficulties -- not for implementing the mechanism in the "project manager", which is fairly straightforward, but rather, in the applications : saving a running state isn't all that simple... Yet I think we can provide the developer with some methods to facilitate it; possibly for example, a lot of work can be done once and for all for NSDocument-based applications, so that the developer won't need to bother with it, that will be done automagically (from the developer's point of view). Ok... so what we can do to try to save the running state (or rather to approach that) is perhaps to 1) warn applications that the project need to be serialized 2) ask them if they want to save some state, and if so, request a list of opened documents and tell the applications to save them (or save a delta) in the metadata directory, and secondly, ask for a NSData object containing the application "running state" [more likely, some information that the application will need to restore something equivalent -- a real, full serialization is perhaps too heavy]. For example, if we take a text editor (and actually I think we _should_ start with Ink and work from that point), what will it need to save ? Well, obviously the list of opened documents, and the current document state as well. A first implementation could be done by saving the documents directly, a cleverer implementation could take advantage of the NSUndo mechanism to simply save a delta,.. Then, Ink will need to save some "state" information -- eg what are the opened panels, the windows position, the selected font, etc. Some of this information is already saved in the defaults, by the way, but we need to save them per-project, obviously. Ok I stop here... I hope I clarified the path we could take to implement projects in étoilé; obviously things aren't that clean-cut, and that's why I think we should try to implement that step by step: first get a "session management" working; then add the "belonging to a project" tidbit in nsapplication; then try to work out the saving state problem starting with a simple NSDocument application like Ink.app. What do you all think ?
I just explain more on the x session manager. When users logout, session manager will ask each application to save their own state, even the window position. Each application will return a command to session manager so that session manager can start this application again next time. For example, Ink.app might return a command 'openapp Ink.app --load ~/file.txt -line 24' The next time, session simply execute this command. Therefore, applications take FULL responsibility to reload itself. Session manager simply save and execute what applications want it to. Old applications, like xterm, will fail to return this command because it doesn't support session. In this case, session manager will ask window manager to do so. Window manager can save the window state. So the next time session manager load window manager, window manager will load the state of these old applications. Actually GNUstep already did some of these functions. The position of menu is automatically saved and loaded. Window and view can be saved if developers ask for. So it all depends on applications themself. Session manager simply provide a place and protocol to save and load the commands. Yen-Ju
-- Nicolas Roard "I love deadlines. I like the whooshing sound they make as they fly by." -- Douglas Adams _______________________________________________ Etoile-discuss mailing list [email protected] https://mail.gna.org/listinfo/etoile-discuss
_______________________________________________ Etoile-discuss mailing list [email protected] https://mail.gna.org/listinfo/etoile-discuss
