[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNUstep Base OpenStep Compliance

From: Tim Harrison
Subject: Re: GNUstep Base OpenStep Compliance
Date: Fri, 4 Apr 2003 17:07:50 -0500

On Friday, Apr 4, 2003, at 15:55 Canada/Eastern, Richard Frith-Macdonald wrote:

What I want to see is a system that behaves (look and feel of apps)
like NeXTstep (that's the real goal!) but is compatible with MacOS-X
(to attract developers).

This can be done, but I think the order you want it to happen in is detrimental to GNUstep's success.

In that light, I thing the compatibility priorities above are in the wrong

I think they're perfectly in order.

I can't see why we'd want the OPENSTEP 4.2 implementation as a
particular target. In terms of look and feel of the gui and applications
IMO NeXTStep3.2 was better and we should be aiming for that,
while in terms of implementing the OpenStep API OPENSTEP4.2 is
little better than MacOS-X, so where undocumented implementation
details are concerned we should take a live system in preference to
a dead one as our primary standard.

I think you're TOTALLY missing the point. We're not talking about wanting a dead system. We're talking about wanting support for an API that is UNCHANGING, as opposed to the CHANGING API of Cocoa, something we may not have the resources to track, and something that might implement changes that break previous OpenStep/OPENSTEP behaviour, causing GNUstep to be less than consistent.

It's like building a house (if you'll pardon the simile). You can create the most incredibly beautiful house, with lovely gardens, and stunningly expensive stained glass windows, an exceedingly expensive art collection in the den, and a kitchen the size of Kitchen Stadium...

... but if there's no solid foundation, the whole bloody thing is going to crash down, and your neighbours are going to call you a prat, and wander off, chuckling to themselves.

People keep saying "OpenStep (or OPENSTEP, or whatever bloody combination of case you wish) is dead". And then, in the next breath, argue that Cocoa is just an updated OpenStep. Which is it? Is it dead? Is it Cocoa now? Is it alive and well and living in Freedom/France? Is it my cat? I think OpenStep is alive and well, and Apple is learning how to build a proprietary system out of something that used to be a whole lot more "open". So, maybe OPENSTEP 4.2 hasn't been a "current" system for a while, but the core technologies beneath it (OpenStep and the additions for OPENSTEP) are VERY much alive.

At least I can go out and buy a reference copy of MacOS-X to test
against ... even if I can find someone to sell me a second-hand copy
of OPENSTEP-4.2 the chances are it won't run on my computer
because it won't have drivers for the modern hardware.

You'd be surprised at what it runs on. I believe it also runs in VMware, which would solve your hardware problem. As for second hand copies of OPENSTEP, they are out there.

(NOTE: I know VMware is a naughty word around here -- a situation that I think was silly beyond words (it's okay to use a copy of Windows or Mac OS X to develop GNUstep, but a generous grant of licences of VMware turns into a fiasco), but it *is* a potential solution)

I'm very happy to have backward compatibility options for OPENSTEP
users built into the code ... as long as those users help maintain them,
but I don't want to spend my time borrowing time on someones old
OPENSTEP system to test each change I make so that the code
conforms to the OPENSTEP4.2 implementation.

But, the point is, having "forward compatibility" with Cocoa would be a much wiser design choice. Chasing an actively developed, and changing API, and expecting to base a stable system on it is, in my opinion, folly. Starting with a solid, stable, unchanging base, and then adding on extensions to that, carefully selected from Cocoa, makes infinitely more logical sense.

I've kept my personal reasoning out of this, thus far. But, I'm absolutely infuriated by the current state of GNUstep. I've been trying to build an operating environment that is significantly based on GNUstep, but I have trouble going forward with it, because I don't want a user to have to reinstall the ENTIRE system every time someone makes a change to the releases, and suddenly everything from the user's mail client to the desktop/workspace to the init system no longer functions. And, to a small degree, this happens to most of us, from release to release. Even from CVS checkout to CVS checkout. And I can't tell you how many times I've ranted, or watched others rant, about how ridiculously unstable GNUstep is, and how pissed off people are that the API/implementation/documentation (just kidding) keeps changing under the apps, making them fail miserably.

If you really think you can maintain a stable development environment while tracking Cocoa as a primary goal, then I salute you. But, historically, and certainly up to this exact point in time, GNUstep is NOT stable, does NOT seem to have a solid goal (whether it be Cocoa-clone, OpenStep implementation, or anti-GNOME, whatever), and, in my opinion, has trouble getting developers and users because of these issues, not because NSDrawer isn't implemented.

I love the concept of GNUstep. I love what it could/can be. I can't tell you how many people say, "I read about GNUstep several years ago, and hoped it would be ready by now". I started getting involved with this community two years ago now, and honestly believed that this environment would be ready for the kind of system I wanted to build. And, for some silly reason, I still stay, and still try to do my part for making things better. I can't code to save my idiot life, but I submitted proposals for cleaning up filesystem organisation. I want to see GNUstep rise above. But, in the current state, I fear that it will forever remain an unstable, niche gadget, and act as an example of what might have been.

Does that make it clearer as to why we'd want to focus on OpenStep/OPENSTEP as a basis for development? I can't think of any way to make it more plain.

Tim Harrison

reply via email to

[Prev in Thread] Current Thread [Next in Thread]