Le 1 mai 05, à 22:07, Yen-Ju Chen a écrit :
Although it is interested to have this kind of information about
what Etoile will be,
I am more interested in how we can build this kind of environment.
We need to a more detailed diagram about the Etoile for developers,
for example, which framework is build on top of which framework.
The most bottom one is of course GNUstep.
Then what is the framework just above it ?
A compress library and a regular expression library come to my mind
first..
LuceneKit need both of them, and a workspace build on top of
LuceneKit (and others).
So my point is that it is very nice to have this document for users.
We also need a similar document for developers of Etoile.
It's hard to tell the relationship between components
from the existed document on Etoile wiki.
With this kind of diagram, we can also have a progress report
on each component so that people will can when Etoile will be
completed.
Yes, I fully agree with you, our UI discussions are a bit foggy because
of this fact and our incomplete wiki glossary : we need to be sure we
are talking about identical concepts (folder vs project to take a basic
example). I have started to write some design documentation for
frameworks like IconKit, PreferencesKit for example and I created early
diagrams to have a better idea of Étoilé from developer point of view.
I hope I will be able to put them soon on the wiki in an acceptable
state :-).
I think we really need to have a parallel development between what we
want on the user side and how we implement it on the developer side,
because they are lot of interesting ideas currently discussed but
several UI ideas are out of current Étoilé scope or not doable (mainly
because we are really few developers and we cannot think without
GNUstep inheritance), we shouldn't forget that Étoilé first goal isn't
to rethink desktop environment from scratch at every levels, even if we
could wish to be able to do it in future.
The best we can do is to layout flexible foundations with proper design
documentation in order to be able to refactor them regularly and easily
in future when we will need to move forward.
We also need to accept we will do things in wrong way sometimes too ;-)
because we learn things faster by coding and experimenting (when
discussion is a bit stalled).
I think we are starting to have a good idea of Étoilé at bottom or
middle levels, but we need to sort out problems like :
- how we implement sessions management
- how we implement service/component duality
- how we aggregate components in custom Service/Application tailored
for particular work (thinking about BluTulip, ImageEdit, Text editor
etc. in this context)
- how we handle document bundles (in Étoilé and outside)
- how we fake single address space (in local and distant way)
- how we push forward model objects management in order components
share their data easily with an unified protocol (that could involve
stuff like CoreData, Controller layer, StepTalk etc.).
- how we implement modular persistency (OS persistency vs managed model
objects persistency… CoreData again may be with some extra twists :-)
- which third-parties frameworks we want to include in Étoilé (Regex,
XML, HOM, AppKit extensions, ZeroConf, etc.)
- which parts of GNUstep need improvements or extensions from our side
(hmm look at Cocoa in Panther and Tiger especially) in order to ease
your task and to benefit to GNUstep itself
- which parts of GNUstep we are going to support but to phase out for a
better or more adequate solution (NSFileManager for example)… what we
can do to have a compatibility layer with Cocoa on Mac OS X for theses
evolutions.
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
