Re: Cocotron

[Yen-Ju Chen]

On 12/23/06, Helge Hess <helge.hess@opengroupware.org> wrote:
> On Dec 24, 2006, at 24:35, Gregory John Casamento wrote:
[snip]
> > Etoile is a desktop project which uses GNUstep (see http://
> > www.etoile-project.org/etoile/mediawiki/index.php?
> > title=EtoileWiki:About), not a reimplementation of any part of
> > Cocoa. So, I don't think Etoile even remotely, by the most wild
> > stretch of the imagination possible, fits into the same category as
> > the other things I mentioned.
>
> Possibly. This depends on what GNUstep "is". If its a desktop
> environment, its obviously a fork.
> Now its your task to define what GNUstep is, convince the developers
> and move it forward. If that involves dropping the idea of creating a
> desktop environment and promoting Etoile for that task, its IMHO a
> good idea.

 I would say the desktop part of GNUstep are
 GWorkspace and SystemPreferences, which are absent in Etoile.
 So the redundancy is less comparing to gnustep-base and libFoundation.
 And if necessary, Etoile generally uses bundle to override methods in GNUstep
 to minimize the redundancy.

> > The projects libFoundation, Cocotron and AJRFoundation are re-
> > implementations of Foundation/AppKit. There is no reason, aside
> > from obstinance or ego which should cause so many projects with
> > similar or identical goals to develop things in parallel.  It is,
> > purely and simply, an egregious waste of time and effort.   Well
> > understood, but not reasonable at all.
>
> This paragraph is full of incorrectness'es. Only one of them,
> Cocotron, does Foundation/AppKit and is recent. I don't know the
> reasons but it seems to be rather clear: a) other license, b) Windows
> deployment focus. GNUstep had no focus in the past.
> (BTW: stating that GNUstep is a viable cross platform _solution_ is
> ridiculous. Having a way to target Windows seems like a great thing
> to me, and something I often proposed)
>
> AJRFoundation AFAIK is just a Foundation _addon_ (like SOPE
> NGExtensions). Its more like a concurrent to GDL2, but was also
> started when it was unusable (it made no sense to build upon GLD2).
>
> libFoundation was started a looooong time ago (~1995?), when gnustep-
> base was extremely immature wrt to OpenStep compatibility, and more
> importantly wrt code quality.
> BTW: lF isn't really being "developed" anymore, its just kept in
> shape. It just works and does all we need in our limited scope. Its
> no waste of time for us because fixing gstep-base to match our
> requirements is still quite a big effort, while keeping libFoundation
> is a matter of a few days per year at most.
>
>
> Most projects with duplicate code pathes I know in the ObjC area are
> duplicates due to historical reasons, not because someone didn't want
> to work together. Now merging those high quality DUPs is quite some
> work.

 I can understand the existences of  several AppKit implementation
 because it depends on the platform and gnustep-gui
 indeed is not as mature as gnustep-base.
 But I don't understand the difficulty of merging libFoundation and
GNUstep-base.
 Base on this document:
 http://www.opengroupware.org/en/projects/gnustep/index.html,
 it seems to be not so hard.
 GNUstep-base does support some Cocoa methods which are not in OpenStep.
 I believe it can also support the extension in libFoundation if someone asks.
 Same argument can apply to Cocotron
 so that they only need to implement their own AppKit.
 But if license is the issue, there is almost nothing people can do.
 As for the place to install (/usr/loca/lib or GNUstep/System/Libraries),
 gnustep-base works on both ways with right settings.

 Happy Holidays !!

 Yen-Ju
> Greets,
>    Helge
> --
> Helge Hess
> http://docs.opengroupware.org/Members/helge/
>
>
>
>
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnustep