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