[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