Re: FHS compliance/Abstraction of NSBundle

[Andrew Ruder]

On Mon, May 08, 2006 at 07:21:04PM -0700, Gregory John Casamento wrote:
> FHS Compliance
> ==============
>  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. 

I don't believe that this should be an option; this should be *STANDARD*
operation.  As I discussed with Greg earlier, I think one problem with
GNUstep is that there is an incredibly large barrier to entry:

    *) Objective-C
    *) Environment scripts to run things
    *) The whole concept of openapp/opentool/etc..
    *) Filesystem layout
    *) Bundles??
    *) Special make package
    *) Floating menus
    *) Non-standard font system
    *) App icons
    *) Confusion on whether GNUstep is a desktop? Window manager?
    Librarise? What is it?!?

Now, for people who *have* used Mac OS X, NeXT, Openstep, whatever, most
of these are no longer barriers, but I'm sorry, the majority of people
have not used *any* of these.  It took me months before I finally gave
into GNUstep raping the conformity of my filesystem. ;)

Now, I understand the strengths/benefits of a lot of the items listed
above, but adoption of GNUstep is quite low for as far along as it is.
The problem is (I believe), that we are asking people to deal with all
of this at the same time; heck, you can't even really use/learn
Objective-C without GNUstep and even if you're not developing, you still
have *tons* of other things to deal with just *using* GNUstep.

FHS compliance (by default) takes care of a lot of this.  If we move to
the said modularized bundle support, even "bundles" can be just files in
/usr/share /usr/lib /usr/share/doc /usr/include etc... Perhaps GNUstep
really should aim to just be a set of libraries; let Etoile and other
desktop projects take care of the desktop issues.  If they want to wrap
GNUstep in the current filesystem layout they can, but GNUstep itself
should be ready out of the box for FHS compliance.

- Andy

P.S. I think this will also boost our adoption into distros incredibly,
GNUstep is not exactly the easiest thing to get into a distro due to its
non-conformity.

> 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.

P.P.S. Excellent work on the Nib loading stuff so far.  It will be a
great boon to GNUstep. :)

-- 
Andrew Ruder <address@hidden>
http://www.aeruder.net