-----Original Message----- From: Richard Frith-Macdonald <[EMAIL PROTECTED]> To: Gregory John Casamento <[EMAIL PROTECTED]> 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 > [email protected] > http://lists.gnu.org/mailman/listinfo/gnustep-dev > > _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
