Le 1 nov. 06 à 21:01, Yen-Ju Chen a écrit :
I propose to move some of the frameworks into EtoileFoundation and
EtoileUI
if there is no extra dependencies and the license is fine (LGPL,
modified BSD, Apache, etc).
The simple reason is that when we start to reuse some of these
classes,
the dependencies become too many.
For example, Grr now depends on RSSKit, BookmarKit, CollectionKit.
It will depend on PaneKit for preference.
I have a copy of gktmozembed which can become GeckoKit
in the future if I can work it out.
And Grr will also depend on it to display HTML.
The dependencies are just too many for people who want to use it.
And I believe it will happen for other applications
when we start to share the code.
Currently, I think only BookmarKit, CollectionKit,
XWindowServerKit and PreferencesKit are qualified.
I can move them into EtoileFoundation and EtoileUI.
I'm in favor of making Étoilé development easier but I don't really
like the idea of merging all these frameworks together.
My main concern about frameworks is to keep them small and focused.
Most of time, they are too big in my opinion (I mean in general, not
speaking about Étoilé frameworks).
Having frameworks with too many classes make understanding the
purpose of the frameworks and the class relationships harder. In my
opinion, browsing class documentation is also more pleasant when the
number of classes doesn't exceed 10 or 15.
Merging all these frameworks would also complicate reusability
outside of Étoilé. For example, I currently use PreferencesKit in a
personal Cocoa project and I wouldn't like to embed the whole
EtoileUI and EtoileFoundation into it. Well I could copy the classes
I'm interested in and just bypass the framework, but this defeats
framework/library purpose.
I think the solution is either to add an umbrella framework like
Cocoa on Mac OS X. Or to add an umbrella header in the project you
maintain, then you just got to two files to modify : GNUmakefile for
the frameworks to be linked and the umbrella header for the
frameworks import.
Example of an umbrella header named: Etoile.h
#import <Foundation/Foudation.h>
#import <AppKit/AppKit.h>
#import <EtoileFoundation/EtoileFoudation.h>
#import <EtoileUI/EtoileUI.h>
#import <PaneKit/PaneKit.h>
#import <RSSKit/RSSKit.h>
#import <CollectionKit/CollectionKit.h>
#import <BookmarkKit/BookmarkKit.h>
then you just have one import statement in the headers of your
project : #import "Etoile.h"
For the umbrella framework idea, just create dummy library which
links Étoilé frameworks that make sense to provide by default. And
package this library with the previous umbrella header example.
And I think we should use other prefix than UK for EtoileFoudation and
EtoileUI because it doesn't match.
Something like ET, EL, or just E would be fine.
Any comment ?
Even if UK doesn't match, it's not a really a problem in my opinion.
NS doesn't match either with GNUstep or Cocoa ;-)
If many people really think we should move to ET or something like
that, we may consider the move though.
Aside of that, we could try to reduce the number of framework
prefixes a bit. Moving from PK to UK to take an example. But to take
an another example, I think trouble will arise if any CollectionKit
based frameworks adopt CK prefix (thinking of conflicts between
BookmarkKit and CollectionKit).
The UnitKit can also be in EtoileFoundation.
Actually, the unitkit.org is dead.
We are the maintainer now.
But it comes with ukrun.
I have no idea how to fit it into EtoileFoundation ?
Just create a subproject for tools ?
I'm not sure it's really interesting to fit it in EtoileFoundation,
it makes sense as a standalone framework.
By the way, the EtoileExtensionKit is still in SVN.
Should we remove them ?
There are some projects depending on it like DistributedViewExample,
we need to find and update them before removing it.
Cheers,
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
