[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Cocotron
From: |
Banlu Kemiyatorn |
Subject: |
Re: Cocotron |
Date: |
Sun, 24 Dec 2006 03:38:45 +0700 |
User-agent: |
Thunderbird 1.5.0.8 (X11/20061116) |
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.
--
Re: Cocotron, Andrew Sveikauskas, 2006/12/23
Re: Cocotron, Helge Hess, 2006/12/23
Re: Cocotron, Fred Kiefer, 2006/12/25
Message not available