Re: Cocoa/Windows parallel dvlpmt

[Alex Perez]

On Tue, 3 Feb 2004, John Stiles wrote:

> On Feb 2, 2004, at 12:54 PM, Alex Perez wrote:
> 
> >> While these goals may ultimately be achieved by the GNUStep project, 
> >> it
> >> seems to me that noone is really working on the Windows port right 
> >> now.
> >> This is too bad because it would make a wonderful porting base (a lot
> >> of their code is mature).
> >
> > I get real sick of people saying this. It's an open-source project! If
> > you're not part of the solution, you're part of the problem. Whiners
> > really ought to either (A) keep their opinions to themselves, or (B)
> > Contribute.
> 
> Oh please. Not all of us have the time to reimplement Cocoa from 
> scratch.
Nobody is asking you to, silly. Probably the worst thing you'd run into is 
the possibility that a class was unimplemented, but since the OpenStep 
spec is 90% the same as Cocoa is, your assertion that you'd need to 
"reimplement cocoa from scratch" is dubious at best.
> 
> I appreciate that open source doesn't write itself, but most of us are 
> looking for stuff like GNUstep because we DON'T want to reinvent Cocoa 
> by hand--we want something that already works! You can't fault us for 
> that.
GNUstep only DOESN'T work if you use a class that is ONLY implemented in 
OS X and not GNUstep. We accept patches.
> 
> > I'm a GNUstep user and know there's active development on the
> > win32 backend. The goal is "Stability First", so I think the old "put 
> > up
> > or shut up" adage rings true here. If Mac developers spent half as much
> > time contributing to GNUstep as they did whining about how much it 
> > sucked,
> > it'd be a world-class product!
> 
> Mac developers have no need to contribute to GNUstep. We have a better 
> version already.
The word Better is highly subjective, because is "platform (and 
architecture) lockdown" really better? I personally don't think so, and I 
say that as an iBook owner and OS X user.
> 
> I think most cross-platform developers, like me, would rather just 
> re-roll their interface code as native Win32 instead of investing the 
> time in a second-class solution that will never look as good as a true 
> Win32-native rewrite. If a goal of GNUstep were to mimic the l-a-f of 
> the target OS instead of looking like Xwindows or something, then I 
> think it would have a lot more appeal to developers of production-level 
> applications. But most of us right now just write native code for each 
> target platform, because that's what end users prefer. If the app 
> you're writing is very GUI-intensive, you may make an abstraction layer 
> or mini-framework that lets you spend more time in cross-platform land, 
> but even that tends to cause little rifts where end-users occasionally 
> get behavior that they wouldn't normally expect from their platform of 
> choice.

As I said, a GNUstep-wimp type L-A-F project is possible. There's nothing 
wrong with rewriting a win32 interface, but for folks who want to use ObjC 
in their backend, and who really don't like C++, windows porting is pure 
hell. You will never get an interface that looks completely "right" under 
win32 unless it's designed for that platform, but products like GTK-wimp 
show that widget re-representation is at least possible in a 
near-transparent way.

There is also potential value in being able to have an ObjC backend to an 
app on win32. With the release of FSF GCC 3.5 (roughly one year away), the 
official FSF GCC branch will likely support ObjC++, and this, combined 
with GNUstep-base (Foundation) would allow for a lot of objc code reuse 
under win32 environments with native C++ win32 frontends.

Alex Perez