Le 4 avr. 07 à 10:55, Nicolas Roard a écrit :
On 4/4/07, Isaiah Beerbower <[EMAIL PROTECTED]> wrote:
Hello all!
I have some thoughts concerning the future design of Etoile.
To start out I'll mention that this email references discussion
from the
chat room. Most of it will be from the conversation in David
Chisnall's
"No More Files!" email.
I think we should eliminate applications all together. It seems that
almost all of them have been eliminated. If we keep just a few of
them,
they'll be awkward for the user, as well as stick out terribly.
Some applications cannot be eliminated like Games, Workflow (the one
you're working on) etc.
There was a problem discussed in the chat room: Since services are
bundles, and bundles can't be unloaded, we'd end up with a bunch of
loaded bundles which are taking up memory.
And compromising stability.
A work around was to try and
load an application like a bundle. This however would need to be
hacked
into shape, and would end up with bad results.
It doesn't end up with bad results necessarily. More below…
I propose (please tell me if this is a stupid idea) that we have
services be, well, services. Instead of using a bundle they would be
similar to an application, but not an application. If I am correct,
applications get their behavior from the NSApplication class. I
propose
we create our own class (EtoileService) and a new function
(EtoileServiceMain) to start the run loop. This way we could
define our
own behavior for services. EtoileService would have some sort of
integration with NSDocument (or, probably, EtoileDocument) to give
the
document oriented behavior.
There would probably be one service for each main data type.
Extensions
in the form of bundles could be loaded into these separate services.
When all documents using the service are closed, the service is
shutdown
and the bundles go with it.
It's not a bad idea at all :-)… That's almost identical to what is
planned. I think it's already discussed on the wiki and/or list
archives as Service/Component duality.
A service component can be launched by a double-click like an
application or it can be loaded in another process like a bundle.
In the former case, we start the run loop of the component, in the
latter case we don't.
A simple component can only be loaded like a bundle, that's what you
name "Extensions in the form of bundles".
What you describe involves several issues related to the fact today
operating systems don't use a single memory address space, but rather
rely on protected memory space per process. You can find detailed
discussions of these issues on etoile-dev or etoile-discuss archives
(probably in 2005 and 2006). Discussion revolves about technical
questions like… How can we can we move a document to a new owner?
Should document run in their own process or not?
In getting rid of applications we would also get rid of windows.
All we
would have are documents and panels.
Panels are windows and Document windows are windows too :-)
I also think preference panels
should be eliminated. To change preferences you would open the
preferences document (since that's what they are, documents). A
service
would include a plist file describing what preferences there are
and how
they are to be edited.
Some Mac OS X applications might already support double-cliking their
preferences files to edit it by opening the application and the
related preference panel. At least it's possible to code it that way.
It sounds like a different way to code preferences save and load, but
that doesn't really eliminate Preference panels since they are still
needed. Unless you want to remove preference panels UI and replace it
with a plist editor (that uses a simple outline view) but it wouldn't
be friendly at all ;-)
I'm not sure about the "let's get rid of prefrences panels" -- it
seems to me more an etymologic change (let's call them preferences
documents!) than a real technical change.
I agree.
On adding more "pickers" it's a good idea. Not sure about a calculator
one, but a date/time picker would be neat, yes. Other "pickers" idea ?
No other ideas right now :-)
(ps: I didn't answer to david's mail -- but basically I entirely agree
with him, files are bad. The only problem I have is how long will it
takes us to do it, and what should we do in the meantime)
Ditto.
Cheers,
Quentin.
_______________________________________________
Etoile-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-discuss
