Re: The future of GNUstep (was: Open URL in NSWorkspace)

[Nicolas Roard]

On 8/7/07, Vaisburd, Haim <HVaisbur@advent.com> wrote:
>From many discussions on this list I got an impression that every
> attempt
> of porting any serious Mac OSX application failed - either because of
> Carbon
> or because of some toolkits on the top of AppKit that we do not have.
> If this is a wrong impression because problems are reported on the list
> but
> successful ports go silently - please accept my apology. But if this is
> true
> - what do we really gain from compatibility?

Well, it's true that many ports can not be done because of Carbon use.
On the other hand, it's false that every attempt at porting any OSX
app failed :)
There's first (obviously) apps that are the easiest to port because
first done with GNUstep or OPENSTEP like GNUMail or Cenon, or
StepTalk, etc.
But there's also apps like Vienna or Sketch we ported straight from
OSX to GNUstep/etoile, apps that fabien ported too (MPlayer, etc), and
I forget others.
And there's as usual all the apps that people don't report about (eg I
wrote some custom apps for my research that work on OSX and on GNUstep
straight away, and I was very thankful to have GNUstep for that).

So basically, my understanding and my experience is that if you /want/
to port an app, it's doable. It might be harder and need work in some
cases (use of Carbon, of other toolkits) but it's doable. And if you
write your app with compatibility in mind it's really just a
recompilation.

Also, let's look at what causes the problems if you want to recompile
a cocoa app : apart from the Carbon code (and well about that, it's
the cocoa app developer's fault, and if he did do a good job in the
first place it should only be a tiny part), the main problem is use of
other toolkits/capacities like CoreData or Bindings.

CoreData could be the most controversial : It could be argued that we
do not need CoreData as such -- we have GDL2 for instance -- and work
on it would therefore be an example of what Fabien was talking about
(running after compatibility rather than debugging GNUstep).

Well, there's indeed an implementation of CoreData that Saso started,
yet gnustep wasn't involved itself. So you can't say that there was
here some kind of delay caused by gnustep devs busy implementing
CoreData rather than working on gnustep (though I guess you could have
preferred to have Saso work on GDL2 but hey: this is free software,
not prison, he's free to do whatever he wants!).

Now for Bindings -- there are gnustep devs working on it. Yep. But
it's not merely running after compatibility for compatibility's sake
here! we *want* to have Bindings because they are damn useful ! (and
while we are here hopefully we'll do a better job than Apple to
integrate bindings and Gorm in a nice way).

So well, to sum it up...
1/ Portability is here today, even if it means some work in some cases
2/ We use that fact to port OSX apps to GNUstep and vice-versa
3/ Generally gnustep efforts to port OSX new stuff are because we want
the new stuff because it's cool, not purely for compatibility effort
4/ There's still room to implement it better ;-)
5/ And at the end of day, it's a free software project: people are
free to work on whatever they want.

-- 
Nicolas Roard
"La perfection, ce n'est pas quand il n'y a plus rien à ajouter, c'est
quand il n'y a plus rien à enlever." -- Antoine de St-Exupéry