Re: Cocotron

[Richard Frith-Macdonald]

On 28 Dec 2006, at 00:35, Tima Vaisburd wrote:

> > I disagree that we should adopt the single platform approach ... my
> > feeling is that
> > what they have right is the idea that interface completeness is
> > unnecessary if you
> > have good enough feature coverage.
> >
> > So I think we should be concentrating on that 'good enough'  feature
> > coverage
> > and making that easy for people to get started with.
> >
> > I'm certainly not arguing that we should not add new features, just
> > that our
> > priority should be delivering ease of use rather than completing the
> > task of implementing the entire API.
>
> Ok, I happily agree with you. I tried to describe it as "feature
> completeness":  maybe not all functions are implemented, but
> with those that are you can write everything you want.
>
> I wrote about sticking to Linux only because I was looking for a way
> to reduce the amount of work to be done until, say, "stage 1" is
> fully completed. But your suggestion is even better.
>
> Please note, though, that this task is harder to define - you need
> to deeply know the interface rather than go search for FIXME or
> NOT IMPLEMENTED. I do not have such understanding, for example.
> It's somebody like you (or just you :-) ) needs to say: here is a  
> set of
> methods, we do them and nothing else.

I don't have that knowledge either ... and I'm not sure anyone does.

IMO the best way to find out what bits of the API still need to be  
implemented as a priority is to get people to join the project  
writing applications to do particular jobs, and somehow encourage  
those people to either fill in the missing bits they need or at least  
point them out as feature requests/bug reports ... but to have them  
involved somehow.  I have a suspicion that people who find something  
they need missing just tend to quietly give up and go away, so that  
nobody else even knows about the problem ... or they perhaps raise  
the issue in a chatroom, where there is no record of it.
We need such feedback to tell where to focus (though ideally we need  
patches to be contributed).

In fact I wonder if the irc chatroom harms the project ... my  
impression (from lurking on irc a bit recently) is that most of the  
people who hang out there are not gnustep developers ... ie they are  
people who don't want to contribute to the project, but are  
interested in using gnustep in other things.  So asking for help in  
the chatroom is quite likely to mean that anything said does not  
actually get through to anyone working on gnustep!  It's also as  
likely to get a response griping about gnustep as it is to get  
something helpful.  So it seems the chatroom gives us bad publicity  
and blocks feedback from getting to us!

I don't know what we can do about that though.

I'm inclined to say that core developers should not be proactively  
implementing missing parts of the API at all ... but should be  
concentrating on the ease of use and user appeal issues and only work  
on missing API as a response to a specific bug report or feature  
request from a user.
Of course, sometimes ease of use work implies large scale changes  
including implementing missing API.

For instance ... even though I don't know the Apple CoreGraphics API  
at all, I think we should be changing the gui/backend interface to  
use that for drawing rather than the old DPS methods.  It's an issue  
which ought to make a real usability difference for any MacOS-X  
developer looking to use GNUstep who is doing any drawing into views  
at all.  However, this is lower priority than other usability issues.