-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2005-03-22 15:50:46 +0000 Nicola Pero <[EMAIL PROTECTED]> 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-----
_______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
