On 11/2/06, Quentin Mathé <[EMAIL PROTECTED]> wrote:
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.
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. :)
[snip]
> 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.
Well, I still in favor of libraries. :)
But I see no reason to change it how.
> 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.
I see.
I cannot get PreferencesKit to work on GNUstep and Cocoa.
But since you mention you are using it,
I guess I better to create a branch to work on it.
You want to name to be PaneKit or PanelKit ?
I found this one interesting:
KBPalettePanelExample
http://www.literatureandlatte.com/freestuff/index.html
and this one:
http://www.positivespinmedia.com/dev/PSMTabBarControl.html
Yen-Ju
Cheers,
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
