discuss-gnustep
[Top][All Lists]
Advanced

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

Re: Kickstarter was not successful... but it did help things...


From: David Chisnall
Subject: Re: Kickstarter was not successful... but it did help things...
Date: Thu, 12 Sep 2013 09:20:48 +0100

On 11 Sep 2013, at 17:58, Gregory Casamento <greg.casamento@gmail.com> wrote:

> 2) I should have been more realistic in my goals on the kickstarter.  We are, 
> honestly around 10.3 in some APIs, 10.4 in others and 10.7 in others.  An 
> honest assessment of our states on a class by class, method by method level 
> is what's really needed.

I believe that 'compatibility with OS X 10.x' as a goal is fundamentally 
flawed, for three reasons:

First, we're only claiming compatibility for a small number of frameworks.  If 
an application needs QTKit or AVFoundation or whatever from one of these 
releases, we won't have it.  The claim of '10.x compatibility' will be taken as 
meaning that any code that works on that version of OS X will work with 
GNUstep, and that's not feasible (even for 10.1, because code that old likely 
uses a load of Carbon cruft).

Second, no applications actually use all of the APIs in a particular release.  
A better approach would be to find some open source OS X-only applications that 
only work with OS X 10.x or later and ensure that we have all of the APIs that 
they need.  This gives the same PR benefits ('FooApp requires OS X 10.x, but 
runs fine on *BSD/Linux'), and means that the new APIs that we implement get 
immediate testing.

Third, if we struggle and get full 10.6 compatibility for Foundation and 
AppKit, people will say 'but 10.6 is ancient, 10.9 is out now!'  In spite of 
the fact that we may be supporting all of the commonly-used features from 10.7 
and 10.8, if this is our bar then it means that we always appear to lag behind 
where we are.  

If we want WebKit (which we do!), then the first step would be to run some 
analysis on the WebKit code and see what CoreFoundation APIs it needs, and what 
methods on which Cocoa classes it uses.  We should then produce a list of 
these, cross off the ones that are missing, and make 'implement these methods, 
which would allow WebKit to run on GNUstep' the goal.  This is a concrete goal 
where people can reasonably assess how difficult it is (and therefore how much 
it would cost to implement).  We could even assign a bounty to each function 
and method and pay it out once someone writes an implementation that passes 
code review.

We should also approach companies like Omni Group and ask them if they can 
provide a list of APIs that they need to port their products, and if they would 
be willing to match funding.  We could almost certainly provide them with an 
automated tool that they can run on their codebase that would give them a 
pretty clear idea of the OS X APIs that they use.  Actually, providing such a 
tool with the ability to produce a report against the current version of 
GNUstep showing what is missing would be very helpful for a lot of projects.  
In some cases, it might be possible to meet half way and say 'well, this API 
isn't really core functionality, so we could make it optional, and if GNUstep 
provides these ones then we get a Linux port...'

Other things I'd have liked to see on the Kickstarter list that are more 
achievable:

- Finish Opal / CoreGraphics implementation
- Provide an Android back end (using GLES and Cairo)
- Ship an Android SDK

David

-- Sent from my Apple II




reply via email to

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