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