What GNUstep is and is not....

Recent replies to my previous post on the gnustep-dev mailing list have made it necessary for me to further define what I believe GNUstep should become in the future.

GNUstep is a development environment and API, first and foremost. While GNUstep contains a few apps which comprise a minimal desktop... mainly GWorkspace... I feel as though it should not be considered as a desktop project. Yes, I know this contradicts what I said in part of my previous posting, but here's why I've had this change of heart. It is necessary for GNUstep to focus on being one thing and doing that extremely well. GNUstep's main purpose, like OPENSTEP's, is to provide a multiplatform development environment and API.

The way I see it right now, the project is divided into two camps:

1. The group of people who feel that GNUstep should be an API/development environment
2. The group of people who feel that GNUstep needs to be a desktop and possibly a standalone OS which is a clone of OPENSTEP/NeXTSTEP.
   

What I am saying is that if we do #1, #2 can follow. There is no reason why GNUstep cannot be a strong, multiplatform API AND provide the basis for a desktop/OS.

My point, quite simply is, that we must be the first one. The second one can be done in other projects. Examples of these projects are Etoile, Backbone and GAP. These projects all contain applications which make up a desktop environment on top of GNUstep. Once completed they will complement GNUstep's offering. The LiveCD provides the other part of this, which is a self-contained GNUstep environment that people can sample.

Plans for Change

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.

Chief Maintainer for GNUstep

I have been involved with GNUstep for seven years now, since 1999. It is my great pleasure to take leadership of the project so that I can help it grow. From my first commit to NSScreen to the latest Gorm nib modifications, this project has been a labor of love for me, and it will continue to be so for many years to come.

I sincerely hope that Adam will remain a part of the project. A "thank you" hardly expresses what the project owes him. You have our deepest gratitude, Adam, for everything.

Qt, Interface Builder and "Modern C++ programmers"

I just don't understand what it is about some people. While reading slashdot, I came upon this article at regdeveloper and I'm thinking to myself that it's nice to see another crossplatform library, aside from GNUstep, in the open source world, but when I get to page 3 the author pops up with this little tidbit:

In fact, on the Mac, I find the combination of Qt and C++ far more intuitive than the weird Objective-C language and the frighteningly non-intuitive Interface Builder.

Whoa there... did he just say Interface Builder is unintuitive? Wow.... of all of the lame brained things I've heard Qt developers say, this really tops the list. If you take a look here.. you will see that it is quite easy to learn InterfaceBuilder, or alternatively, GNUstep's Gorm.

Interface Builder is built on one basic principle: making connections between objects. That's really it. Everything else is peripheral. "Modern" C++ programmers complain about Objective-C because they are completely convinced that C++ personifies what is meant by Object Oriented Programming. In fact, quite the opposite is the case. The person who coined the phrase, Alan Kay, has specifically said that when he did so he was NOT referring to C++:

I invented the term Object-Oriented, and I can tell you I did not have C++ in mind.

He, in fact, had Smalltalk in mind. Objective-C, for the uninitiated, is a dialect of C which incorporates some Smalltalk like features. So, as you can see, it is not the weirdness of Objective-C or the "non-intuitiveness" of InterfaceBuilder, but it's really the closed mindedness and relative stupidity of most "modern C++" programmers which causes this type of thing to happen.

And, as we all know, it's much less common to be intelligent than to be dumb. Perhaps this explains why there are so goddamn many of them.

Nice To See Someone Feels The Same Way

It's funny, but this article here really cheered me up today. I've always, personally thougth the exact same thing about GNOME. It is butt-ugly. Nice to see someone else in this world has some sense.

New Release of GNUstep available!

The latest release is available on the ftp site. You can also go to the gnustep website to download. This version has support for NSStreams, RTFD, Nibs and lots and lots more... go check it out!

Nib Encoding Now Working in GNUstep

Although it's experimental at the moment it's working. As you can see here, I'm saving a nib file from Gorm to the "Cocoa Nib" format:














Here is the same nib file after being loaded into IB on OSX:














This functionality opens up all kinds of possibilities for GNUstep. It will ease porting by allowing developers to utilize one format or to easy translate from nib->gorm and vice versa. All Mac OS X developers need to do is to make sure they save the nib files as 10.2 or later, and GNUstep will be able to read the archives.

