All,
While discussing various ideas with other GNUstep developers today there were a number of ideas that I felt were good,
FHS Compliance
==============
I believe that it's useful to allow GNUstep to support an FHS
compatible layout for the libraries. Currently, everything that is in
/usr/GNUstep could live in various places in the FHS layout. We could
have Foundation and AppKit in the /usr/local/include directory, the
libraries in /usr/local/lib and the resources for the libraries in
/usr/local/share. This could be offered as an option for the user at
configuration time. This would allow the deployment of GNUstep in an
FHS compatible fashion.
The FHS layout has the advantage of not requiring the user to run any scripts to set up the environment.
NSBundle Abstraction
====================
Why should we be constrained to the .app wrapper?
One of the things which I've done on the NibCompatibility branch is to abstract the model loading mechanism so that it has "loader" classes. Each loader handles a specific type of gui model (i.e. GSGormLoader for gorms, GSNibLoader for nibs and GSGModelLoader for gmodels). Each loader registers itself with a factory class so that the scheme is entirely open and can be easily extended. A similar scheme would be possible to implement for NSBundles.
This would effectively decouple GNUstep from it's bundle structure and allow the use of any given bundle structure. This would allow, for instance, people to distribute apps as ".app" wrappers, or in other formats since how the bundle would find its resources would be abstracted into the bundle loading mechanism for each different type GNUstep could support.
Please let me know what
you think.
Thanks, GJC
--
Gregory John Casamento