[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cocotron

From: Richard Frith-Macdonald
Subject: Re: Cocotron
Date: Tue, 26 Dec 2006 11:37:48 +0000

On 26 Dec 2006, at 10:22, Renaud Molla wrote:

First of all,
I join the cocotron thread after several posts and may say things already said in previous messages.

I tried the cocotron textedit example, and to be true, i first thought this was an hoax since I downloaded it and it worked as is. So i changed the NIB with Interface Builder to check this was really true, addes a Label and A button, and it worked, so i guess claims that they're experiencing nib reading problems can't be totally true.

What stroke me (positively) is that their example worked after unzipping, nothing more to do. The application integrates well within the OS look and feel, i mean, I'm a mac os x user and really like the top menu bar and the floating menu concept of openstep, but to most windows or other APIs (gtk/kde/etc...) with menus right below the title bar, the menus are rather reluctant. (what a pity however).

I think it really is straightforward to see that cocotron and gnustep do not share the same goals. They must have common "subprojects" in order to comply with the OpenStep specifications, but it is clear that the end user/deployment philosophy is not the same.

I think that is partly true ... only partly, because I think a large part of the issue is simply that GNUstep unfortunately does not have any mswindows experienced programmers.

Where I think you are right about philosophy is actually something I've noticed common to all the non-gnustep variations I've seen...

GNUstep tries to produce libraries which are fully MacOS-X compatible, and the emphasis of development is on 'fully' with completeness and correctness of the implementation being a major focus.

The various Cocoa-clone projects seem to be much less devoted to correctness/completeness of the library implementation, but instead focus on producing a usable subset of roughly correct code, which can be 1. Easily used by Cocoa programmers (eg uses the MacOS-X development tools)
2. Easy for end-users to install/run on a particular target system.

This gives GNUstep developers a strange view of alternative projects ... their codebase seems to be woefully incomplate/immature/ buggy from our point of view, and we therefore tend to be dismissive. In part we have developed this attitude because people always complain about missing features ... but there will always be missing features for people to complain about.

However, the perception of new users actually wanting to try out the software is the opposite of ours ... because (in the case of cocoa developers) they can work with the Cocoa development tools they are used to, and because there are smoothly working demo applications, the alternative projects can appear better than GNUstep.

I imagine that, once they start writing applications with a non- GNUstep framework they will be frustrated by the lack of completeness and immaturity ... but by then they have bought in to the software psychologically ... and are likely to fix bugs and implement missing features/classes.

This is exactly what GNUstep lacks ... we need to lower the entry barrier and make things look easy so that people will start using GNUstep ... once they have started developing with it they are more likely to contribute. And while it's a radical departure, I think it's probably now more important to lower the usability barrier than it is to fix bugs and add missing features.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]