Sunday, May 16, 2010

Progress on Plans for Change...

The old blog post is here. Even though it's been four years, I'm happy with where things are at the moment. Over the past few years the following things from that list have been accomplished:

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.

This has been accomplished by the Etoile folks without question. But my blog post was meant to push the project itself to adopt a more modern looking GUI. So far we haven't done that yet, but the mechanisms are in place now to do it. The theming engine is now much more capable than it was before and should be able to allow the creation of some killer themes.

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.

Given that our last release was last year and it's now the middle of 2010, we've still got a long way to go on this one too. This release, however, was a big one since it included a lot of functionality, not the least of which is the theme engine I mentioned above.

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

We have a GNUstep.conf file in /etc/GNUstep which environment variables get read from.

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.

This has happened. More free software and proprietary projects are starting to take notice of GNUstep and it's helped improve GNUstep since contributions have been made to the project which have increased stability, performance and efficiency for all concerned.

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.

This has happened just recently with Fred's recent change making Cairo the default backend. Cairo provides the ability for us to really forget about writing another graphical backend for any operating system that Cairo supports which takes an ENORMOUS burden off of the project and allows us to leverage the work done by the Cairo project.

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.

This has happened and has worked out pretty well. GNUstep has defined itself as a development environment. GNUstep is what powers a desktop environment whether that is Etoile or just WindowMaker with GWorkspace.

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.

The recent theming capability has accomplished this. :)

I believe we should commit ourselves to getting the rest of these tasks completed. They should all help GNUstep move forward. Right now stability, and more applications are key for the project.

Tuesday, May 04, 2010

An Artist's Concept of GNUstep's redesigned UI


A few years back Jesse Ross came up with this concept for a new look for GNUstep.

I'm wondering if there are any ideas/looks/concepts we can glean from this which might be of use. I have always liked the general look of it.

One person I talked to about it suggested being able to "dock" the menu bar. That is... attach it to a particular place on the screen, such as the border or something so that it could act like the menu bar on OS X, if we really wanted it to. Interesting thoughts. :)

Objective-C end of life?? Not a chance...

Recently, I saw this article regarding ObjCs "end of life" from JetBrains. The tiobe index seems to disagree. It’s also importa...