[Top][All Lists]

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

project goal Re: Release schedule

From: Helge Hess
Subject: project goal Re: Release schedule
Date: Sat, 05 Apr 2003 13:40:17 +0200
User-agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312


... getting a bit late into the discussion, had to do some real work ;-) Started the mail yesterday and still writing on it (quite an amount of other mail came in in the meantime) ... Find below a huge stack of junk I wrote in an attempt to bring up my idea of what an ObjC/Foundation based project could be.

Nicola Pero wrote:
> I frankly fail to understand why AppleScript, Quartz, NSQuickDrawView or
> NSMachPort are relevant anyway to API stability.

I think I understand the issue even though I do no agree. Actually as far as I can see two different perspectives are take place in the discussion:
a) a technical perspective
b) a resource perspective

From what I've seen so far people always take only one of the perspectives in the discussion, even if this isn't always apparent ... which results in misunderstanding (obvious if you take a look at the huge thread).

IMHO (attention, *everything* below is IMHO ;-):

a) does Cocoa add any *technical* instability or complexity ?
No, absolutely not. IMHO Cocoa scripting classes and even CoreFoundation *should* be added to gstep-base/gui to improve compatiblity. If you don't want Scripting, don't use it, if you consider it instable, don't use it. Almost anything in Cocoa are *additions*, not incompatible changes affecting OpenStep compatibility. This is what Richard, Nicola, ... are talking about and they are right from this perspective.

b) this point is a bit more difficult to explain. Does Cocoa add instability ? Yes ! Because GNUstep has *extremly* limited developer resources. So it's very important to focus on a project which actually can be accomplished in good quality using the given resources. For example if Nicola would have invested the same time in gnustep-gui like in Renaissance, GNUstep GUI itself would have probably much further now ! Now we have a good Renaissance on MacOSX (which I like ;-), and a lacking one on Linux because gnustep-gui is simply not stable.

The Problem is, that b) cannot really be enforced in free software projects. Same example, if Nicola want's to write Renaissance instead of investing the same amount of time into boring X11 testing and fixing, he will do so. Nobody uses gnustep-gui in a commercial environment and this is a major problem (and IMHO the reason why GNUstep is FAR behind KDE and GNOME in usability terms). This is not that much a monetary issue, but more the customers force requiring the company to provide a working solution.

OK, now what I think GNUstep should be. IMHO the GUI thing should be dropped altogether. Really !! (I know I'm going to get killed ;-)

Why ? Because they are definitly not enough resources and there are working (and implemented) solutions available for any platform. Some points which may might clear why I think so, totally unorganized in note form.

- There are about five, maybe ten developers activly working on gnustep-gui, but in less than part time. I claim that this *obviously* isn't enough to write a complete and production quality GUI framework (even in 10 more years). Think about it, really ! Take a look what KDE does, how long it took and how many resources were required to reach the current state. Note that Qt is available in stable form for years.

- I agree that the GNUstep GUI framework is almost complete from a functional point of view. But now the last 10% of fixing the bugs starts and this 10% take 90% of the development time (eg writing the NGImap4 client library according to the spec took about a month, but getting it working in sufficient quality took at least a year). Richard asks for people submitting bugs, but it should be understood that this is very hard and time killing work and needs qualified people.

- GNUstep as a separate, non Cocoa compliant framework IMHO doesn't improve development in a huge way in contrast to KDE or GNOME. If GNUstep-GUI would be 100% stable and complete it would still be no KDE killer. GNUstep's technology is better than KDE's but not that much, KDE is good too and just works.

- A gui framework itself isn't enough. KDE/GNOME are not only frameworks but also a significant number of applications. And I'm not talking about Finger but about Konqueror, Evolution, Gnumeric, KOffice, Kivio, ... I think it's a common myth that once gnustep-gui is ready writing apps will be trivial, but it's only trivial for trivial applications, even on MacOSX and trivial apps are not killer. Those apps shall be developed by the five part-timers ?

- A gui framework isn't enough 2. KDE/GNOME are not only frameworks, but also component systems. Eg think of embedding Mozilla into Konqueror or Nautilus. Think about DCOP IO services. Configuration management. Package management. QuickTime (as a media framework, not necessarily as an exact replacement).

- As Nicola has pointed out, Renaissance (or something similiar) is required for achieving good platform independence. Now you must realize that most systems already work that way and are *blaimed* for that traditionally ;-) That is, one of the technical features of gnustep-gui was seen in InterfaceBuilder, but we (at least some) already realized that this isn't really a good solution for the current problem. Eg OPENSTEP/NT wasn't that nice because it wasn't really Windows (same problem in Swing and Mozilla). GNUstep-GUI does not have up to date abstractions for X-platform GUI.

