I see some options to get GNUstep out of its "misery". See below and
discuss (for that reason I moved that to [email protected])
Am 30.10.2007 um 02:20 schrieb 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.
Well, I am trying to play my part in there, I am currently porting an
OPENSTEP/Rhapsody sound editor (Resound) first to OS X and later to
GNUstep. Progress is slow, I am currently facing some obstacles which
I don't know how to resolve yet (I got a header problem on OS 4.2 and
troubles to remove the dependency from the ancient NeXT SoundKit on
OS X - no SoundKit there - but the /somewhat/ similar MusicKit from
Leigh Smith exists)
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.
- an easy installation and setup process for GNUstep is essential in
my opinion. It must be easy for the curious "chance customer" to get
an experience of GNUstep. It doesn't matter if this is achieved by an
simpler installation process or by providing GNUstep in a binary
form, for instance as a Live CD image. Maybe we should get our act
together and use some "synergies" (as in marketing speak ;-)). For
instance link projects related to GNUStep like Étoilé from the
GNUstep website more prominently (also with a hint that you can get a
Live CD there).
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.
I'd say "act differently" (from what we are acting now) I think we
need to make GNUstep more visible (to both users and developers):
- fight the common misconceptions about GNUstep (like: "GNUstep? I
use WindowMaker too!") with a short slogan that explains the most in
just two words: "code differently". Add this as a tagline to our
website and use it on merchandising stuff (like t-shirts):
"GNUstep - code differently" (maybe even something ObjCish: [GNUstep
code: @"differently"];)
- emphasize more on our relation to Cocoa. In a blog from a guy who
took part in GSoC I read that he was desperately looking for a
project that uses Cocoa and he was lucky when he found Camino (a
Cocoa/Mozilla based Webbrowser). Obviously he did not know about the
relation between GNUstep and Cocoa.
To attract more developers we might need to remove possible obstacles
for others to get involved. What would that be? To my mind come here
the installation hurdles, difficult first steps for new developers
and maybe even the need to sign the copyright over to FSF might shy
some people away.
- the easy access is important here to (like already said above)
- but also the code as such should be as easy accessible as possible
like you already mentioned
- maybe we need tutors that help newbees on their first steps in
developing for or with GNUstep (well this might be difficult because
it is very time consuming)
- I don't know if that helps - but what about bounties? I guess we
can make some money from merchandising stuff (which in turn also
makes us more visible) and put that as a bounty for parts of GNUstep
which are important but not currently worked on. Hey, maybe some
companies which use GNUstep are willing to put out a bounty. We
should ask them (there is no shame in this - even wikipedia asks for
support).
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 <[EMAIL PROTECTED]>
To: Gregory John Casamento <[EMAIL PROTECTED]>
Cc: GNUstep Developers <[EMAIL PROTECTED]>
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
_______________________________________________
Gnustep-dev mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/gnustep-dev
_______________________________________________
Discuss-gnustep mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
