Re: FHS compliance/Abstraction of NSBundle

[Serg Stoyan]

-----Original Message-----
From: Richard Frith-Macdonald <address@hidden>
To: Gregory John Casamento <address@hidden>
Date: Tue, 9 May 2006 16:43:35 +0100
Subject: Re: FHS compliance/Abstraction of NSBundle

> 
> On 9 May 2006, at 14:40, Gregory John Casamento wrote:
> 
> > 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.
> 
> I guess we must be talking at cross-purposes somehow ...
> I was making a few points ...
> 
> 1. NSBundle provides us with an abstraction layer already ... there  
> is no point in providing another abstraction layer internal to it as  
> anyone can simply subclass it to do different things.  From that  
> point of view, your comment above about NSBundle making assumptions  
> about where resources are seems irrelevant ... as any subclass may of  
> course provide the same api with different assumptions about how it  
> implements it.
> 
> 2. It makes sense to identify real word issues where alternative  
> NSBundle implementations would be important (eg all resources  
> actually residing in a compressed archive) and have someone who is  
> interested in one of them do an implementation to handle that case.
> 
> > 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.
> 
> The filesystem layout of programs under windows is hugely variable/ 
> inconsistent, and most users don't care about where their programs  
> keep resources they use (as long as it all uninstalls properly).
> 
> However, for a *modern* windows system Microsoft supply a standard  
> installer, so most modern applications do in fact install in a  
> standard way.
> This standard behavior is to have the installer executable create a  
> subdirectory in the 'C:\Program Files' directory in which the program  
> and resources are stored.  This application subdirectory often (but  
> not always) has its own subdirectories so that only the executable  
> and DLLs reside in the main application directory.
> 
> This is of course exactly the same sort of setup as an app wrapper /  
> bundle in GNUstep!
> The most important thing is to have your application bundled up  
> inside an installer ... and the installer would normally put the app  
> wrapper in 'C:\Program Files' and create a shortcut to the executable  
> so users would never look in the app wrapper at all!
> 
> In other words, if we want to conform to the most common behavior on  
> windows, you want to use the current GNUstep app wrapper/bundle  
> system all wrapped up inside an executable installer script.  This  
> obviously doesn't effect NSBundle at all, but ideally the gnustep- 
> make package would have an option to turn an application into a self- 
> installing executable.
> 
> All that being said ... a few people are unhappy about multiple file  
> installations ... so an NSBundle subclass to work with a compressed  
> archive would be interesting.
> 
> 
> 
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnustep-dev
> 
>