Re: Cocotron

[Renaud Molla]

//
// Sorry for <Richard Frith-Macdonald> that may read this message twice,
// I replied to him but didn't post the message to the mailing list.
//

I agree with you,
depending on one's knowledge of computers/systems (and many other  
things), the focus when
comparing systems may be very different.
Unexperienced users may find themselves lost with 'exotic' screen  
arrangement (menus, scrollbars ;-), etc. )
and consider something is crap when compared to other things because  
they can't compare using other means because
they don't have the knowledge to do so.
However, software developers (should) try to view their product with  
the end user point of view, therefore,
no matter how elegant the backend design can be, if it was to be  
classified as garbage by the users,
this design would simply be discarded.

So in the end, this leads to the use of other APIs like Qt to develop  
cross platforms products.


On Dec 26, 2006, at 12:37 PM, Richard Frith-Macdonald wrote:

> 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.
>
>
> ---------------------------------------------------------------------- 
> -----------------
> Orange vous informe que cet  e-mail a ete controle par l'anti-virus  
> mail.Aucun virus connu a ce jour par nos services n'a ete detecte.