I'm going to continue refining these enhancements until they are perfected. They're very close at the moment, but like anything new they need to be shaken out a little.

Feel free to comment. Thanks, GJC

NeXTbuntu?

I read a blog today called "nextbuntu" it can be seen at nextbuntu.wordpress.com. A few things stated on the website are entirely false:

1) That GNUstep has changed the names of the classes "and everything"
GNUstep has done nothing of the sort. For all of the classes in the published API of OpenStep and Cocoa, we have used the same class names, constants, method and function names. Period. It is trivial to port applications from Cocoa or OpenStep to GNUstep so long as Carbon and the Core* libraries (for which we have no equivalent) aren't used. The only classes which use GS as a prefix are private classes which are not part of the NS (Cocoa) framework.

It's immediately apparent that no review whatsoever was done by NeXTbuntu regarding the current state of GNUstep.

2) Graphics makeover
This is something that has been on the top of my personal list, as GUI maintainer, for a long time. RIO and others have made some progress in getting this done on the theme branch.

3) Give the user the option of using cascading menus instead of the menu bar.
GNUstep currently has cascading menus, it also has the capability to show the menu as a menu bar on the top of the screen. To change it is a matter of changing a default.

All of these concerns are known and are being addressed in GNUstep at present. The goal of NeXTbuntu seems compatible with that of GNUstep. The only thing about his post that concerns me is his "dislike" of the GPL. Currently GNUstep is under the LGPL, which is a "lesser" version of the GPL which lacks certain things that some people don't like about the GPL.

4) Mac OS X/Cocoa compatibility
Porting from Cocoa to GNUstep or from OpenStep to GNUstep is quite easy. Please see this link: http://mediawiki.gnustep.org/index.php/Portability for more information. Also, recently, as you may or may not have noticed, I've implemented nib compatibility, so it's currently possible to read/write nib files for use on OS X.

Cocoa compatibility is one of the main aims of the GNUstep project. It's a very challenging one because Apple keeps adding things, so It's a moving target.

5) The Desktop Env. vs Development Env. issue
GNUstep needs to be both, or, at least, have a separate desktop project which is the official desktop.

Conclusion
I would suggest that the person behind NeXTbuntu should contact a member of the GNUstep team such as myself, Richard, or Adam to discuss collaboration. If you are planning on re-writing all of this stuff yourself, good luck, but it would go much more quickly for you to use GNUstep. Also, I suggest you drop the attitude that you seem to have, it won't make you any friends.

Nib loading working in GNUstep

As you can see from the screenshot, Gorm is now able to load nibs just fine.



Gorm should be able to save nibs in the next few weeks. This is a huge step forward for GNUstep. Builder and Loader classes have been added along with a factory class which gets the appropriate builder/loader for a given format. Gorm has also been changed so that it is effectively format agnostic. This means that it can accept any format that a builder/loader class can give it.

In addition to the above Gorm also uses the NSDocument* classes instead of implementing it's own framework.

Why Linux is boring

It seems, for whatever reason, that the Linux community has stopped evolving. We only seem to be heading towards one of two environments: GNOME or KDE. Now, of course, I'm not blind, this trend has been obvious for a very long time. It's amusing, however, that so many people buy into it. They don't see the potential for other possibilities, and they assume that anything which challenges the current two dominant players must be "nuts".

Is this the brave new world of open source? Will KDE and GNOME be all we have? I have looked at both and I am unimpressed with what they offer. Both are poorly designed, amateurish pieces of software. They both feel like they have "evolved" to this point and were never *designed* to be like this. In my next few articles, I'll examine them both further.

A couple of ideas

A few ideas have been rolling around in my head recently:

• Champollion -- OSX app, most likely will need a kernel extension.... translator from x86 -> PPC (the opposite of Rosetta.app)
• GNUstep ABI compatibility with Mac OS X. (suggested by aurynn)
  

Both of these seem like good ideas to me and I wanted to get the out someplace. ;)

GUI Maintainer

I was made gui maintainer of GNUstep today. I will try to take the project forward as much as possible.