The NeXT-Best Thing: GNUSTEP 0.9.4 Live CD

roard writes "Following the NeXT tradition with mixed case, GNUSTEP is a live CD/distribution while GNUstep is an implementation of the OpenStep API. GNUSTEP is based on Morphix, and uses the GNUstep libraries and GNUstep-based applications to provide a NeXTSTEP-like environment that people can easily test and use. This new 0.9.4 release comes 8 months since the precedent 0.5 release, and brings a lot of new GNUstep applications with it, as well as an upgrade of the GNUstep libraries and the development tools. In other news, a small demonstration of GNUstep development tools is available in Flash or divx. The old dream of having a GNU OS with Hurd and an OpenStep implementation doesn't seems that far now ;)"

Comments

wHy WaS NeXT nAmED LiKE ThAT aNyHoW?

[JessLeah]

i'Ve aLWaYs wOndEReD.

Re:wHy WaS NeXT nAmED LiKE ThAT aNyHoW?

[BlueGecko]

NeXT has that capitalization because the original NeXT logo had that capitalization. It had that capitalization because the artist wanted to emphasize several adjectives that started with e (I don't remember them at this point, but they were words such as excellent, extendable, educational, and so on) so he made the e lowercase.

NEXTSTEP the operating system is and always has been all caps. OPENSTEP the operating system has also always been all caps. OpenStep the API specification is capitalized in camel case, and I'm not going to touch NeXT's computers, because I always get them wrong.

Hurd?

[Digital Pizza]

Does Hurd have anything to do with this? (Can't get to the article). I don't see how this brings the Hurd closer to "release", any more that it does Duke Nukem Forever.

Re:Hurd?

[Pflipp]

Like Hurd was the perceived GNU kernel, GNUstep was the perceived GNU GUI.

Re:Hurd?

[TheRaven64]

GNUstep, like HURD, is a GNU project that has been going on for ages (it predates KDE and GNOME), without appearing to get close to completion. Unlike KDE or GNOME, which can incrementally add and deprecate features and APIs (potentially ending up with the same mess of legacy interfaces that plagues Windows), GNUstep is implementing the OPENSTEP API, jointly developed by NeXT and Sun. This meant that it was not particularly usable until it was about 90% done. This happened in the last year or so which, combined with the introduction of OPENSTEP into the mainstream in the form of Cocoa on OS X, lead to an increase in interest in GNUstep.

The relevance to HURD is tenuous, but I recall Roard mentioning recently that he had seen a demo of a GNUstep desktop running on top of HURD, giving a 100% GNU desktop. Perhaps this is what he was referring to. It doesn't bring HURD any close to release, but when HURD is ready (Real Soon Now(TM)), it is likely that there will be a GNUstep desktop waiting for it. If only the GCC developers would commit Objective-C++ to the main tree and let is have a WebKit-based browser...

GNUstep works on hurd

[Anonymous Coward]

with a really small patch to libobjc,
available in a gcc/libobjc bug report.

GNU's not Unix - but it is, apparently, Mac OS X

[1010011010]

Microkernel, unix-like userspace, Nextstep-based application development?

Right here.

This Should Be THE Desktop Environment for Linux

[jkheit]

This UI and development environment seems so much better than the standard KDE/GNOME stuff, I've always wondered why this was not championed as a default desktop environment for Linux. There is also some OS X compatibility there as well as far as getting a single code base to compile for both environments. That, the unified display postscript, the great development environment, etc. seem to make it a natural and *sane* front end to the otherwise fragmented UI world of Linux.

With the relative compatibility to the OS X/OPENSTEP libraries and code re-use, there could be a real network effect by making this a default environment for Linux and other Unixes.

ISO download sites

[tarzeau]

Thanks Department of Physics, ETHZ, GNUSTEP-i386-0.9.4.iso
Thanks inode.at and Robe GNUSTEP-i386-0.9.4.iso
Thanks Lyle E. Dodge, GNUSTEP-i386-0.9.4.iso
Thanks Philipp, GNUSTEP-i386-0.9.4.iso
Thanks Daniel Aubry, GNUSTEP-i386-0.9.4.iso
Thanks Peter Samuelson, GNUSTEP-i386-0.9.4.iso

Re:Nice Demo

[TheRaven64]

Actually, that's not the cool thing. The cools thing is that the simple app with two lines of code implements the Model-Controller-View pattern. This means that this development approach is 100% scalable to large projects. Oh, and the fact that the output from GORM is a set of serialised objects, so you can instantiate them from the code with the same ease that you would create an object from within your code (particularly useful in document based applications where you'd want to create a large number of identical document views connected to different models).

Made with ibuild

[eburner]

I just wanted to note that this was created based on morphix using a tool called ibuild that eases creation of Linux LiveCDs.

Interesting how this post appears....

[linguae]

I was just looking at OpenStep/GNUstep/Cocoa stuff before browsing Slashdot today, and I came here to search for old GNUstep articles. Interesting....

Anyways, GNUstep sounds like a very interesting platform. I have always been fond of NEXTSTEP and Mac OS X, and I have been curious about Objective-C and Cocoa. GNUstep gives me an opportunity to learn Objective-C and the OpenStep specification, before I switch to Mac OS X. I seem very impressed by the development environment, and as soon as I build up my C programming skills and learn Objective-C, I'll be developing programs, too.

I only wish, though, that GNUstep was a bit more popular among developers. GNUstep seems to lack programs such as web browsers, word processors, and spreadsheets. Porting applications such as Firefox, Abiword, and Gnumeric, for example, would be difficult because those applications are written in C++, not in C. (GNUstep still doesn't support Objective-C++, because of some difficulties that Apple and GCC has with Apple's Objective-C++ implementation). Even so, I feel that GNUstep has the potential to become a very powerful and influential platform for developers. If it can build its developer base and developers start building applications that are just as good, or better, than what NEXTSTEP and OPENSTEP offered, just imagine the possibilities....

Re:Interesting how this post appears....

[HeghmoH]

C and C++ are unique in the world of Cocoa as being extremely popular languages that don't have a bridge to Objective-C. Most popular languages out there are dynamic enough that writing a bridge isn't too hard, so you can access Cocoa or GNUSTEP from Python, Perl, Lisp, etc., but C and C++ aren't. Of course it doesn't matter for C, because it's a proper subset of Objective-C and you can just write a bit of glue code.

C++, however, is not a proper subset of Objective-C and you can't mix the two. That means that you have to drop down to the least common denominator, C, and write a bunch of glue between the two which makes for a royal pain in doing any integration.

Apple solves this with Objective-C++, which lets you mix the two, but for now it's an Apple-only language.

Re:Man screw that

[TheRaven64]

Yes. Most of AppKit works. The things that don't are largely bells and whistles which are nice but not essential (and even they are being added slowly). The real problem is that you can't use the same interface definition files on both GNUstep and Cocoa at the moment. Work is currently underway on two fronts to fix that:

1. Adding the ability for GORM to parse XML .nib files from Interface builder.
2. Compiling GORM on OS X linked against Cocoa rather than GNUstep and using it to create Cocoa .nib files directly.

At least one of these should be possible in the next few months.

The Windows port more or less works (transparency in images is broken. Everything else seems to work). Additionally there is a bundle (not yet in the release) which creates Windows-style menu bars instead of GNUstep ones for use on platforms like Windows, KDE and GNOME which are designed by people with no clue about Fitts' Law.

Additionally, Cameleon, the theme engine developed by the article submitter is nearing completion (it's been ready in the next week since the middle of January), and it will eventually be tied in with native theme engines for other desktop environments (including Windows) to give a completely native look for GNUstep apps.

yeah... but it looks like its from the 80s

[samhalliday]

really, it looks terrible.

it is a good framework, and brilliantly implemented in OS X... but this GNU look is really awful! they need artists... LOTS of artists.

i could barely even follow the demo as the IDE and general look of the thing was so confusing and horrible that i wasn't able to even see where the obvious buttons were to press.

they may be doing wonders with implementing the whole framework... but it needs polish.

Re:yeah... but it looks like its from the 80s

[Coryoth]

To be honest, yes. You can see the issue most clearly by comparing this and this. One is GNUMail compiled under GNUstep, the other is the very same GNUMail compiled under MacOS X.

To my eye, for reasons I can't fully explain, at first glance the GNUstep version looks more cluttered and complicated even though some inspection will show all the same UI elements in the same places with the same icons. It's the colors, and the sizing and style of the widgets, and just the general feel given off by the look as a whole.

Jedidiah.

Re:yeah... but it looks like its from the 80s

[linguae]

I agree, too. Judging by the screenshots, the Mac OS X port looks very attractive and, to my knowledge, follows the Apple Human Interface Guidelines completely. Heck, it looks just as good as the Mail.app bundled with Mac OS X. The GNUstep version, on the other hand, doesn't look as attractive. Assuming that GNUstep applications follow the design of NEXTSTEP applications, it needs some work. The toolbar should look like buttons, not like an Internet Explorer 3.0-esque design. I also don't really like the arrangement of some of the widgets.

This is an example of the NEXTSTEP Mail.app program. You can see that the GNUMail.app application got many parts right, but its interface still needs some cleaning up to do.

Re:yeah... but it looks like its from the 80s

[Coryoth]

I've seen that page. There is one skin that doesn't address some of the fundamental issues that make GNUstep applications to ugly and clunky looking. Adding gradients does not a good GUI make. Consider the Industrial theme for GTK - very popular, and a very nice theme, but it is also fairly flat and simple.

The big issues I tend to have with GNUstep GUIs are

(1) The big chunky controls. In comparison to the font size all the GNUstep controls are huge boxy things adding to the cluttered look.

(2) List selector widgets: You know the ones, the NeXT file manager used them. They need horizontal scrollbars usually. As far as GUIs go that's not a very efficient or pretty way to manage things. NeXT had some very good ideas. That wasn't one of them. The world has moved on.

(3) Floating menus: MacOS puts the app menus across the top of the screen to "obey Fitt's law", most everyone else has them at the top of the application. GNUstep kindly has them as bizarre free floating objects. Once again, not one of NeXT's better ideas. Can't we move on from slavishly copying NeXT?

(4) Empty scroll troughs: Nice big (due to those huge widget controls) areas of the screen that have no obvious function until you get enough items for the scrollbar to appear. Either put a full size scrollbar in there, or have the scroll widgets appear when required. Again, slavishly copying NeXT even on their "not so good" ideas.

There's a reason no one else took up these particular ideas from NeXT, not even MacOS X which is essentially the next generation NeXT. The reason is that they aren't very good - at the time (early 90s) they looked promising, but we've had GUIs for a long time now, and ideas of what works and what doesn't have come a long way. For some reason GNUstep slavishly follows NeXT even in their foolish early 90s mistakes.

Jedidiah.

One STeP Beyond

[Doc Ruby]

That demo is pretty nifty. But still too much typing: not just to bind the object interfaces to each other, but also in the controller coding. Is there any way to draw flowchart-style graphical indicators between object interface GUI representations? And any way to drag/drop primitives like the "*" and "=" operators into scopes of objects, much like drag/dropping the GUI textfields into their group? Finally, does it run on Linux ;)?

Re:video

[Wordsmith]

It's a codec that might be contained within avi files, or wmv files, or mov files. MPG files are explicitly mpegs.

Now, to make it even more fun. divx is an implimentation of mpeg-4. So even through it's not an mpeg1 or mpeg2 file, in a sense, it's still an mpeg file.

There ARE no viruses.

[GFLPraxis]

Opener, to name one. ASTrojan to name abother. Why is there OSX antivirus software? (Which I'll admit is useless, because viruses aren't a real threat on OSX, even if they exist)

Trojan /= Virus. Look it up.

There are two trojans and NO VIRUSES. Opener does NOT self replicate, nor does it use any vulnerabilities (you have to deliberately execute it and then type in your password for it to install itself). Therefore it is NOT a virus.

And there are many OS 9 viruses, and Word Macro viruses (not a threat to OS X, but a thread to your Word documents), which explains the OS X antivirus software.

But the fact remains, there are no viruses. There is only two trojans, both of which require you to install them yourself.

Looks neat, but...

[david.given]

The demo's very impressive; I particularly like the connections feature for setting up relationships between different objects. I wish Glade had that.

I do, however, have two minor criticisms.

Firstly, please, please update the look-and-feel. If you want to be taken seriously, don't look like a reject from the 80s. Given GNUsteps modularity, this should be easy enough to do. So, do it. (Tip: application icons should always have labels, because since they're supposed to be unique you can pretty much guarantee they're going to be unfamiliar to someone.)

Secondly, I didn't see any support for layout management in Gorm --- that application was constructed by just placing absolute-sized objects at absolute positions in a window. Please tell me this isn't how you design all applications... because that way leads to inflexible, unscalable, uncustomisable applications, and there's no excuse for that any more. Fixed layouts mean you can't let the user change fonts, because different fonts are different shapes (you can't just scale linearly). Fixed layouts mean wasted screen estate (remember the old Mac file browser dialogues that would float a tiny, eight-line scrollable list in the middle of a 21" monitor?). Fixed layouts are just wrong.

Re:Looks neat, but...

[roard]

Firstly, please, please update the look-and-feel

Like I said in a previous comment, I'm working on Camaelon 2, a pixmap theme engine that lets you have pretty things.. it should be officially released before the end of this month (it already works, I just want to clean up things).

I didn't see any support for layout management in Gorm

Well, I didn't show that part, but that works exactly in Gorm like on InterfaceBuilder on OSX (and imho it's a better model most of the time than the springs). So of course you can have resizable widgets. In addition, GNUstep implements a couple of widgets implemeting the spring resizing model (that's used by Renaissance by the way, an XML framework for describing UI for GNUstep...), so if you *really* want the spring model, you can use it.

Re:Nice Demo

[TheRaven64]

GNUstep is a set of libraries that run on almost anything (Windows, most flavours of *NIX including OS X, Solaris and *BSD. Oh, and Linux). The files created by GORM are just a description of how to instantiate a set of objects, and connections between them. They will work on any platform GNUstep works on. Currently, they are not compatible with OS X, unless you install GNUstep on OS X (and then you won't get the native look). Any GNUstep code that doesn't use GNUstep-specific extensions (i.e. anything that starts with GS instead of NS) will work on OS X natively (you may need to include different headers, but that's about it), but you will have to re-do anything you did in GORM in Interface Builder. A port of GORM to OS X to eliminate this restriction is underway, but not ready yet.

Seeing the trees, but missing the forest...

[pschmied]

The appearance is only skin deep. Creating a theme that looks "good"? That's easy, get some graphic designers together with a usability safety inspector.

Writing a complete framework with rich, well thought-out object libraries? Now that is a feat. GNUStep is a lurker project that is getting close to hitting critical mass. They've got the hard stuff done that others are still swinging at but not quite hitting.

No, the GNUStep people have been much more concerned with laying sewer lines, roadways, electrical grids, water, gas, etc. When they get around to picking the color for their street signs, it'll be good.

Some work is already going into theming.

Now that GNUStep is getting really close to being complete, I hope they look at Cairo as a base for doing something similar to Quartz.

-Peter

Re:Seeing the trees, but missing the forest...

[TheRaven64]

Now that GNUStep is getting really close to being complete, I hope they look at Cairo as a base for doing something similar to Quartz.

The GNUstep GUI components are in two models, a front, which talks to the program, and a back, which talks to the windowing system. Under X11, there is an xlib backend (which looks hideous) and a libart backend which looks a whole lot nicer. Additionally, work us underway to produce an OpenGL backend, which will almost certainly be faster than using OpenGL via a layer of indirection like Cairo.

Re:This Should Be THE Desktop Environment for Linu

[bnenning]

As for OS X compatibility, name one OS X program that has been ported to GNUStep.

There's many more than one.

Hellooo?

[melted]

http://ipw2200.sourceforge.net/

This is developed (apparently) by folks from Intel. It's just that nobody can't be bothered to include it into the kernel.

ACPI spec is publicly available, but nobody can be bothered to fully implement it.

Finally, nice examples of UI are available even within OSS community, yet every distro out there ships with UI that was, it seems, put together by a teenager.

Agreed

[Lysol]

I've always like NeXT and Windowmaker much better than Gnome and definitely better than KDE (sorry K-guys, it's waaaaay too much like Windows).

In fact, even Gnome is too much like Windows; even tho it does incorporate some OS X like features as well. But it also seems too fragile and it seems to be going more along the lines of C# dev, which I'm definitely not partial to (it's a mistake guys!).

Obviously, I feel that NeXT/OpenStep got a lot of things goin in the right direction. Turning away from the copy-all-Windows-features mindset seems to be the more logical choice. Will Gnome and KDE still exist? Absolutely. But Windowmaker - regardless of its sometimes slow development pace - is much more of a joy to use than whatever the current default Gnome window mananger is.

I spent many years developing in a Windowmaker environment and they were quite productive. That time changed the way I looked at using my desktop and even though I've switched to OS X, I can still tweak it to work like Windowmaker. So I'll have to second it as the official desktop env for Linux, hands down.

Re:boring demonstration

[pHDNgell]

I wasn't that impressed by the demo either. Maybe I'm not "with it" enough to see the beauty in all this point-and-click programming, but I think I could have written the same demo app in Java/Swing in about half the time. And I'm by no means an expert Java programmer.

You could not have. Pointing out your lack of experience doesn't help your argument. Spend a few minutes developing for GNUSTEP/NeXTSTEP/MacOS X or whatever, and see what it actually does and how to use it, and you'll realize why people who are ``with it'' get excited about this kind of stuff. What I've found is that I will spend extra time getting my UI to be perfect (IB lets you not only define your UI in shape, actions, resizing, etc..., but also try it out to see how it acts when its resized, or how the buttons click, etc...).

MacOS X is definitely the direction to follow in software development. Native apps built in xcode with ZeroLink and even dynamic code replacement (i.e. smalltalk-style bug fixing from the debugger without restarting your app). So, no time spent linking, but you can use an arbitrarily large and automatically discovered compile farm while developing rich MVC apps quickly and easily.

Also, see what happens when more palettes are completed. If they had the WebKit palette, for example, they could've done a demo where they created a full-featured web browser in the same time (you can do this on MacOS X with *no* code). In the video that was going around of a NS 3.3 demo in 1992 by Steve Jobs, he created a pretty decent graphical employee database application in just a couple of minutes that would allow you to look up departments (with pictures), and look through the list of employees within that department (with pictures of the employees). Again, with no code.

The openstep objects are great to work with, though. I just ported an app from python to objective C just so I could use the URL loading kit from cocoa. That is a particular thing missing from gnustep that I'd like to get ported over (although, it may be part of the webkit that Apple was working in open source).

I've worked in quite a few GUI kits (raw X11, Motif, tk, awt, swing, morphic, nextstep, probably more I can't think of), and I can assure you the objective C MVC kit wins hands-down so far.

Anyway, give it a shot before you say it's pointless. It's very impressive and has huge potential.

Re:Come on!

[TheRaven64]

Well, I'd rather go with the GNUstep vision of duplicating and improving on OS X, than the KDE/GNOME vision of duplicating Windows...