gnustep-dev
[Top][All Lists]
Advanced

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

Re: More Windows stuff ... Gorm works ... sort of


From: Richard Frith-Macdonald
Subject: Re: More Windows stuff ... Gorm works ... sort of
Date: Tue, 22 Mar 2005 15:26:21 +0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2005-03-22 15:50:46 +0000 Nicola Pero <address@hidden> wrote:

Btw, I think you both missed my point ;-)

.... if an application is built using "simple" / "standard" mechanisms
(like: building a shared library, building a bundle, linking an object
file to a shared library) then porting to new platforms will be easier,
because once those "standard" mechanisms are implemented, your application
will be automatically ported.  Linking a loadable bundle against an
application is always going to be implemented *after* linking a loadable
bundle against a library.  So if you depend on support for linking against
a library (rather than on linking against an application), the stuff is
more easily portable.

You are correct ... I did miss that point.

But I think that linking against the application is of the essence of a
bundle, so while it may be harder to port, it is necessary.  From the point
of view of a developer using GNUstep (rather than someone
maintaining/writing the gnustep core) the correct behavior of bundles is
something that should just be assumed.  In other words, I don't think this
is an issue that Gregory should need to consider in his design, rather it's
an issue that we need to resolve in make/base so that he and others like him
can work productively.

Finally I don't understand why those palettes are loadable palettes at all
(and are not just linked directly into Gorm) if they access Gorm internals
directly so heavily ... why don't you link them directly into Gorm ?
Then building Gorm on a platform would only depend on shared libraries and
applications, and would be really easy to port ...

I don't know the current design ... but I can answer from a historical
perspective.
When I wrote the standard palettes, they used only the public API to access
Gorm and didn't depend on special access to the internals (I don't know if
that's still the case).  They were written as palettes precisely so that I
could test that palette loading worked and that the public API from Gorm
worked to let people write their own palettes.  A secondary (minor) reason
... which is doubtless still valid, is that using a single mechanism to
locate and load palettes is cleaner/simpler design than using two
mechanisms.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using the GPG bundle for GNUMail

iD8DBQFCQDkdE6AJp3nmKIkRAkZyAKCZFTSH92VMH1lXKHAEChJAIFtjsgCfRRSU
txxFIGmaKaZb3kz0CXrJTv0=
=E3gG
-----END PGP SIGNATURE-----





reply via email to

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