Re: Cocotron

[Banlu Kemiyatorn]

Richard Frith-Macdonald wrote:
> On 23 Dec 2006, at 19:14, Gregory John Casamento wrote:
>
> > Helge,
> >
> > A quick analysis shows the following things:
> >
> > 1) They are missing many Cocoa classes
> > 2) They do not use native widgets, they draw thier own, like we do.
> > 3) Much of the nib decoding logic which is currently present in 
> > GNUstep is not in Cocotron.  That is to say... there are many cases 
> > that the Cocotron code cannot handle properly when unarchiving Cocoa 
> > nibs.   There are other problems along these lines as well, such as 
> > some classes are missing keys which are needed to function properly.
> > 4) Cocoa compatible keyed nib encoding is entirely missing
> > 5) The only way you can build it is by using Xcode on a mac and cross 
> > compiling it for other platforms, this is a major drawback.
> > 6) Printing appears to be non-functional, or, at least severely 
> > restricted... more so than GNUstep's printing functionality currently 
> > is.
> > 7) The TextEditor example is completely bogus.   None of the 
> > connections in the nib are actually made... none of the menus work.   
> > All it does is bring up a window with an NSTextField in it and look 
> > halfway nice.  Other than that the example is non-functional.
>
> On the foundation side, much is missing too ... distributed objects, 
> xml parsing, streams, url handling etc and also large chunks of 
> functionality of a few classes I looked at.

Well, I was grinning for controllers.

> > I'm quite sure there's more, but the above is just from looking at it 
> > for about 10 minutes. :)   There are, however, a few things that can 
> > be learned from the project... particularly how the code is 
> > organized.   I like the idea of having class clusters in thier own 
> > directories/subprojects, it seems like the right thing to do.
>
> I rather liked that too.

too++;

> > The only reason that Cocotron looks good under Windows, I suspect, is 
> > because it was themed that way.  It likely looks precisely the same 
> > under Linux.
> >
> > It's unfortunate that all of these efforts are going on in parallel 
> > with GNUstep (libFoundation, Cocotron, AJRFoundation) instead of 
> > people getting together and collaborating on one project.
>
> I very strongly agree with that ... it always saddens me to see people 
> re-inventing what GNUstep already does and duplicating effort rather 
> than joining in.  I wish I know how to persuade people to contribute 
> to a joint effort.  Perhaps we should try posting requests for 
> volunteers to all these projects and to any other mailing lists where 
> objc developers might hang out?  I guess we would need to figure out 
> *why* (assuming reasons other than simple ignorance) people do their 
> own thing rather than a group effort, and try to address any mistaken 
> impressions of the project in any email we sent out.  However, my 
> impression is that unfortunately the reason is often either religious 
> differences over licensing/copyright or simple desire for total 
> control over their own project, and no reasoning will convince people 
> in those cases :-(  Even so, it's probably worth a try.

In my opinion, I think their code looks very clean and may be it's a 
good source to point out
the new gnustep developer to check before diving into GNUstep or as a 
reference.
So I think it's not a very duplicating effort and it should strenghten 
the overall OpenStep standard
and drive the market. This kind of project really open more opportunity 
to us!

My friend claims its win32 GDI backend much more responsive than GNUstep's.
May be we could just ste^Wborrow their CoreGraphics subproject so we don't
have to maintain a backend ourselves.

--
 Banlu Kemiyatorn

 Senior Janitor

 Game Square Interactive Co., Ltd.
--