Slashdot Mirror
GNUstep On LinuxFocus
Dennis Leeuw writes "Linux focus has a very good article on GNUstep and it's status. It might have been a long time in the making, but they seem to pull it off." GNUstep doesn't get the attention that some of the window managers' get, but I think the diversity of the desktop interface is one of the more fun aspects of open source.
It most certainly does not use GNUstep libraries.
Stating on Slashdot that I like cheese since 1997.
Yeah, and there's only one word processor, only one web browser, only one sound editor in Windows.
FUD
Folks, is this in the Microsoft Employee Handbook yet?
Stating on Slashdot that I like cheese since 1997.
GNUstep is aiming to create a NeXTSTEP 3.3-like enviroment.
Actually, it's more like an OPENSTEP environement. Being based on the OpenStep public API, which has it's roots in NeXTSTEP.
Please note that capitalization is important.
Karma karma karma karma karmeleon: it comes and goes, it comes and goes.
Long answer: a lot, if you're talking about "do nicely" rather than "do inefficiently and with ugly code".
Specifically, ObjC has two features which the whole NeXT concept relies on quite a lot. First, all calls are made using stringified name and parameter signature. That means that all calls are deferred, and are tested at run time. The result is you can do very clever tricks by plugging in objects.
Second, you can (because that deferred call system means there's no binary offsets to break) fiddle with the insides of objects after their creation, or make other objects pretend to be the first. Even if you didn't create that object, you just loaded it from a precompiled library. This allows the lovely distributed objects system they have - a proxy object at the client end actually makes out it's the real server-side object, but just shoots the data down the line to another proxy server-side which is pretending to be the client object. Totally transparent after the setup - very sweet.
This stuff you couldn't really do in Java without jumping through hoops, because it uses C++ style function calls.
As a lark I can see it is a neat thing to do, but wouldn't you be better off just running OpenStep for Intel under VMware?
For several reasons: 1) OPENSTEP doesn't run under VMware; 2) OPENSTEP isn't supported anymore; 3) OPENSTEP is proprietary; 4) We want to use a *good* development environment to write cross-platform object-oriented software that is GPL.
As soon as Apple goes over to XML-based interface specs, you'll be able to very easily compile GNUstep apps on MOSX and vice versa. (You can actually do it now, and many have done it, but it will get easier). Note that this only applies to apps written with the OpenStep API. So, for example, Microsoft's Carbon version of IE won't run on anything but Macs.
Yeah, people have been saying that for a long time s/Forth/Lisp , etc. But no one has gone ahead and done it. Yet Unix has been implemented several times in C, and the first thing new systems do is implement a POSIX layer (i.e. eros). Why is this? Is C so much easier to implement large systems with? Is Unix actually a really useful design despite what some academics who have never built a practical system maintain?
Why burn bridges when you can nuke the whole river?
Luckily, this is not the case. Apple's effort to force the Java language onto Cocoa ended in a big bust because, hype notwithstanding, Java simply has too many performance problems. Most of the utilities re-written in Java for later Rhapsody builds are back in Objective C now, and the people responsible for the Java push are no longer in decision-making positions. The Objective C lovers are running things again, and Objective C is the preferred development language for MacOS X.
Apple's Stan Shebs has taken over the GNU Objective C compiler in GCC from Ovidiu Predescu, and is working to sync Apple's source base with GCC 3.0. He reports that they're working to even bring back Objective C++, for easy ObjC/C++ interaction.
What's more, MacOS X ships this Saturday, and the reports I hear are that it includes the development tools. That's going to bring Objective C to a whole new generation of programmers.
And if nothing else, there's the GNUstep project to carry it on. Objective C can only fade away if everybody stops using it. :-)
GNUstep is not a GUI theme engine. Far, far from it.
GNUstep (for now) consists of a number of parts: gnustep-base, gnustep-gui, gnustep-make, gnustep-db, and gnustep-web. gnustep-base
The GNUstep Base library is the counterpart to the OpenStep Foundation. Think of it as an extensive class library for Objective C. It provides basic classes for arrays, object dictionaries, strings, dates, high-precision decimal numbers, object sets, notifications, hash tables, and map tables. It extends Objective C a bit by providing object archiving, a powerful distributed objects system, exceptions, invocations, and forwarding. (You'll have to read up on ObjC to understand these latter two.) It also includes abstract classes for run loops, timers, mutexes, reading/writing files and URLs, tasks, threads, timezones and user settings. A couple of GNUstep extensions include an XML parser class, and a MIME handling class.
gnustep-guiThe GNUstep GUI library is the counterpart to the OpenStep AppKit. It provides all the widgets: buttons, sliders, pop-up buttons, images, text fields, Miller-style column browsers, menus, checkboxes, text areas, panels, et cetera. It also provides a color panel, font panel, help panel, and printer panel. And once finished, its text system is going to be quite powerful.
But the real magic -- the stuff that makes developers giggle uncontrollably -- is the interface builder, called Gorm. (NeXT already took the name Interface Builder.) OpenStep uses a fairly strict Model-View-Controller paradigm for its apps.* You write your model and controller in Objective C. Then, you put together your view (the GUI) in Gorm by dragging real, live GUI objects into place. You can test your GUI interface, right there in Gorm. Using the power of Objective C's runtime method bindings, it's a simple matter to hook the GUI up to your controller object with a few mouse clicks. Then, Gorm uses the archiver classes in gnustep-base to write the GUI to an object archive file. No code involved. (Not even behind the scenes.)
This scheme has some really cool implications. For one, the user can twiddle with the application's interface easily, without the need to look at code or re-compile the app. And the developer just needs to spend a few minutes with Gorm to create an entirely different GUI for a different platform. None of the Mozilla-style XUL interface that's not at home on any platform; it's a real, native interface, that hooks easily onto the app with no extra coding needed.
Now, to be honest, gnustep-gui will be this cool when finished. Gorm is still a work in progress, and there's only support for NeXTSTEP-style GUIs on X11 right now. Volunteers for other platforms always appreciated!
* The quick intro to MVC is that you have a set of classes which model your application logic, a view (i.e. the GUI), and a controller object to hook them together.
gnustep-makeThis is the makefile package which makes creating your project makefile easy. Of course, GNUstep ProjectCenter.app creates the makefile for you, so it's all done behind the scenes, if you work that way. gnustep-db
The GNUstep Database library is a work-in-progress counterpart to the Enterprise Object Framework. I haven't worked with either to really do a description justice, but I'm told EOF and gnustep-db are neat systems to handle large object graphs, typically backed by an RDBMS. You implement your application logic in ``Enterprise Objects'' and they're automatically insulated from both the storage backend, and the user interface, which makes distributed processing and code maintenance one heck of a lot easier. These objects are quite useful as the model in a GUI app, or for use in gsweb (below).
gnustep-webThe GNUstep Web system implements a system like WebObjects, for building Web applications on top of gnustep-db, or other of your GNUstep libraries. Again, I haven't used it enough to do a full description justice.
Anyway, that should give you a good overview of how much GNUstep is not a GUI theme engine, and many of the reasons to get excited about it.
Just to clarify, a NIB and a gmodel are two slightly different means to the same end.
A NIB is an archive of the user interface object tree. NeXTSTEP and OPENSTEP just serialized the objects into the archive, but now Apple archives them as XML on MacOS X. NIBs represent the 'freeze-dried' internal state of the objects. A gmodel, on the other hand, is an archived representation of the user interface object tree obtained through the objects' API. At load time, it re-constructs the user interface by creating new objects and setting their attributes based on the values in the archive. This is an important distinction, because a gmodel doesn't (or shouldn't) contain internal object state. Thus, it is in theory possible to compile the gmodel library on MacOS X and use the same archive files on GNUstep and MacOS X.
However, that's only nice in theory, because GNUstep uses the NeXTSTEP look, and MacOS X uses Apple's slick, new Aqua look. The interface loaded from the gmodel just wouldn't look/work right on one or the other. I believe the current concensus in the GNUstep camp is to use a NIB-analogue for apps, because once Gorm is done, it'll be a pretty simple matter to whip up a GNUstep-specific user interface in minutes, and to use a gmodel as a transfer format if one wants to automatically convert an OPENSTEP or MacOS X NIB to GNUstep.
This doesn't seem true at all. If you develop an app using the GNUStep libraries it will work on any system with those libraries installed, whether you use WindowMaker or not. Maybe GNUStep is different but any application that uses X for graphics display should be able to run under any combination of Desktop Environment, Window Manager and Operating System. I don't see any reason that I couldn't run a GNUStep foo.app under KDE under Sun Solaris. Just pick a toolkit you like.
It's a common misconception that you must run a specific desktop environment to use any of its software, you only need to surrender the disk space to have all the various libraries installed. At home I generally use BlackBox on my Debian desktop with KDE2 apps as well as apps written in all the various X toolkits, at work I generally use KDE2 but sometimes run Ximian GNOME apps like Gnumeric, plus we've been using Glade and PyGTK for little in-house apps. We have users who use ICEwm, KDE1, KDE2 and AfterStep and it just isn't that big a deal.
-- Remember: Wherever you go, there you are!
Yeah. Unless it's vim. Or vile. Or elvis. Or nvi.
MSIE under Mac OS X is a *Carbon* app. This means that it runs the same binary as on the usual MacOS.
Not all Carbon apps can run under both the old (Mac OS 8/Mac OS 9) and the new (Mac OS X) architectures. There are two types of Carbon apps: CFM/PEF and dyld/Mach-O. Both run under OSX, OS8/OS9 can only run the former.
I believe the version of MacIE included with Mac OS X 1.0 is Mach-O. It is only designed to run under OSX.
- Scott
--
Scott Stevenson
WildTofu
Scott Stevenson
Tree House Ideas
People under 30 and those without ossified brains could give a shit about consistency of user interface. They sit down and point and click and look around and figure out the rest later. The rest whine about their VCR clocks, and they are dinosaurs already.
Boss of nothin. Big deal.
Son, go get daddy's hard plastic eyes.
Expanding a vast wasteland since 1996.
Jeez man why are you using linux? Go get a mac and install macosX. I guarantee you it will have a super slick and consistent UI. You will be very happy and hopefull you will shut up about it. Go make yourself happy instead of trying to make me unhappy. I don't want linux to succeed on the desktop on your terms I want it to succeed on it's own terms and that means not caving in to lusers.
War is necrophilia.
Like you said "in theory". In real life you could not run SQLs designed on oracle on sql-server or vice versa.
War is necrophilia.
Here's a laundry list of nifty software done (originally in some cases) in NeXTstep:
:(
:(
- Doom (incl. the original map editor)
- worldwideweb.app
- FreeHand v4 (nee Altsys Virtuoso)
- Lotus Improv (n-dimensional spreadsheet)
- various 3D things (Renderman was standard in the OS)
Things not so widely known:
- TouchType - by Glenn Reid of www.rightbrain.com, display type editing as direct as metal type. Adobe owns it now, but doesn't market it
- PasteUp.app - page layout program done by Glenn Reid in a year, better than Quark or PageMaker. Owned by www.afstrade.com, but they won't sell it either
- TeXView.app - By the same guy who did dvips. There was also Instant TeX which made use of it---best free TeX environment around.
- NoteBook.app - by Millenium Software. wonderful datamanagement.
- pStill.app - Available at www.this.net/~frank (versions for Linux and other OSen as well). Make PDFs without paying Danegeld to Adobe.
- TypeView.app - look at one's fonts at a level of detail not possible outside of a vector app.
Things which were part and parcel of NeXTstep with no real equivalent elsewhere as a whole:
- Display PostScript - unified imaging model 'nuff said
- Services - Think of it as pipes for the GUI, made possible:
-- Webster.app - ``In the future any computer which does not ship with a great dictionary will be considered barbaric.''
-- Digital Librarian/Shakespeare - indexed/searchable texts with nice icons (covers)and accessible from any app. Incl. man pages and most of the NeXT manuals.
-- Oxford's Book of Quotations
- Address Book
- Fax
Apple's Mac OS X gets some of this, but leaves a lot out and puts the scrollbars on the wrong side.
I've been working on some GNUstep information at my web page, http://members.aol.com/willadams/gnustep
--
Lettering Art in Modern Use
Sphinx of black quartz, judge my vow.
I just love /. Nobody understands the concept of the "middle way." 100% diversity is bad. 100% uniformity is bad. The ideal blend lies somewhere inbetween. The Windows OpenGL model is actually a very good illustration of RightWay(TM). In Windows, each vendor provides an implementation of a service, and each app writes to a particular OpenGL API (be it in C/C++, Delphi, VisualBasic, Java, or whatever.) The thing that ties them together is the common OpenGL ABI. Thus, one can switch from the ATI OpenGL implementation (OpenGL drivers implement the entire pipeline, from app-level functions on down) can be easily replaced with NVIDIA's one, and (barring extension incompatibilities) every Java, VB, Delphi and C++ app will continue working unaffected. This is exactly the model that should be used for GUI toolkits. There should be one ABI that all apps write to. Thus, the application developer can choose the API (I'm distinguishing the two: API is source level, ABI is binary level) they want, and the user can choose the implementation they like. Competition is perserved, app developers get a good amount of freedom, and the user is allowed to make their own decisions while retaining a consistant environment. Originally, X did something a bit like this. You could switch window managers around, and all apps would work fine. Its only because they made a miscalculation in the features necessary in the server to support this idea that it isn't true anymore.
A deep unwavering belief is a sure sign you're missing something...
The coolest thing about GNUStep is the fact that it deals with application installation the way it should be dealt with: File Bundles. Bundles represent an application as a folder with a .app extension which contains all the necessary resources for the application to work. No more rpm -i and having an app's resources scattered throughtout god knows where. Everythings in a nice, neat folder--Pixmaps, il8n resources, executables, etc. Bundles are truly a superior alternative to the broken packaging systems (dpkg, rpm) that we have today. It doesn't rely on some unrepairable binary database system that spells death for an installation if corrupted. Why package when you can bundle? Less papercuts.
In all situations, not that productive, at best. For an application developer it's key that the application developed will run on as most target systems as possibel, or at least on almost all systems used by the group targeted by the application. When you target Linux users, with the more windowmanagers there are, the more time you have to spend before you reach your target group. For a hobby project perhaps not that important, but for commercial applications or applications that have to gain money in some other way, it's hell.
--
Never underestimate the relief of true separation of Religion and State.
Just like the diversity in the PC hardware market has caused it's downfall, or the diversity in the server market is killing Sun or the diversity in the RDBMS market is killing Oracle or IBM. Why is competition on the desktop so different from competition in any other sector of the market?
The main driving force behind the InterfaceBuilder and the OpenStep API's is ObjectiveC's deferred method call linking. This language is what enables the juiciest part of the IB, the one people seldom talk about: the possibility to build object graphs by plugging objects into other objects' outlets, and to link any event of an object to any action method of any other object. You can even use the IB to make a graph of objects that contains no graphical widgets. The IB produces no code (as erroneuosly stated in the article), instead it produces an archive of interlinked objects; in fact, the IB introduced a new programming paradigm which was, alas, followed by noone. Maybe it's because writing the whole thing in C++ would be overkill, if at al possible.
Other masterpieces resulted from ObjectiveC's power are the Foundation (and its Distributed Objects) and EOF frameworks. You have to actually compare these to any other counterparts to see why noone comes close. Dynamic linking, categories, protocols, these things work miracles; it's a shame ObjectiveC is slowly fading into oblivion, now betrayed even by its once-time main supporters: the former NeXT software team, now working on Mac OS X. And yes, Java comes painfully close, but its C++ legacy perpetrates enough brain damage to cancel the benefits of the ObjectiveC influence.
Tuff that Smatters.
One of the greatest strengths we have in Open Source is the ability to choose, at every layer, what works best in each situation.
I've taught Linux for beginners during some time, and the hardest part was to make them unlearn the unified OS+Apps+Xserver+WindowMgr they had in the other OS. They even took the graphical interface to be the OS!
Being able to balance speed, memory use, etc seems to me the best part of using Linux.
And it makes the network admin much easier for multi-machine installation, too!
Linux *is* user friendly. It's not idiot-friendly or fool-friendly!
But does that mean I want to use GNUstep? Not really anymore. I view Java, Java2D, and Swing as the direct descendent of NeXTStep and OpenStep. Java as a language has many of the same dynamic features as Objective-C, but Java adds runtime safety and garbage collection, two really important features. Java2D has an imaging model very similar to DPS. And Swing is a mature, powerful toolkit that has borrowed a lot from its predecessors. In terms of size and performance, a Java installation is probably smaller than a full OpenStep (or GNUstep) installation, and Java performs well enough on modern hardware.
So, I understand the appeal of GNUstep. Some things are still easier in it than in Java/Swing. But, on balance, I think Java is a pretty decent successor, and problems are getting ironed out. If you find Java programming itself too cumbersome, you can always use some of the more dynamic languages built on top of Java, like Jython.
Here're some links (from uncertain organic memory, I'm at work) which provide something of a feel/information on NeXT/GNUstep:
:(
:(
:(
www.gnustep.org - main site
www.projectcenter.ch - ProjectBuilder clone
www.windowmaker.org
www.channelu.com - one of the last NeXT sources
www.blackholeinc.com - ditto
www.deepspacetech.com - they may be out of NeXT stuff
www.peak.org/~luomat - list of abandonware apps
www.peanuts.org - home of the official NeXT FAQ
www.this.net/~frank - ``Area 51'' for NeXT software
www.chronographer.com - an app which left NeXTstep
www.omnigroup.com - a surviving software developer
www.stone.com - ditto
www.apple.com/macosx - the official commercial version
William
--
Lettering Art in Modern Use
Sphinx of black quartz, judge my vow.
It's the building blocks for windowmaker, but
it's not a window manager itself.
Actually Wnidow Maker doesn't use any GNUStep libraries that I'm aware of. And Window Maker is moving futher away from the original GNUStep/NeXT interface. Not that that's a totally bad thing. Most of the enhancements have been pretty good.
GNUstep is not a window manager! It is a development environment and gui toolkit designed to be compatible with the OpenStep spec. If you actually read the article before approving it, you would realize this. Once again, confusing WindowMaker (which btw isn't even written using GNUstep) with GNUstep. It would have taken 45 seconds to read the article and figure this out...
(It ain't a window manager)
/ co coa.html
GnuStep is nothing more, nothing less than a fully object-oriented API under the GPL. It is a clone of OpenStep, NeXT's famous OO API that lives on as "Cocoa" in Apple OS X (to be officially released Saturday)
GnuStep (as OPENSTEP) uses Objective-C as a primary language. Objective-C is a fully Dynamic OO language that is a superset of ANSI C. It is modeled after Small Talk, but runs natively compiled- No bytecode.
Apple has added Java bindings to all the Cocoa/Gnustep APIs, so that developers can use Java as a language to call GunStep/OPENSTEP/Cocoa libs. GnuStep has also cloned this Java bridge, allowing the same functionailty in GnuStep.
GnuStep also includes a clone of NeXT's PostScript-based display layer, Display Postscript.
GnuStep also includes GnuStep Web, a GPL clone of NeXT/Apple's Web-Objects application server, which is used on a number of extremely high-profile web sites (including Dell's web store before Microsoft paid them to move to a M$ solution).
NeXT also had a set of development tools, the most interesting of which was Interface Builder, which builds dynamic GUIs (without any code generation). GnuStep has GPL clones of these in the works. They are part of the package, I believe.
These libs and tools were used by Tim Berners Lee to create the original web browser. They were also used to create the original version of Macromedia FreeHand. Anything that comes out for Apple's MacOS X that is labeled "Cocoa-based" uses these libs (http://www.omnigroup.com, http://www.caffeinesoft.com, and http://www.stone.com have some products you might be interested in)
The best source of developer documentation is Apple:
http://devworld.apple.com/techpubs/macosx/Cocoa
GNUStep is a re-implementation of what is probably the most productive set of software development tools I've ever seen.
NeXTSTEP was revelation to me. When I went from the Mac to NeXT machines in 1989, I knew the mac *cold.* Within a month, I was a productive on NeXT as I had ever been on the Mac. Within three months, I could do anything on NeXT in about 1/3 of the time that it would take me on a mac.
There's an amazing culture shock you get when you step up to this kind of tool set. The amount of code you don't have to write will make you wonder why you ever put up with X windows, the Mac ToolBox, or (god forbid) the win32 API.
The downside to using NeXTSTEP, was always the vendor. They were notoriously difficult to do business with, and every NeXT customer I know always said that they would *love* to be able to keep this technology, while dropping the vendor.
GNUStep lets us drop the vendor.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
Absolutely - and being a founder of Slashdot, it seems to me you're in a better than usual position to do something about it.
/.'s coverage of the Unix desktop has essentially dwindled to KDE vs. Gnome with occasional news about highly vaporous 3-D environments. WindowMaker is probably more popular than Evolution and a lot of the other stuff that gets hyped around here. E used to get covered in embarassingly obsessive detail about Rasterman's life but since parting company with Miguel and Gnome, it's become the David Lee Roth of Linux. Blackbox, icewm, UDE, some cool new thing I haven't heard of -- that would be "News for Nerds. Stuff that Matters" to me.
Unsettling MOTD at my ISP.
Maybe it's me, but this article seemed very confused to me. The guy is basically mixing up Window Maker (a window manager for X11) and OpenStep. The distinction between the original NeXT System, Open Step, GNU Step and Mac OS X is not very clear either. He talks a little bit about Interface Builder, but not a word on the different technologies that power the thing.
This is really a shame, because a good explanation about the NeXT technologies would be the most welcome on slashdot. It would be intersting to compare features of the GNUStep/NeXT/OS X Framework against GNU frameworks like Gnome or KDE. This would make it possible to compare them, but also to see if they could be integrated.
Of course this would imply a real discussion, not the usual arguments like Gnome is going to rule the world and everything else is obsolete etc...