-----Original Message----- From: Lars Sonchocky-Helldorf <[EMAIL PROTECTED]> To: Gregory John Casamento <[EMAIL PROTECTED]> Date: Tue, 9 May 2006 18:14:07 +0200 Subject: Re: FHS compliance/Abstraction of NSBundle
> > Am 09.05.2006 um 15:40 schrieb Gregory John Casamento: > > > 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. > > Why not put the whole thing into a (uncompressed?) zip wrapped with > some thin starter shell that does the application start up - much > like those self extracting zips where the extracting functionality > would be replaced by the starter shell. So we would get a single file > executable. > > > > > Later, GJC > > -- > > Gregory John Casamento > > > > ----- Original Message ---- > > From: Richard Frith-Macdonald <[EMAIL PROTECTED]> > > To: Gregory John Casamento <[EMAIL PROTECTED]> > > Cc: GNUstep Developers <gnustep-dev@gnu.org> > > 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 > > Gnustep-dev@gnu.org > > http://lists.gnu.org/mailman/listinfo/gnustep-dev > > _______________________________________________ > > Gnustep-dev mailing list > > Gnustep-dev@gnu.org > > http://lists.gnu.org/mailman/listinfo/gnustep-dev > > > > _______________________________________________ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > http://lists.gnu.org/mailman/listinfo/gnustep-dev > > _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev