The popularity of OS X among geeks in recent years has led to a lot more people discovering OpenStep through Cocoa. GNUstep provides a much-needed Free Software alternative, as David Chisnall explains.
GNUstep: A Free Software Alternative to OpenStep
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSAlert.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
My first contact with GNUstep happened some years ago when I had a look on a Linux machine which GUI reminded me a bit to the IRIX GUI I knew from my SGI. Later, when I moved to FreeBSD for my home use, I decided to use the WindowMaker window manager (see section 2). It’s fast, the keyboard support is great (especially with my Sun USB keyboard) and it feels very native, if you’re familiar with common UNIX GUIs (see section 10). It profits from the GNUstep concepts and libraries. Furthermore, I must admit that I’ve come to like Objective-C and the “you can see it – you can print it” functionality – very useful for software development purposes.
PS. Wrong topic; should read out “WindowMaker”
Edited 2006-11-12 02:28
PS. Wrong topic; should read out “WindowMaker”
Time to correct a few misconceptions here….
WindowMaker is a strictly a Window Manager and GNUstep is a development environment. Lots of people confuse the two. So, no, the topic isn’t wrong.
WindowMaker is the official window manager of the GNUstep project and offers the best integration with GNUstep applications. Also, contrary to popular belief, WindowMaker does NOT use any of GNUstep. It uses a library called WiNGs (WiNGS is Not GNUstep) to look like NeXTstep/OpenStep.
This is mainly because, at the time WindowMaker was written, much of GNUstep’s gui library wasn’t completed. This is currently not the case. GNUstep’s gui (AppKit) library is completely functional, as is base (Foundation). The project also has a fully functional clone of InterfaceBuilder called Gorm.
GNUstep has made a great deal of progress over the last few years and has been getting better and better… the thing we need most is interested developers who are willing to help us make GNUstep into something really great.
Later,
Greg Casamento
Maintainer: GNUstep Gorm and GUI.
I have to apologize for not beeing direct. You wrote:
“WindowMaker is a strictly a Window Manager and GNUstep is a development environment. Lots of people confuse the two. So, no, the topic isn’t wrong.”
That’s completely right and stated this way in section 2 of the artice. What i referred to using “wrong topic” was the topic of my post. I didn’t want to discuss “Pros and Cons”, I wanted to say a few words on the WindowMaker window manager and how he benefits from the concepts of GNUstep.
“GNUstep has made a great deal of progress over the last few years and has been getting better and better… the thing we need most is interested developers who are willing to help us make GNUstep into something really great.”
At least I have to admit that I consider GNUstep (rather than Gtk) for one of my next software projects. It’s well designed for software that professionals will use, so the addition of tons of “eye candy” isn’t needed.
Ah, okay… my apologies.
I thought you were referring to the name of the article. 
GJC
GNUStep is an implementation of OpenStep right? So how is it an alternative?
It’s an alternative in the same way Mono is an alternative to .Net. The fact that the specification and product have the same name can be confusing to a couple people. It is specifically an alternative to OpenStep the product.
OpenStep is the API spec, OPENSTEP is the product. So, as you point out, while the similar titles may be confusing, the title of the post is wrong.
With quite a few developers vocally supporting mono these days I really wish there was a push in the free software community behind the GNUstep environment. I really think the architecture of the whole thing is beautiful and really wish there was a push behind it. Granted some things are in need of updating, such as a modern theme that looks better on today’s displays. (but chameleon is taking care of that) But it has a degree of simplicty that isn’t seen a lot these days. Yes OS X and Cocoa is the obvious exception, but it would be nice to have a free alternative; however, I’m not saying that I want a clone, but merely something designed along the same principles.
Edited 2006-11-12 03:58
openstep is more or less dead w/ regard to the visual aspects of their controls, etc. so long as it looks like NeXT on every platform it runs on (that i’ve seen, specifically on windows and linux) they can’t seriously expect to make any traction. even apple’s yellowbox made some attempt to blend in to the platform.
admittedly, i’m not familiar with their latest stuff, so please ignore this if its not an issue anymore and please let me know, as i’d be eager to give it another spin.
GNUstep is about more than OpenStep. GNUstep also tracks many of the changes that are in Cocoa as well.
While we don’t implement every little class Cocoa contains there are some simple to follow guidelines for making sure your application compatible.
As for themeing, that is something that is high on the agenda for the next few months.
GJC
Maintainer: GNUstep Gorm/GUI.
As for themeing, that is something that is high on the agenda for the next few months.
thanks for your post, that was very helpful. that seems to just take care of osx and the windowmaker environment though. are there any plans to make it so that one can make their application’s menu fit into the platform its running on better? i’m specifically thinking of something like gnome or win32 where the menu is typically associated and located in a window rather than floating elsewhere on the desktop.
Well, with Camaelon theming is already possible, for those who like to “ruin” it
I don’t know how well it works, since my GNUstep installation is b0rked at the moment (apparently it’s a bad idea to combine Gentoo, GNUstep and gcc-4). But from screenshots it seems to be quite nice looking without ruining the good look too much.
The only reason I found out about GNUStep was because of MacOS. I had so badly wanted a pleasent interface on my PC that was not heavy and sluggish, and when I found out that GNUStep was related to MacOS, I tried it. It remained my primary environment for a year, until I got a mac.
I loved using it. The interface was fairly tranparent, and it never got in the way.
I am glad to hear that it is still being worked on.
I have never used the GUI layer, but I have built some serious distributed computing using the Foundation layer. I was extremely impressed, it is rock solid, and allows VERY easy building of sophisticated multi-threaded and multi-machine applicaions. It is hard to describe how truly elegant the Foundation distributed-objects model is, and how much housekeeping code just disappears with the Foundation.
The program was a real-time analysis for Gamma-Ray Bursts with the very high energy telescope Milagro. The Foundation allowed me to build a very fast and efficient search, and it has been running continuously (except for power outages) for 4 years analyzing 2k events/sec, with no errors or memory leaks. I could not have built it without the great Foundation library.
Aren’t many OS X apps coded with POSIX/BSD, Carbon, Cocoa and the Core Foundation, Core Data, Core Image, Core Video and Core Sound APIs?
As I understand it, Carbon and Cocoa both have ways to access most of the Core APIs, and most of the Core Foundation API for C already has been mostly implemented by Apple.
If a project was started to create a way of running OS X Cocoa applications through GNUStep/CF-Lite, then at the moment it’d be able to run many utilities that are plain Cocoa and Core Foundation.
Implementing the Core Image, Data, Video and Sound APIs on Linux could use technologies such as GStreamer and GEGL (if it’s ever finished) and would be of use to Linux developers as well as users of OS X applications. A binary format loader for loading mach-O’s would need to be created and something to help link it to the libraries on Linux.
It seems that there’s a lot less work to do than there is to do on WINE, since much work is done and given the relatively clean start OS X had, it’s a lot cleaner than the Win32 API code base. Also, given the recent Intel migration and AIGLX/XGL taking off… it seems that OS X Application on Linux isn’t too far-fetched..
The hardest part I suppose would be implementing Carbon for things like Photoshop. Still, it seems easier than the Win32 API. Given that the security model on OS X is very similar to Linux due to the UNIX foundations and that applications are already coded with home directories and permissions in mind, and that CF-Lite, GNUStep, WebKit, etc. and indeed Darwin are OpenSource….
Edited 2006-11-12 15:15
I would be interested in reasons that a Gnome or KDE user should care about GNUstep, or be interested in using GNUstep.
Please note that I am not implying that GNUstep is useless, but sincerely asking for reasons that GNUstep matters. Might we have been better off putting resources into GNUstep rather than writing Gnome and KDE from scratch? And in what ways are Gnome and KDE superior?
Edited 2006-11-12 17:26
Well, it depends where you place yourself — as a developer, GNUstep is extremely well designed, and without a doubt was a much better foundation than Gnome or KDE to focus on ten years ago. But, few people had experience with OpenStep, hence the low participation on the project.
KDE and gnome actually started (partly) thinking that they were short-term solutions before GNUstep would be completed. Of course, while they gradually, iteratively evolved in interesting solutions and attracted more and more developers (and everybody knows it’s easier to be attracted to a project that *works* right now, even if it means you’ll need to redo everything every couple of years to get it right), GNUstep in the meantime didn’t have much more developers, so while it progressed, it did so at a much lower pace, etc. A vicious circle.
So well, while it would have been preferable and much more efficient to work on GNUstep (specifically because the blueprint was/is so much better than the rest), the free software community is not a directed effort, and it’s not surprising that people focused on short term gain instead of long-term efforts (it’s also partly what happened in the Hurd vs Linux debate).
Anyway, that’s the historical analysis; the question is more “ok, fine, but what’s interesting about GNUstep now ?”
To that, well, the answer is simply that it is still an extremely well designed framework, and have inegaled tools like Gorm. As a framework to develop GUI applications, GNUstep (or Cocoa) is simply the best thing ever, really. Ask any developers that started playing with Cocoa or GNUstep, they don’t want to go back to anything else.
Beside beeing very well architectured and rather well implemented, as a toolkit you get a lot of niceties for free (vector based drawing system, wysiwyg, services, distributed objects, notifications, serialisation, defaults, etc).
Now if you are talking from the point of view of a Gnome or KDE user (not as a developer), … well, GNUstep is not a desktop, so you shouldn’t really compare it
That’s actually one of the “problem” in a way, of GNUstep; it’s not a desktop, yet the frameworks provide the applications all they need to act as a cohesive whole — so simply by using a bunch of GNUstep applications, they can cooperate and work together, well integrated, “as a desktop”.
To have a “GNUstep-based” desktop, you can thus simply take a file manager like GWorkspace, use something like WindowMaker as a window manager, and use the apps, period. Such a desktop is imho interesting (compared to gnome or kde desktops) because of the tight cooperation between applications, because it’s fast, because the UI are generally well crafted, by people that often care about ergonomy (not saying that gnome or kde are all bad, mind you, just that gnustep apps tend to “feel” cleaner to me — and simply because it’s so easy/fast to modify UI in GNUstep that you simply do it until you get them right).
If you want to try such a desktop, check the GNUstep live cd http://livecd.gnustep.org/ . Else, there is the étoilé project, which aims to create a gnustep-based desktop http://etoile-project.org (check the blog too http://www.etoile-project.org/etoile/blog/ )
Now, in what ways gnome and kde are superior ? Well, gnome is only superior in that it has legions of developers and some nice applications. KDE is technically very cool and already offers a nice desktop and cool applications, but technically I prefer GNUstep/ObjC to C++ (by far), and KDE tends to be a steam factory (?) — from that point of view gnome tends to be cleaner (though the gnome framework is a complete mess).
Edited 2006-11-12 18:08
Who on Earth did you talk to in ’97 that made you think that GNOME or KDE were stopgaps for future GNUstep developments?
What do you mean by that.
As an aside, it seems to me inaccurate to describe KDE as being written in C++ since Qt itself uses MOC which sort of builds this language on top of C++ that really deserves to be considered it’s own super set, not as drastically as C++ to C but along those same lines.
Are the internals of KDE written in pure C++ or are they also written in Qt ?
didn’t know if this expression translated in english or not — it means .. hm, kind of overly complex, bloated. I’m not saying that about the frameworks themselves — Qt is really neat — but about the desktop itself. They tend to be in the “to be perfect is when you can’t add anything more” category, while I’m in the “to be perfect is when you can’t remove anything more” one.
As an aside, it seems to me inaccurate to describe KDE as being written in C++ since Qt itself uses MOC which sort of builds this language on top of C++ that really deserves to be considered it’s own super set, not as drastically as C++ to C but along those same lines.
MOC is just a preprocessor that lets you adds signals and slots to your objects, indeed resulting in Qt beeing a much nicer library than many others.
It’s also actually a bit similar to the way Objective-C works (sending messages), and obviously how you program with GNUstep/OpenStep/Cocoa (but imho, OpenStep is much better designed than Qt). Let’s put it that way : if there were no Objective-C and OpenStep available, I certainly would code in Qt for GUI apps. As it is, I won’t, because I’m vastly more productive with Objective-C and OpenStep (Cocoa or GNUstep).
Edited 2006-11-12 19:54
I agree with you regarding the beauty of Obj-C/Cocoa/OpenOrGNUStep but I have to disagree with you regarding Qt. I would love to deploy applications on Linux/OSX/Win in GNU/Cocoa/etc, but it is no where near as easy as with Qt. I just throw 2-4 libs in with the app and I’m golden. Under the various *Step stuff, it is not so easy, or am I missing something?
The MOC extends C++ trivially.
Well, apart from the clean design (API-wise as well as UI-wise) I’d like to mention the performance. Systems like Gnome and KDE suffers from the same design issues as Windows2000 and newer. They are _bloated_ codewise, sucking too many resources. That’s why I tend to fall back on GNUstep.
Unfortunately it’s still missing quite a few applications in order to be a real replacement, despite the framework being ready.
Personally I dislike GNUstep’s GUI. GNOME and KDE are looking modern while GNUstep looks old fashioned. I don’t need a GUI to do the job so I prefer the commandline over a GUI that’s no eye candy at all.
Take a look at étoilé ( http://www.etoile-project.org ) and camaelon ( http://www.roard.com/camaelon/ ).
heh, the NEXTSTEP GUI is one of my alltime favorites
I love it. i’d rather use it than KDE/Gnome anyday… Funny how different peoples preferences can be.
>>> As for themeing, that is something that is high on the agenda for the next few months.
I think the GNUstep project would greatly benefit from dropping WindowMaker as the official window manager, and going with Gnome instead. Another step forward is for GNUstep’s AppKit to support GTK natively, and include wrappers for freedesktop technologies such as Cairo, FontConfig, Enchant, GStreamer, FreeType, etc.
This would instantly create a mature alternative to Mono for developers that are interested in both Linux and Macintosh as target platforms.
PS — I didn’t mean to exclude KDE. With my limited understanding, it seems Gnome’s GTK toolkit is still mostly C-based, so it would be a more logical candidate for integration with GNUstep than KDE (C++).
I think the GNUstep project would greatly benefit from dropping WindowMaker as the official window manager, and going with Gnome instead.
Er… WindowMaker is the “preferred” WM, but that’s all. Gnome is not a window manager, it’s a desktop. A GNUstep-based desktop doesn’t NEED to use window maker — for instance étoilé has its own window manager, Azalea.app .
Another step forward is for GNUstep’s AppKit to support GTK natively, and include wrappers for freedesktop technologies such as Cairo, FontConfig, Enchant, GStreamer, FreeType, etc.
Why support GTK ? it’s a much worse framework than GNUstep’s AppKit ! beside, we have a Cairo backend, we use FreeType, etc.
Edited 2006-11-12 19:27
Another step forward is for GNUstep’s AppKit to support GTK natively […]
I beg to differ, but… http://www.informatik.uni-osnabrueck.de/elmar/projects/gtoolkit/
here you go.
I remember clearly miguel evaluating gnustep at the time, beside I remember quite a few “oh well anyway GNUstep will be here in a couple of years” kind of comments. Considering how limited was Gtk (conceptually) it made sense. Obviously that position quickly went the way of the dodo, but it was true at the very beginning — in the same way linus thought that GNU hurd would take over the next few years when he started linux.
Edited 2006-11-12 19:25
Miguel superficially attempted to work on GNUstep before starting GNOME, and tossed that in favor recreating COM with CORBA. No one in KDE or GNOME that I can think of had any real interest in developing in GNUstep, or believed that GNUstep would ever “catch up” to fill in the role. GNUstep had already been in development for a pretty long period of time and had less actual work done and little future development interest due its development language. In fact there was some minor interest in creating some ObjC bindings for Gtk+ (which bitrotted) even with some OpenStep dev tool goals but that went nowhere as well. I pretty vividly remember that period of time, and I cannot think of anyone that actually believed what you’re saying to be the case.
I was merely talking about the very beginning, when GNUstep was still supposed to be the GNU desktop. As I said, that quickly wasn’t a concern, for the reasons you state (Objective-C vs C, lack of interest in OpenStep). But I do remember some comments along the lines when the projects started; I agree they probably were very short-lived
That beeing said, I still believe it was stupid to not work on GNUstep, but I’m really biased here, so take that with a grain of salt
Update:We did try for a few days to work on the GNUstep project. Francisco Bustamente (bit), Federico and I would be working on getting the whole thing to work, but it was too big, too slow, too buggy, too incomplete and there was little organization in the team. After repeated attempts to work on it, we eventually gave up.
From http://primates.ximian.com/~miguel/gnome-history.html
>>> Why support GTK? it’s a much worse framework than GNUstep’s AppKit! Besides, we have a Cairo backend, we use FreeType, etc.
Because Gnome/GTK has a lot of momentum, while AppKit has none. For GNUstep to escape the proof-of-concept phase, it needs to face reality and support either Gnome or KDE. Look at Mono. It has achieved more in a few years than GNUstep has in a decade.
If AppKit becomes GTK abstraction layer (like Windows.Forms) where apps on Linux use GTK and on OSX use Quartz, GNUstep could be just as popular as Mono. Also, by pooling resources, and defining one clear target platform, Mac developers would be presented with an extra audience for their (niche) applications.
As long as GNUstep remains a great tool to develop applications for WindowMaker or 12 other obscure environments, you limit the potential audience to zero.
There are some points that I wanted to clarify:
Because Gnome/GTK has a lot of momentum, while AppKit has none.
– That is (sadly) true but that’s not the point, GNUstep is based on the OpenStep specification but also on the spec’s clean design and philosophy. Although the abstraction layer could technically be made, I think that time and ressources needed for such as task would be better used improving the existing GNUstep solution (Foundation/AppKit, addional frameworks, apps, WM…) which is what the étoilé project guys (among others) try to do.
For GNUstep to escape the proof-of-concept phase
– While it’s true that GNUstep doesn’t have the attention/devs/user base it really deserves, GNUstep has passed the “proof-of-concept” phase for some time now from the technical point of view.
Look at Mono. It has achieved more in a few years than GNUstep has in a decade.
– Again this is true but incomplete because Mono fully enjoys the popularity of C# (which – as you surely know – is more hyped than ObjC as ever been/is/will ever be) then the project obviously catches attention/ressources of many people/devs/investors.
GNUstep could be just as popular as Mono
– That is not true since such a situation would require ObjC to be “as popular” as C# and unfortunately that will not happen any time soon.
As long as GNUstep remains a great tool to develop applications for WindowMaker or 12 other obscure environments, you limit the potential audience to zero.
– WindowMaker is a window manager, GNUstep can be used with about any window managers you want because GNUstep has nothing to do with WMs by itself. Use metacity is you prefer.
I’m sorry but I fail to understand how an AppKit/Gnome/GTK hybrid monster could leverage the GNUstep “potential audience”.
WindowMaker is a window manager, GNUstep can be used with about any window managers you want because GNUstep has nothing to do with WMs by itself. Use metacity is you prefer.
You can even ‘run’ GNUstep without any window manager.
Please do not get me wrong—I have toyed with GNUstep a bit, and I am generally well-disposed towards it, in principle.
In my view, the main problem wiht GS is that there are too few developers to really push the framework forward, so that it can be competitive with the big guys (Gnome and KDE, that is) on the desktop.
One way to maybe attract attention is to try and use it as a bridge between OS X and Linux/*BSD etc. . There is already some work in this direction (e.g. GNUMail.app, or the Cocoa/Gnustep port of Emacs). Ideally, one woudl take a popular, high-profile Cocoa app and try to use GS to port it. Open-source would be easiest, but shareware, too would be nice, I think—for instance, Textmate would be a perfect candidate in my opinion. [I seem to recall that, at least in Allan’s view, GS lacks certain features that Textmate uses heavily, e.g. bindings]. A WebKit-based browser would be nice too, perhaps. EDIT: I just noticed that an earlier poster made a similar comment. END EDIT.
The other, serious issue is the 80s look of the default GUI. This issue has been debated to death on the GS ml’s, but my impression as a “lurker’ was that many of the core GS developers do not fully appreciate how important this is for potential, “normal” desktop users. They see Gnome, or KDE, and they are smooth / glitzy / shiny / ???. They see GS, and it’s drab and gray. It’s like Java’s Metal all over again—and see what an unattractive GUI look did to the popularity of Swing (OK, speed was originallly an issue, too, but that was addressed long before the GUI look was).
Camaleon and the Nesedah look only exist in screenshots and CVS code—too hard to get a hold of for a normal use. And I would argue that even Neseday is a bit too understated and low-key to be attractive to a wide audience. [ Not that I want garish ]
Edited 2006-11-13 04:27
In my view, the main problem wiht GS is that there are too few developers to really push the framework forward, so that it can be competitive with the big guys (Gnome and KDE, that is) on the desktop.
The problem with this attitude is that it’s cyclical. The less “ready” it looks the fewer people will help the fewer people who help, the less “ready” it is.
Don’t wait for our small team to make things happen. If you like GNUstep and you want to see it made better, then please help us.
Greg Casamento
Maintainer: GNUstep GUI/Gorm
I’m sorry if I sounded cynical. However I know my limitations, both in terms of time and programming abilities. I am in awe of what the GNUstep folks have achieved. For example, Gorm is a beautiful piece of software, to be sure (although Qt Designer comes close)
I am just pointing out how things look from the point of view of a potential, non-contributing user.
If you wish to focus on developers, that’s fine. They can understand the potential of GNUstep as a framework. That’s why focusing on ports from OSX might actually be a workable medium-term strategy.
Personally… I think, even beyond the GUI issues that some people may have with it, there ought to be some focus on putting a friendly face on this whole environment for the sake of the user. Everything smacks of a ‘for developers, by developers’ mindset and there’s no real easy port of entry for a general user… It might be wise to look at what is already available for the development platform and try to make it a little more marketable and ‘ready to run’.
Say I read about GNUmail and think it would be great to have a cross platform email app to use under OS X and Windows. I shouldn’t have to do much more than pick the required binary (or binaries) and possibly a runtime for each OS. Instead I’m left with a feeling that I have to run around grabbing several packages, and then am expected to compile things in many cases. In this example, the cost of entry is too high and there are other freeware options available.
You’re going to have to attract more users to attract more developers, imo…
Edited 2006-11-13 08:21
GNUsteppers:
The world of KDE, Gnome and others inspires a certain high level of interoperability that hasn’t been achieved yet. There’s still a large amount of work to be done in this area, and the end result won’t be pretty or efficient. It will be a disjointed orchestra of musicians each playing a slightly different tune at perhaps a different tempo or rhythm. While it might be considered “music”, it’s not very good music.
I’ve fallen in love with GNUstep because it doesn’t tolerate impurities in the system design and isn’t concerned with interoperability issues at this stage of development. It plays its own tune and that’s good music. This is ideal and this ideal should be kept.
But the problem is that this is only on a system design level. I say that you guys should focus more on building your own distribution and screw interoperability for now, because your audience will not grow for as long as GNUstep is just considered the odd wonderchild of a larger group of ordinary people.
Build your own kernel or use an existing distribution template (a GNUstep Ubuntu?) and support only that, build a system at the terms of GNUstep, not on the terms of what everyone else does. It’s a waste of time to focus so much on supporting many different operating systems and Linux distributions, when there are only this few people working on GNUstep. I know it’s attractive to get GNUstep programs supported on Windows to provide a new Yellow Box. But this is not a good time to be doing that.
I would much rather see one single focused hardcore GNUstep distribution than having it slapped on top of 5-10 existing ones with poor support for bleeding edge GNUstep stuff. Make it easy to download and let any user start developing for it. This way you can bring GNUstep forward on its own terms.
Edited 2006-11-13 11:42
Let GNUstep be its own distribution
So instead of maintaining GNUstep with a handful of people, a whole distro has to be maintained?
I’ve fallen in love with GNUstep because it doesn’t tolerate impurities in the system design and isn’t concerned with interoperability issues at this stage of development.
I’m glad interoperability issues are of no concern after a mere decade of development. Given the vast application catalog for GNUstep (two calculators, a notepad and and a beta-version of TicTacToe). Come on!
Given the vast application catalog for GNUstep (two calculators, a notepad and and a beta-version of TicTacToe). Come on!
Ehem … http://wiki.gnustep.org/index.php/Category:Applications
So instead of maintaining GNUstep with a handful of people, a whole distro has to be maintained?
“A whole distro” would be GNUstep, a kernel, some drivers and the programs. Maybe a foundation from an existing Linux distribution could be used, but the idea here is to NOT support 10000+ odd programs from everywhere, but GNUstep only software.
My idea would be to create something like a free MacOSX which exactly is working on its own terms. It doesn’t have to resemble a normal distribution at all.
My idea would be to create something like a free MacOSX which exactly is working on its own terms. It doesn’t have to resemble a normal distribution at all.
Enter http://www.midnightbsd.org/
Not everything aside from Apple and Microsoft is Linux…
And of course, you can always use Darwin as a ‘foundation’ for a GNUstep based Operating System.
I’m sorry but I fail to understand how an AppKit/Gnome/GTK hybrid monster could leverage the GNUstep “potential audience”.
GNUstep may not need a window manager to function, but to develop an app with GNUstep that integrates reasonably well with the rest of a Gnome desktop (e.g. pick up system theme, use font chooser, color picker, file and print dialogs, etc.), it will need good Gnome/GTK bindings.
This will not create a hybrid monster, but a useful development environment, no different than Apple’s implementation to use Quartz/Cocoa.
If one look at the application catalog doesn’t tell you GNUstep is on the wrong track, then I don’t know what will:
http://www.gnustep.org/experience/apps.html
The problem with this attitude is that it’s cyclical. The less “ready” it looks the fewer people will help the fewer people who help, the less “ready” it is.
At this point, it’s unrealistic to expect to ever catch up with Gnome or KDE. So, if you can’t beat the big guys, join them.
GNUstep + GORM makes a great development environment. With proper GTK bindings, it might finally get the audience it deserves.
GNUstep may not need a window manager to function, but to develop an app with GNUstep that integrates reasonably well with the rest of a Gnome desktop (e.g. pick up system theme, use font chooser, color picker, file and print dialogs, etc.), it will need good Gnome/GTK bindings.
– Nobody, (personne, nunca) wants the GNUstep environment to be integrated with Gnome or KDE because those Desktop Environment have their own (and respectable) philosophy, programming language (mainly C++) and sets of API which are – in essence – uncompatible with GNUstep.
GNUstep devs/users love GNUstep because of its very elegant and efficient frameworks and they love it because you develop using Objective-C which is very powerfull OO language (and superior in many regards to C++). Believe it or not, but none of the the API you propose – namely QT and GTK – come close to GNUstep/Cocoa when it comes to simplicity, code elegance and efficience. Just like the Mono example in your previous post, QT & GTK strongly rely on the huge C++ popularity… (you know the end of the story
).
no different than Apple’s implementation to use Quartz/Cocoa.
Perdon ??? GNUstep is more or less equivalent to Cocoa, ok. But what about Quartz & GTK ??? GTK stands for Gnome Tool Kit and is an API to develop Gnome apps using C++, Quartz is the name of the compositing layer in OS X and is responsible for drawing vector based Text and shapes (or Bezier paths)… They have NOTHING in common ! It’s like comparing oranges and potatoes…. nothing in common so no intelligent comparison is possible. Both GTK and GNUstep rely on X to for displaying and catching user events. GNUstep way of displaying/managing events is just very usable and I don’t see any interst in applying and GTK interface based layer between X and GNUstep! GNUstep is themeable using Camaleon which gives a fresh and polished interface. Absolutely no need use GTK for this.
At this point, it’s unrealistic to expect to ever catch up with Gnome or KDE. So, if you can’t beat the big guys, join them:
– Your arguments really looks like those of the Microsoft fanboys when Linux was emerging… “if you can’t beat the big guys, join them.”
GNUstep has nothing to win relying on extern/unrelated API just Linux had nothing to win going Microsoft way.
GNUstep + GORM makes a great development environment.
– Hey I agree with you on that one !!!
With proper GTK bindings, it might finally get the audience it deserves.
– When will you understand that a “dev audience” is based on both a programming language and a set of API, for GNUstep to get the audience it deserves, people got to know Objectice-C which is not the case of the vast majority of devs hence no audience, period. Just give me one thing, one feature that GTK could add to GNUstep’s AppKit ??? None !!!
The GTK / QT devs won’t turn to gnustep because it would use GTK based back-end, rather they would develop it with the language they know, namely C++ and it’s just IMPOSSIBLE to create the most little GNUstep/Cocoa object with C++ (although Objective-C can access virtually any C or C++ libs) because it lacks many feature that Objective-C enjoys for more than a decade.
GNUstep + GORM makes a great development environment.
I won’t repeat what GStepper just said, because I agree in every aspect. Instead, I’ll ask: With an excellent development environment, why is the audience so little?
As I said before, I think it’s because GNUstep gets buried under Gnome and KDE in the “marketing department”. People got Gnome and KDE so why should they use a new environment now? This is why GNUstep needs to be for it self, rather than just sit along with the other desktop environment/development suites.
Any casual Linux user (who don’t browse forums like these), probably hardly have ever heard of GNUstep. They don’t know what it means, don’t know the history and don’t know what it stands for. All they see is an odd looking GUI. There’s actually quite a lot you need to know in order to find merit in using GNUstep.