Re: Gomoku.app ported to Mac OS X

[Richard Frith-Macdonald]

On Thursday, January 24, 2002, at 09:45 AM, Dirk Theisen wrote:

> Hello, Nicola!
> Hello, Lars!
>
> > > Nicola Pero, are you listening? Do you still maintain Gomoku.app?
> > > Aren't  you interested to incorporate the changes into the main
> > > source tree?
> >
> > Sorry for always answering late.
> >
> > The application is GNU GPL, so you are absolutely free to distribute
> > your own version :-) as soon as you comply with the terms of the
> > license of course.
> >
> > I'd be happy to incorporate changes allowing the application to run on
> > MacOS-X, if that helps merchandising GNUstep, with a single important
> > restriction - I don't want in my sources any file in a binary
> > proprietary format which I can't read - so no apple binary nibs - you
> > need to make a source-code only port.
>
> I wonder why GNUstep is not simply using the plist format as Apple does 
> for compatibility (and merging in cvs). Here is an example of the 
> "nibtool" commandline tool output used for this purpose. It can also 
> convert plists back into nibs.

Because it would not aid compatibility in the slightest.  The fields 
within the plist and their meanings are
undocumented, and proprietory and reflect the implementation details of 
the objects encoded within
the plist.  GNUstep would have to reverse engineer it and write custom 
encoding/decoding methods for each
class that could appear in the list (and possibly change things with 
every release of MacOS-X).

> As I understand it, gmodel is already something similar?

Yes.

> It looks like an nibtool plist reader could be created in a generic way 
> using keyValueCoding (correct me, if I'm wrong).
> Plists can be in XML to be even more "open" and "standard".

No ... because the keys and values used by apple are based on their 
implementation of classes - which differ
from the GNUstep implementation.  We would need to hand-craft 
conversions by reverse engineering apple info.

At some point this may be desirable, but it's a lot of programmer 
resource which could be (IMO) better spent
on fixing bugs, improving performance, and adding important missing 
features.

I'd rather have faster, more reliable graphics/text handling than nibs 
which we can port to MacOS-X for instance.