Hi all,
I'm planning to reorganize frameworks to make things more logical and
cleaner manner. Thereby this should allow to reduce reorganization in
future.
- AddressesKit --> rename the module probably. Better to avoid plural
form. May be AddressKit. For the real frameworks located inside in
the module, we can keep Addresses and AddressView.
Use AD prefix. It could be better to replace it by NS to match Cocoa
API, not sure it's needed though.
- BookmarkKit --> no changes planned
Use BK prefix.
- CollectionKit --> no changes planned
Use CK prefix.
- LuceneKit --> no changes planned
Use LC prefix.
- IconKit --> no changes planned (not usable currently though)
Use IK prefix.
- OgreKit --> no changes planned
Use OG prefix.
- PreferencesKit --> rename it PaneKit (some improvements needed too)
Would continue to use PK prefix.
- RSSKit --> no changes planned
Use RSS prefix.
- ServicesBarKit --> no changes planned, we could rename it
ServicesBar since it provides few features (not yet finished)
Use SB prefix. May change the prefix to UK or ET since this framework
cannot be used outside of Etoile
- UnitKit --> no changes planned
Use UK prefix.
- XWindowServerKit --> no changes planned
Use X prefix.
- EtoileExtensionsKit --> split in three separate frameworks:
- EtoileFoundation for Foundation-based classes
- EtoileUI for AppKit-based classes
- DistributedView for UKDistributedView/UKFinderIconCell classes
(the only GPL classes in the framework currently, then not compatible
with its dual BSD/LGPL license)
I have modeled the new framework names against common Cocoa-based
frameworks terminology.
UKDistributedView would keep the prefix UK. The two other frameworks
would use either UK or ET, unless we decide to keep only one, not
sure it's worth the trouble.
- ExtendedWorkspaceKit: --> rename it EtoileKit, ServiceKit or
something else… this framework includes in theory everything which is
specific to Etoile (like project management, indexing/searching, UI
server for system-wide dialogs etc.) and cannot be used in another
environment (unlike EtoileFoundation and EtoileUI). Perhaps it would
be simpler at least initially to get rid of it by splitting its
classes between, EtoileFoundation, EtoileUI and CoreObject. Anyway it
should be severely rewritten since its design doesn't match current
Étoilé architecture anymore.
Probably move to ET or UK prefix, it's currently EX.
Two new System related frameworks have to be written
- SystemConfig --> to handle system configuration/preferences and
monitor system events (like network interface/connection, media/disk
mount and unmount etc.) with a daemon. This framework would be used
directly by Hardware, Look & Behavior, Network & Internet preference
applications.
- SystemCore --> put classes to interact with System daemon, sessions
etc. I will move some System module classes into this framework.
Both frameworks would use the prefix SC.
And another couple of frameworks have to be written for Security
handling. We could adopt Cocoa API and extend it to fit our needs:
- SecurityFoundation (should include something similar to keychain
and a security daemon)
- SecurityUI (should include a securityUI daemon providing the
necessary security related dialogs like authentification).
Here are Cocoa API related links: <http://developer.apple.com/
documentation/Security/Reference/AuthServicesObjCRef/index.html> and
<http://developer.apple.com/documentation/Security/Reference/
SecurityObjectiveC/index.html>
that's it :-)
Cheers,
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
