Re: FHS compliance/Abstraction of NSBundle

[Serg Stoyan]

-----Original Message-----
From: Gregory John Casamento <address@hidden>
To: Richard Frith-Macdonald <address@hidden>
Date: Tue, 9 May 2006 06:40:36 -0700 (PDT)
Subject: Re: FHS compliance/Abstraction of NSBundle

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