On 7/17/07, David Chisnall <[EMAIL PROTECTED]> wrote: > On 17 Jul 2007, at 12:29, Quentin Mathé wrote: > > > Subproject doesn't mean necessarily subframework or sublibrary it > > could be purely organizational, but I think subframework is clearly > > better in that case. > > I agree. > > > We should probably have within EtoileFoundation: > > - Headers <-- headers part of metaframework by default > > - Source <-- source code file part of metaframework by default > > Are there any classes that we want to be in EtoileFoundation but not > part of a sub-framework?
There are some small classes in EtoileFoundation now which does not belong to any other things, like UKPuashbackMessenger, which allows you do something like "searching while typing" efficiently. I know how to do subprojects as in LuceneKit (subproject have its own header and source directory), but I am not sure we can do sub-framework with gnustep-make. In another word, EtoileFoundation still complies as a simple framework instead of a abstract framework which links to other frameworks. And if we just build several frameworks inside EtoileFoundation, then it is equivalent to move most framework from Frameworks/ into Frameworks/EtoileFoundation/. It is not really an improvement. > > We definitely want an EtoileFoundation/EtoileFoundation.h that will > include everything for us. > > > - EtoileXML/Headers > > - EtoileXML/Source > > - EtoileThread/Headers > > - EtoileThread/Source > > I'll re-arrange the sources in these frameworks to match this pattern. > > > I think we have GPL2 applications like Grr, Vindaloo that use > > EtoileFoundation. > > Are they GPLv2, or GPLv2 'and later' ? Azalea is GPL v2 and later. MenuServer is GPL v2 and later. System is LGPL v2 and later AddressManager is LGPL v2 (not clear). Components in Grr is GPL2 (no later). Vindallo is GPL2 or later. > > > I would prefer to keep it GPL2 compatible easpecially for the > > following reason, EtoileFoundation is linked by EtoileUI which in > > turn will be linked by a new framework EtoileKit implementing high > > level Étoilé specific concepts and UI behaviors. So all Étoilé > > applications are going to link at least these three frameworks on > > release 0.3. > > The problem is to find the right balance between dependency chain, > > reusability/sharing and features worth to provide by default. > > At some point, I will post another mails about upcoming framework > > organization, EtoileKit, Container etc. > > So, we shall say that we intend to keep the core frameworks all GPLv2 > compatible? > > > Yes. The framework naming rules are (I mean the ones I use until now > > in an instinctive way :-): > > - low level key system framework uses Core like CoreObject, > > SystemCore or SecurityCore > > - low level system framework which are less central can use System > > like SystemConfig, SystemShare or SystemLDAP > > - low level framework packaging classes which aren't UI or system > > related uses Foundation like EtoileFoundation or AddressFoundation > > - framework packaging mostly views or UI elements related classes > > uses UI like EtoileUI, AddressUI or SecurityUI > > - big Foundation-style framework without UI counterpart, framework > > mixing UI/Foundation stuff or framework that doesn't fit in another > > category uses Kit like EtoileKit, OgreKit, MultimediaKit, > > CollectionKit or LuceneKit > > - small framework that handles only little things and cannot be > > broken in Foundation/UI style framework uses Etoile prefix or no > > prefix/suffix, like EtoileThread, DistributedView (only one view > > class) > > > > Let me know about your criticisms and suggestions. I plan to update > > HACKING document with these rules. > > These all seem sensible. > > > Some frameworks don't conform to these rules yet. We may fix some of > > them when it makes sense as we go along. > > After 0.2, can you make a list of all of the frameworks that don't > meet these guidelines, and we can try to tidy them all before 0.3? > Since 0.3 is meant to be for improving the UI, let's try to improve > the UI for developers too. > > > For prefix, the default prefix is ET for classes but its use should > > be reserved to EtoileFoundation, EtoileUI and EtoileKit. It should be > > used in any subframeworks of the previous ones or any frameworks with > > Etoile prefix/suffix in its name. For all other frameworks, using a > > distinct prefix should be the rule. > > Okay. > > >> Do we even have a guideline > >> for this yet, or are we still making it up as we go along? > > > > Now we have an official one under evaluation ;-) > > I'll take that as a 'we're still making it up as we go along' ;-) > Another thing is that maybe TRXML and EtoileSelialize can use UnitKit for testing instead of its own testing facility. Yen-Ju > David > _______________________________________________ > 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
