Re: FHS compliance/Abstraction of NSBundle

[Serg Stoyan]

-----Original Message-----
From: Lars Sonchocky-Helldorf <address@hidden>
To: Gregory John Casamento <address@hidden>
Date: Tue, 9 May 2006 18:14:07 +0200
Subject: Re: FHS compliance/Abstraction of NSBundle

> 
> Am 09.05.2006 um 15:40 schrieb Gregory John Casamento:
> 
> > Richard,
> >
> > My apologies for the top post, but the developers of the Yahoo beta  
> > Mail application don't seem to realize that people sometimes want  
> > to comment inside, or indeed below, a previous email. :)
> >
> > NSBundle does make some assumptions regarding where the resources  
> > might be.  For instance, it looks in the language directories for  
> > different nibs.   It also assumes that the app wrapper or bundle  
> > has a Resources directory.   What I'm proposing is to have a  
> > further level of abstraction to allow for layouts which are vastly  
> > different from the .app wrapper.
> >
> > Another possible application of this idea is on GNUstep for  
> > Windows.  If GNUstep is to be widely used on Windows, it would be  
> > better if it conformed to something that Windows users are used to  
> > on that platform.  If you look at iTunes for Windows, you'll see  
> > that it has an iTunes executable and an iTunes.Resources folder in  
> > the folder where iTunes resides.   While I realize that iTunes on  
> > Windows is a Windows application, I think that this layout would be  
> > a good thing to have for GNUstep apps because windows users will  
> > be, understandably, confused when trying to invoke a GNUstep  
> > application from Explorer especially if they have to navigate  
> > within an app wrapper to do so.  We need to provide them with  
> > something that is familiar.
> 
> Why not put the whole thing into a (uncompressed?) zip wrapped with  
> some thin starter shell that does the application start up - much  
> like those self extracting zips where the extracting functionality  
> would be replaced by the starter shell. So we would get a single file  
> executable.
> 
> >
> > Later, GJC
> > --
> > Gregory John Casamento
> >
> > ----- Original Message ----
> > From: Richard Frith-Macdonald <address@hidden>
> > To: Gregory John Casamento <address@hidden>
> > Cc: GNUstep Developers <address@hidden>
> > Sent: Tuesday, May 9, 2006 4:12:37 AM
> > Subject: Re: FHS compliance/Abstraction of NSBundle
> >
> >
> > On 9 May 2006, at 03:21, Gregory John Casamento wrote:
> > >
> > > 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.
> >
> > I don't think it's a bad idea ... but it's probably one which is
> > 'waiting for an application'.
> >
> > I remember discussing this about a year ago, with reference to
> > monolithic distribution of an app on windows ... the idea was to put
> > all resources inside a single zip image linked in to the executable,
> > so that you could access the resources via NSBundle as normal, but
> > everything would actually be in a single executable which could be
> > copied and moved around very simply.  The NSBundle would uncompress
> > data files into a temporary directory on demand.   Anyway, that's one
> > possible application.
> >
> > However ... as decoupling from the underlying bundle structure is
> > precisely what NSBundle does anyway, there does not seem to be a need
> > for extra generic code to support it.  You access things via NSBundle
> > rather than doing them directly, so subclassing NSBundle lets you use
> > any representation you like for the data stored in the bundle.  If
> > people needed alternative storage formats they could easily support
> > them that way, so I guess nobody has really needed them (after all,
> > the default format is really simple).
> >
> > So ... if we have a concrete application that's reasonable important
> > to devote time to, it would be good to code an NSBundle subclass to
> > handle that application and add makefile extensions to package up
> > resources in the manner the new bundle expects.  Handling a
> > compressed archive seems the obvious first choice.
> >
> >
> >
> > _______________________________________________
> > Gnustep-dev mailing list
> > address@hidden
> > http://lists.gnu.org/mailman/listinfo/gnustep-dev
> > _______________________________________________
> > Gnustep-dev mailing list
> > address@hidden
> > http://lists.gnu.org/mailman/listinfo/gnustep-dev
> 
> 
> 
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnustep-dev
> 
>