- I know quite a lot of former NeXT users. Some of them moved to Windows, some to Linux and most to MacOSX. Know what ? Nobody is really interested in a NeXTstep looking GUI anymore ! Certainly, any NeXT user will look at GNUstep and say "wow, cool", but nobody will actually want to use it, because UI technology has evolved. MacOSX UI is considered better than NeXTstep and XP UI is considered better than NeXTstep (talk with someone who uses VisualStudio.NET !).

- GNUstep-GUI might get significant attention if the goal would be to reproduce MacOSX completly. Pretty much comparable to WINE at a higher level. But this is even a bigger project impossible using existing resources.

If I think another day about the topic, I would probably come up with more reasons. I know that those a pretty aggressive points, but IMHO gnustep-gui can only lead into nothing. It might be a fun project, but anyone who actually wants to accomplish something useable for more people should think about the points above.

So what would I suggest as a GNUstep goal ?
I have no ready made answer on that, again only some thoughts ;-)

First I think we should focus on GNUstep's real advantages. I see two things which are worth a project:
a) Objective-C (and Foundation)
b) gstep-web

I have some difficulties explaining that in email, but I give it a try ;-)

a) IMHO the real advantage is Objective-C. It's simply the better Java and the better C#. IMHO the biggest advantage of ObjC is it's 100% integration with C (to the level of toll free bridging as seen in CoreFoundation). A difference between GNOME and KDE is, that GNOME tries to be compatible with any language at very low level and KDE is C++ only. That results in GNOME libraries being written in ANSI-C which is why GNOME is even more difficult to develop than KDE. Now the nice thing is, because ObjC is so compatible with ANSI-C, we can add "toll-free" additional value. It's very easy to wrap anything available in C and make it more usable. We can integrate with Apache, we can integrate with Java, with Mono, with GNOME, with TCL, with Perl, with Windows, ...

Objective-C is the better C and instead of writing everything from scratch we should use that advantage and become a "value-adding" product for existing stuff. Pretty much like scripting languages, only on a different level. It's certainly a project that looks very doable to write a very good and complete Objective-C wrapper for Gnome or KDE in, say 3 months using 5 people. If that would be done, 5 people could finally start out writing applications in Objective-C ! The model layer could be easily shared between OSX and Linux applications. And we can write good GNOME applications in ObjC much faster than other people in plain C.
So we are not winning by base technology, but by superior applications.

Objective-C has an abstraction level almost comparable to Smalltalk or Python but by being pragmatic, is a lot faster and more integration friendly than those two.

b) It IMHO has less potential than the above, but at least the project can in my opinion be completed using the given resources (from experience since we have done exactly the same ;-) This is also pretty much the same way Python got major attention - by Zope. We can certainly be far better than Zope basing on WebObjects technology. We can provide much better integration with existing environments than Zope. And we can be a lot faster. Also Mono is trying to accomplish that using ASP.NET, which is not nearly as usable as WO technology.

But such a project also still needs *quite* some work to make it interesting for masses. Eg we would need an IDE for gstep-web (... probably somebody needs to write an Eclipse plugin ;-) And we would need to support writing components in Java, PHP, Mono, ...

So, that's it what I have in mind till now ;-) I'm open to discuss the points and to try to explain further. Please don't flame, be constructive ;-)


reply via email to

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