On 5/10/06, Günther Noack <[EMAIL PROTECTED]> wrote:
Hi!
Am 09.05.2006 um 01:20 schrieb Yen-Ju Chen:
> Actually session manager will be the project manager for Etoile in
> the future.
Why that?
Considering that the project manager will probably be quite a complex
and experimental application in its first versions, I wonder if it
won't affect the overall Etoile stability if it kills the inherent
session manager on each crash. Wouldn't it be easier to let the
session manager be a minimal tool that is thus mostly bug-free?
What are the reasons both the session and the project manager are
designed to be the same application?
Probably because sessions -- as in, "saved sessions" will be
"projects", for étoilé. And I'm not sure the "project manager" will be
such a complex application anyway -- most of the action will be in the
frameworks.
Anyway, we can start by having a small application that takes a plist
containing a list of applications to start, and start them, why not.
But to implement projects we need a bit more than that; it's perhaps
interesting to have the discussion about projects now then :-)
Basically, what do we want with the projects, and how will they work ?
well, here is my take:
1) Think of a project as if it was a "session" -- you have a bunch of
running applications with opened documents, etc -- basically, a
running state -- and you want to be able to a) quit it and b) reopen
it without losing anything, ie, you want to "freeze" everything then
find it back as it was when you come back.
This is rather close to existing "session management" as done in X11,
apart from the reopening document thing / save state which is
half-baked currently.
2) You want to be able to have more than one "project" open
simultaneously -- in that view, projects behave like virtual desktops
(and they will probably be implemented like virtual desktops)
Solving 1) can be separated in two things:
- manage the applications: get the list of the running apps before
closing a project, and restart the apps when coming back
- manage the state: do the same thing for the current documents/state.
Solving 2) should not be very hard (virtual desktop already exist in
Azalea), but will still lead to some problems: shall we restart
applications already running (that is, have two copies) or not, etc.
I will concentrate on 1) for now on; and "projects" for étoilé will be
stored/manipulated, technically, as normal folders, containing a
hidden directory where we can put any kind of additional metadata we
want (so this is where things like annotation will go, and this is
where the information for restoring the state will go too).
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 ?
--
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
