Re: FHS compliance/Abstraction of NSBundle

[Lars Sonchocky-Helldorf]

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