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

[Riccardo Mottola]

Hi,

On 09/12/13 10:20, David Chisnall wrote:
> 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.
Exactly my take. I have discussed this off-list several times. Claiming 
compatibility with a certain version is flawed because:
1) it sets an extremely high bar
2) it is difficult to measure: if something is implemented but doesn't 
work accordingly or incomplete?
3) it sets expectation about other frameworks (Core*, WebKit, ical and 
whatever else) which go beyond Foundation and Appkit. Which is fine, I 
don't say we should have some of those, but linking them together is too 
much
4) It means always "following behind". At first it looks as a nice 
marketing hype, but it is counter-productive
5) it makes a bad figure if you lack certain little used method or 
method which are just convenience.. because you can't say you are 
complete. Also, the other way around... you may seem like "90%" and 
then.. you miss NSTextTable or another big class in the last 5%...
6) it makes a very cocoa/apple oriented impression (but this is just my 
opinion).


I would prefer to have "we have the APIs to have application X work".
> 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...'
That is a very interesting part. It could be also accompanied with a 
"porting guide" for things known to be different outside of Mac.

I don't have exact proposals right now, but I would prefer smaller, 
precise goals at the beginning... thus mor similar to GSOC. Essentially 
you could take then these specifications give them to a programmer and 
have an estiamte of the cost.
people came to the mailing list asking about applications

For AppKit:
- Implement NSTextTable (very helpful for SWK)
- complete Printing enough so that application X, Y, Z work as on the 
mac (where the apps currently are simple OpenSource apps like Graphos, 
LaternaMagica and PRICE, of course if we have bigger apps on the porting 
front, then fine)
- extend & implement feature X in the windows theme (not just "finish 
it, but a set of precise things make real native menus
- improve theming to support feature X or Y (e.g. horizontal menus, 
theming of decorations...)
- many others

Outside AppKit, I could think of precise goals that could be 
interesting,even app related
- port Emacs to GNUstep
- make an Xcode chain
- make ProjectCenter and Gorm work on windows
- extend SWK to the point where a precise set of pages can be displayed 
(e.g. reference documentation or gnustep Wiki)
- implement a preference pane for SystemPreferences to manage feature X 
on operating systems at least W, X, Y (e.g. displays, wireless 
interfaces,  on Linux, BSD, etc)

I would refrain from something like "make FlexiSheet work" (I got this 
request off-list recently, showing that there is really a different set 
of goals). FlexiSheet is buggy and incomplete to start with. Maybe we 
can make GNustep good enough that it works on Mac, but waht if you 
encounter bug compatibilities? or even more bad bugs in FS of which 
there is full? You could reach the  goal, but the "customer" might not 
be that happy, needing to fix, enhance both FS as AppKit.

I just came with a short list, things could be bundled together, 
split...  I was just making examples of the kind of things I have in mind.

Riccardo