On 8/7/07, Vaisburd, Haim <[EMAIL PROTECTED]> 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 _______________________________________________ Discuss-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnustep
