gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FHS compliance/Abstraction of NSBundle


From: Gregory John Casamento
Subject: Re: FHS compliance/Abstraction of NSBundle
Date: Tue, 9 May 2006 06:40:36 -0700 (PDT)

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 <address@hidden>
To: Gregory John Casamento <address@hidden>
Cc: GNUstep Developers <address@hidden>
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
address@hidden
http://lists.gnu.org/mailman/listinfo/gnustep-dev

reply via email to

[Prev in Thread] Current Thread [Next in Thread]