Hi! On Thu, Nov 02, 2006 at 10:26:42AM -0800, Yen-Ju Chen wrote: > >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. > > I personally agree with you. > But when Etoile becomes bigger and bigger, > installing all the dependencies will be an issue. > Using GNUstep as example, > if Foundation is split into network, file manager, basic data > structure, runloop, etc, > people will start complain about it because most application > will use more than one part of it. > Anyway, maybe it is too early to discuss it for Etoile. :)
In my opinion, it's not too early to discuss that. >From the past I know that getting applications into a Linux distribution can require you to wait for a long time until the distribution maintainers approve it. Since every dependency to an application usually ends up being an extra package, this wait gets longer with each dependency. (That's the reason why RSSKit is packaged into the same Debian package as Grr.) As some Etoile frameworks are far from stable at the moment, and I really don't expect any distribution to include them all at this stage, I think we need to find a way to deploy our applications independent from Etoile. Of course I don't mean removing Etoile dependencies, but offering a way to include Etoile frameworks into the applications in an easy way. (One aspect to that is to have alternative GNUmakefiles, as we can't expect people to check out the whole Etoile repository to build a single application.) This does not only allow us to deploy our own applications, but it also makes the decision to use Etoile frameworks easier for other GNUstep developers. The deployment is a crucial part in the software lifecycle, we should not ignore it. :-] -Guenther _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
