[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Cocotron
From: |
Renaud Molla |
Subject: |
Re: Cocotron |
Date: |
Tue, 26 Dec 2006 16:54:43 +0100 |
//
// 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.
- Re: Cocotron, (continued)
Re: Cocotron, Gregory John Casamento, 2006/12/23
- Re: Cocotron, Helge Hess, 2006/12/24
- Re: Cocotron, Adrian Robert, 2006/12/24
- Re: Cocotron, Tima Vaisburd, 2006/12/26
- Re: Cocotron, Renaud Molla, 2006/12/26
- Re: Cocotron, Richard Frith-Macdonald, 2006/12/26
- Re: Cocotron,
Renaud Molla <=
- Re: Cocotron, Tima Vaisburd, 2006/12/26
Re: Cocotron, Lars Sonchocky-Helldorf, 2006/12/26
Re: Cocotron, Tima Vaisburd, 2006/12/26
Re: Cocotron, Philippe C.D. Robert, 2006/12/26
Re: Cocotron, Gregory John Casamento, 2006/12/23
Re: Cocotron, Gregory John Casamento, 2006/12/24