Re: Objective-C 2.0 and other new features in Leopard

[Gregory John Casamento]

Fred,

The previous email wasn't meant to address anything outside of how ObjC 2.0 
directly impacts GNUstep.  Nor was it meant to cast an optimistic or, indeed, 
pessimistic slant on things.   Neither is this one, for that matter.  That 
being said, you and I have discussed the these very issues last time we spoke.  
   We need to figure out how to solve them.

The development applications and libraries in GNUstep are complete for the most 
part.   All of the important classes are there and, with Gorm and Project 
Center, all of the important functionality is there.   I think that part of 
what we're seeing is due to that.   The perception is that there is not much 
left to do on the core libraries themselves.

Here are the challenges that I see (in order of priority):
++++
1) Applications... We need a comprehensive suite of applications for GNUstep.  
Something that, when someone uses them they have an integrated experience.   We 
currently don't have that.

2) GUI... Apologies to anyone who's in love with the old interface and you know 
who you are, it's extremely dated.   Etoile is helping with that, but many 
people, when they try GNUstep.. they try the core project and they see the old 
NeXTSTEP-ish GUI.   This GUI is not as attractive as some of the current GUIs 
out there.   We need to make it so.   A pretty gui can be very compelling to 
both users AND developers.

3) Repository...  I think we need to simplify a number of things with respect 
the repository.  It is currently hard for people to check GNUstep out because 
of the structure it was given in SVN.  You can't simply follow the instructions 
on the GNA website to make it work but you need to checking from "devmodules."  
 We should be able to put something into the repository which will let people 
check out in a more "normal" fashion.

4) Thinking differently...  In my experience GNUstep is often perceived as 
doing things "differently" or "weirdly" because we don't follow the current 
"standards".  Usually, these standards are set by people who are using C++ or C 
based libraries which are no where near as dynamic as what GNUstep has to 
offer.   Honestly, call me an idealist, byt I think that the way we do things 
is often better both in execution and design.   From how our make system works 
to Gorm to how the backend works.  GNUstep is a better system than GNOME or KDE 
in it's design.   However.. all of that being said... when we do things 
differently, it might be useful for us to determine if there is a way to bridge 
the gap.   

We've already taken steps towards addressing #4 earlier this way with Nicola's 
changes with gnustep-make-2.0 (for which kudos are long overdue... he did an 
excellent job.. thank you Nicola) since they allow for installing GNUstep in 
different layouts... including one that is FHS compliant, but we need more.

Also... we should emphasize *publically* what we've done more than we do.  In 
the past two years we have been ahead of Apple twice or more in a number of 
things:

1) 64 bit support on Intel.  GNUstep had this way before Apple did!
2) AppKit on openmoko -- while the iPhone debuts with a pitiful API... we have 
a full AppKit available!
3) Support for multiple model formats!  last I checked Apple only supports .nib 
files for Cocoa/Carbon (and the second is being dropped).

These are not "optimism" but statements of fact.   It's too late to say 
anything about the first one, but it's certainly not too late to talk about 2 
and 3.

We have a lot of challenges ahead of us.

Please tell me your thoughts on these points.

Later, GJC
--
Gregory Casamento -- OLC, Inc 
# GNUstep Chief Maintainer

----- Original Message ----
From: Fred Kiefer <address@hidden>
To: Gregory John Casamento <address@hidden>
Cc: GNUstep Developers <address@hidden>
Sent: Monday, October 29, 2007 8:09:32 PM
Subject: Re: Objective-C 2.0 and other new features in Leopard


This is a very optimistic view of things, which I cannot share for the
whole of GNUstep at the moment.

My feeling is the race is over and we lost. Apple has just released a
shining new version of there system and GNUstep is rather stagnant. We
are no longer attracting old or new developers and it doesn't look like
this is going to change. Have a look at the Changelog files from the
last half year and you will understand what I mean. Not even the paid
coders from GSoC made any difference.

We urgently need to change the way GNUstep appears to the outside
 world,
or we will become as obsolete as now seem. Personally I am thinking
about reducing my involvement with GNUstep. It still is fun to hack way
on GNUstep, but trying to get the library out of its current stagnation
phase would require a bigger effort, which I cannot see at the moment.

Cheers,
Fred

Gregory John Casamento wrote:
> All,
> 
> As many of you are probably aware, Apple released Leopard today.  
>  Leopard contains a number of enhancements which are important to us,
 one of which is Objective-C 2.0. 
> 
> Objective-C 2.0
> =====
> Odds are the existing developers will still write for versions of Mac
>  OS 10.4 and below in order to have the widest possible range of
>  customers, but eventually Objective-C 2.0 *will* become the
 standard.   As more
>  and more people upgrade this will become the case sooner rather than
>  later.  The core libraries of GNUstep should remain ObjC "1.0"
 compatible for the forseeable future, but I believe we need to start talking
 to the people in the GCC project to determine
>  how we can help with the implementation of a gnu runtime that works
>  with the new version of the language. 
> 
> Interface Builder enhancements
> =====
> The other feature which is interesting in it is the ability of
 InterfaceBuilder to support multiple languages including Ruby.  The recursive
 descent parser I wrote for Gorm currently only handles Objective-C
 headers.  Additionally, Gorm's internal data structures are decoupled from
 the type of archive that is being saved or read, nib, or gorm.   When
 I added the nib support I rewrote nib/gorm support in both gui and in
 Gorm to support an architecture that allows classes which read/write
 different types of gui files to register themselves so that they would be
 considered when a gui model is loaded.
> 
> I am planning on moving Gorm to a more bundle/plugin oriented
 architecture in the future.   This has a number of implications:
> 
> Gorm will be able to:
> 1) parse multiple languages
> 2) generate multiple languages (for class files)
> 3) read/write any type of gui model for which it has a plugin
 available
>     * gorm
>     * nib
>     * gmodel... etc
>