Re: FHS compliance/Abstraction of NSBundle

[Richard Frith-Macdonald]

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.