gnustep-dev
[Top][All Lists]
Advanced

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

Plans for change....


From: Gregory John Casamento
Subject: Plans for change....
Date: Fri, 15 Dec 2006 20:10:01 -0800 (PST)

All,

I've written up a short list of things that I want GNUstep to accomplish in the 
year to come:

As Chief maintainer, it is up to me to determine the direction of the project.

Over
the past several years interest in GNUstep has steadily increased, but
not nearly by enough. In order to reach a wider audience, GNUstep needs
to do a number of things (not necessarily in priority order):

1)
Adopt a more modern look. This includes the look of the windows, the
color scheme and how the menus are rendered. It's okay to let that old
gui go, it's not going to kill you to do so. ;) Users like things to
look "good". This is entirely subjective. Personally, I think GNOME and
KDE are quite ugly under the best of circumstances. To this end, we
need to make integrated theming available in GNUstep and make it easy.

2)
Make regular releases. Start courting different distributions to
include GNUstep in their package set. Start getting the word out. Start
making sure that people KNOW that GNUstep is alive and well. This, I
believe, is the main reason why people have the perception that GNUstep
is dead. We don't push ourselves hard enough and into enough
distributions to be visible enough for people to care.

3)
Eliminate the need for GNUstep.sh, either by making GNUstep place it's
binaries and libraries in more "standard" places, or by providing an
installation procedure

4) Start appealing more to the Mac OS
X/Cocoa crowd. While some people disagree with me, I believe that this
group IS the group we need to be playing towards. In the past some have
advocated that GNUstep be an "OPENSTEP-like" or a "Cocoa-like"
environment. While I don't believe that GNUstep should necessarily
follow all of the design decisions Apple has made, I believe that it
should implement all of the classes which are useful and which are
being commonly used in spite of
whether or not people personally agree with having that class in
GNUstep or not. A good, and recent, example of this is NSToolbar. It's
not about us, remember, it's about them... the users and developers
USING GNUstep. We are here to make life easier for our users not to
make GNUstep into the epitome of "perfect design" by excluding classes
we personally don't like. This is not productive and, not to mention,
highly subjective.

5) Focus and concentrate on one and only one
set of display technologies per platform. We expend way too much time
and energy on maintaining mulitple backends (xlib, art and etc) when we
really don't have to. For Linux/BSD we have two functional backends and another 
on the away for cairo. What's the point of this? In my opinion
we should complete the cairo backend and deprecate BOTH the xlib and
art backends. xlib is hopelessly outdated and libart isn't really
supported by anyone anymore. 

6) Decide what we are. Yes,
that's right. Some people view GNUstep as a desktop, others view
GNUstep as a development environment. GNUstep needs to define itself as
one or the other. The website says it's a development environment, but
it has many aspects which fit the definition of a desktop environment.
In truth, I believe it should be both.

7) Make GNUstep friendly
with other environments like GNOME, KDE, Windows and etc. Make sure
that GNUstep functions sanely in these environments. This might mean
that we need to have behaviors for each different environment. How to
implement this is unclear, but it's something that I believe would make
the user experience better overall.

All of this is just for
starters. Anyone who is familiar with my work on Gorm knows that I tend
to focus intently on things until they succeed. I intend to do the same
with this project as a whole.

If you have anything to add to or detract from the above, please feel free to 
comment.   I would love to hear all opinions.  I, respectfully, ask that you 
make your comments constructive and avoid flaming.

It is also posted here: 
http://heronsperch.blogspot.com/2006/12/plans-for-change.html

Thanks, GJC 

--
Gregory Casamento
## GNUstep Chief Maintainer






reply via email to

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