Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
GNUStep GUI GNU is Not Unix Businesses Apple

The NeXT-Best Thing: GNUSTEP 0.9.4 Live CD 444

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 ;)"
This discussion has been archived. No new comments can be posted.

The NeXT-Best Thing: GNUSTEP 0.9.4 Live CD

Comments Filter:
  • by JessLeah ( 625838 ) on Sunday February 06, 2005 @01:55PM (#11590988)
    i'Ve aLWaYs wOndEReD.
    • Because you can't trademark a generic word (like next) unless you fuck with the capitalization. Because then it's not just the word- it's YOUR(tm) word.
    • by BlueGecko ( 109058 ) <benjamin@pollack.gmail@com> on Sunday February 06, 2005 @03:10PM (#11591513) Homepage
      NeXT has that capitalization because the original NeXT logo [obsoleteco...museum.org] 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.
  • video (Score:3, Informative)

    by va3atc ( 715659 ) * on Sunday February 06, 2005 @01:59PM (#11591016) Homepage Journal
    is not divx, its mpeg(1 or 2, haven't finished downloading yet)
  • Hurd? (Score:3, Interesting)

    by Digital Pizza ( 855175 ) on Sunday February 06, 2005 @02:01PM (#11591025)
    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? (Score:5, Informative)

      by Pflipp ( 130638 ) on Sunday February 06, 2005 @02:02PM (#11591036)
      Like Hurd was the perceived GNU kernel, GNUstep was the perceived GNU GUI.
    • Re:Hurd? (Score:5, Informative)

      by TheRaven64 ( 641858 ) on Sunday February 06, 2005 @02:09PM (#11591075) Journal
      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...

      • Re:Hurd? (Score:3, Informative)

        by Master Bait ( 115103 )

        If only the GCC developers would commit Objective-C++ to the main tree and let is have a WebKit-based browser...

        Ironic state of things, considering that the very first web browser was written [w3.org] for OpenStep in Objective C.
        • Re:Hurd? (Score:3, Informative)

          by zsau ( 266209 )
          Not at all. Objective C++ and Objective C are two different languages. ObjC is a version of C with minimal additions to make it a great object-oriented programming language. ObjC++ is ObjC combined with C++ in the same source code.

          Standard GCC can compile ObjC just fine. But because most major gui free webbrowsers (Mozilla and Konq at least) are written in C++, the only ways to write an OpenStep webbrowser are with ObjC++ or by rewriting the entire engine.
      • 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.
        So they must not have been using X, since that's not GNU. In that case, what backend were they using?
        • It's not a GNU project, but Cairo is a GPL 2d image compositing library which can interface to glitz (also GPL I believe?) in order to render via OpenGL. There is a form of MesaGL which works without X... You could possibly build a non-X GNU desktop this way, though again there would still be non-GNU components. At least it would be 100% GPL.
    • when Duke Nukem Forever is released, it will only run on Hurd.
  • by Anonymous Coward on Sunday February 06, 2005 @02:01PM (#11591031)
    with a really small patch to libobjc,
    available in a gcc/libobjc bug report.
  • by 1010011010 ( 53039 ) on Sunday February 06, 2005 @02:02PM (#11591035) Homepage

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

    Right here [apple.com].
  • by jkheit ( 634306 ) on Sunday February 06, 2005 @02:09PM (#11591076)
    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 [macobserver.com] 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.
    • by Anonymous Coward
      It WAS championed as the default for GNU, like 10 years ago. Except it took forever go get usable, has like three serious developers and very few applications, and therefore is almost entirely useless to the end user. As for OS X compatibility, name one OS X program that has been ported to GNUStep. Thought not.

      If you want an evironment where The Voice Of God comes down and tells everyone stop their C/C++ crap and go write Objective C programs, use OS X. It's never going to happen with Linux.
      • GNUmail.app [collaboration-world.com] is one app that runs on both OS X and GNUstep. I've seen a small handful of others. However, there are some hurdles in porting an OS X app to GNUstep- if you use any Quartz compositing, it just won't work, for one. Or if you use any Carbon convenience functions, or any number of other non-OpenStep APIs that exist within OS X.

        But you are quite right in the last part. No way will your average Linux h4ck3r drop C/C++ and go to ObjC. A shame, as ObjC is a lot nicer, but it just won't happen.
      • by bnenning ( 58349 ) on Sunday February 06, 2005 @02:59PM (#11591415)
        As for OS X compatibility, name one OS X program that has been ported to GNUStep.

        There's many [freshmeat.net] more [freshmeat.net] than [freshmeat.net] one [freshmeat.net].
    • I have to disagree with you on the UI. It looks really ugly. Like, motif-level ugly. I'm sure it's all just themes, but open one of those apps and open a default kde app along side it and tell me the user is going to choose that one. If they want this to be a serious choice for end users, they're going to have to stick some sheen on it.
    • Agreed (Score:4, Insightful)

      by Lysol ( 11150 ) on Sunday February 06, 2005 @03:19PM (#11591583)
      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.
  • Makes me want to play with GNUstep. Only 2 lines of code for this simple app. The rest was built with the GUI, cool.
    • Re:Nice Demo (Score:5, Informative)

      by TheRaven64 ( 641858 ) on Sunday February 06, 2005 @02:17PM (#11591132) Journal
      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).
      • I'm not all too familiar with this. Is the code portable? For all the GUI creation, does it just include a bunch of libraries and code for you? It seems cool, but what are its limitations?
        • Re:Nice Demo (Score:4, Informative)

          by TheRaven64 ( 641858 ) on Sunday February 06, 2005 @02:53PM (#11591366) Journal
          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.
        • What it does isn't so much write out a bunch of code and include a bunch of libraries, but rather what it does is make a live graph objects and then serialize them on save. Starting a nextstep,openstep, cocoa, or gnustep application reconstitutes the serialized object stream from the nib file.

      • If developing for GNUSTEP is anything like developing for Cocoa, that would be great. But why, oh, why must everything OSS have a supposedly cute, but actually ugly, name like GORM? Or Postgre? It's not clever and it sounds like vomit.
        • GORM (Graphical Object Relationship Modeller) is arguably a better name than Interface Builder, since it is a tool for graphically modelling relationships between objects, which happens to be used primarily for building interfaces.
        • Developing for GNUSTEP is quite a bit like developing for Cocoa, and getting more so all the time.

          OS X was the best thing to happen to GNUSTEP, as it gave them a target to work towards.

  • ISO download sites (Score:5, Informative)

    by tarzeau ( 322206 ) <gurkan@aiei.ch> on Sunday February 06, 2005 @02:11PM (#11591095) Homepage
    Thanks Department of Physics, ETHZ [phys.ethz.ch], GNUSTEP-i386-0.9.4.iso [gnustep.ethz.ch]
    Thanks inode.at [inode.at] and Robe GNUSTEP-i386-0.9.4.iso [inode.at]
    Thanks Lyle E. Dodge [mailto], GNUSTEP-i386-0.9.4.iso [incosy.net]
    Thanks Philipp [www.bind.ch], GNUSTEP-i386-0.9.4.iso [gnustep.bind.ch]
    Thanks Daniel Aubry [mailto], GNUSTEP-i386-0.9.4.iso [chaostreff.ch]
    Thanks Peter Samuelson [mailto], GNUSTEP-i386-0.9.4.iso [p12n.org]
  • Made with ibuild (Score:3, Informative)

    by eburner ( 833625 ) on Sunday February 06, 2005 @02:21PM (#11591159) Homepage
    I just wanted to note that this was created based on morphix using a tool called ibuild [livecd.net] that eases creation of Linux LiveCDs.
  • Developlment IDE (Score:3, Informative)

    by jd142 ( 129673 ) on Sunday February 06, 2005 @02:22PM (#11591163) Homepage
    Wow, I really appreciate the Borland/Delphi/Kylix/C++ Builder/JBuilder IDE now. Even the VB ide was easier to build a gui app in.
  • by linguae ( 763922 ) on Sunday February 06, 2005 @02:24PM (#11591180)

    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....

    • If you like languages other than Objective-C, you can go the Cocoa way: You can mix it with other languages such as C, C++ and what not.

      If you're not too much into programming: The same interface as visible in the Flash demo, can be used to code with AppleScript!

      Bert
      • by HeghmoH ( 13204 ) on Sunday February 06, 2005 @05:18PM (#11592303) Homepage Journal
        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.
    • I seem very impressed by the development environment

      I seem to agree. :-)

  • Too much! (Score:3, Insightful)

    by fm6 ( 162816 ) on Sunday February 06, 2005 @02:30PM (#11591213) Homepage Journal
    This is proof that the LiveCD fad is out of hand. GNUStep's distinguishing feature is an API. How is distributing a LiveCD going to persuade developers to code to that API?

    I'm waiting for the MP/M [z80.de] LiveCD!

    • getting users to use gnustep will get more developers to write for it. getting more developers to write for it will get more users to use it. boosting either boosts the other.
      • Users don't "use" GNUStep. They use software that happens to be written to the GNUStep API. Suppose (it's unlikely, but suppose) that some GNUStep program on this CD generates a lot of buzz. It doesn't tell programmers to create more GNUStep programs. It tells them to create more programs like the one that generated the buzz. They don't have to use GNUStep to do that.

        In order for GNUStep to get more developers, it has to convince them that the API will make their jobs easier. The API has been around for 2

  • by samhalliday ( 653858 ) on Sunday February 06, 2005 @02:30PM (#11591215) Homepage Journal

    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.

    • by pschmied ( 5648 ) on Sunday February 06, 2005 @02:55PM (#11591376) Homepage
      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. [roard.com]

      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
      • by TheRaven64 ( 641858 ) on Sunday February 06, 2005 @03:20PM (#11591593) Journal
        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.

    • by Coryoth ( 254751 ) on Sunday February 06, 2005 @02:59PM (#11591420) Homepage Journal
      To be honest, yes. You can see the issue most clearly by comparing this [collaboration-world.com] and this [collaboration-world.com]. 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.
      • It's the color scheme. Seriously. Remove all those reds and yellows and lighten up the grey a bit and all the "clutter" will be gone. Personally, I far prefer the simple, polished look to the gel toothpaste goo look of Aqua, but that's just opinion.
        • The color scheme is a large part of it. It's also the fonts, the the size of the widgets - all the buttons and list dividers etc. all look kind of chunky and stand out, adding to the "clutter" look. By contrast in the MacOS X screenshot the obvious UI elements are the messages themselves. It doesn't need to be all gel looking like MacOS X, but even a theme more akin to GTK Industrial or KDE Plastik along with better fonts would go a long way to making the application look much nicer and more inviting.

          Je
      • by linguae ( 763922 ) on Sunday February 06, 2005 @03:31PM (#11591666)

        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 [levenez.com] 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.

      • I have to admit that the OSX version is pretty. But I'd rather use the GNUstep version because it is easier to see. Might be that my eyesight isn't as good as it was 20 years ago...but the GNUstep version is *easy* to see, whereas the OSX version is easy to look at.
    • I don't get this "it's ugly" attitude. Practically everyone I know who uses Linux uses Windowmaker as their WM, so I would imagine that most people *like* the NeXT look and feel. Heck, if I could get a decent theme engine working on OS X, I'd dump Aqua in a second to get back to the clean NeXT look.
  • One STeP Beyond (Score:4, Interesting)

    by Doc Ruby ( 173196 ) on Sunday February 06, 2005 @02:32PM (#11591227) Homepage Journal
    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 ;)?
    • FWIW, I still want to type raw source code into the files under the GUI. Really, I want the GUI to produce raw source code files, so I can still use all my lexical parsing techniques, tools and existing files. And exchange them with my GUI-challenged associates :).
    • Re:One STeP Beyond (Score:3, Informative)

      by BlueGecko ( 109058 )

      Is there any way to draw flowchart-style graphical indicators between object interface GUI representations?

      That's what you do on OS X, but NeXT (and now Apple) have a patent on that implementation. GNUstep tries to circumvent it by using the small "s" and "t" circles (for "source" and "target") that you see in the video.

      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?

      I'm not quite sure what you mean he

      • I find it incredible that Apple could have a patent on generating code from a user drawing a line between two mapped interfaces - doesn't Visio (among many other flowcharters) do it like that? But not necessarily surprising.

        Drag/dropping code primitives would look just like the demonstrated GUI drag/dropping GUI widgets into a container window. I'd create a new "controller" object, by dragging a the baseclass from a palette and dropping it - creating a controller window as its representation in the IDE GUI
  • Looks neat, but... (Score:4, Insightful)

    by david.given ( 6740 ) <dg@cowlark.com> on Sunday February 06, 2005 @02:48PM (#11591324) Homepage Journal
    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.

    • "...don't look like a reject from the 80s." Not to burst your bubble on that, but it looks like one of the best systems of the early 90s, not the worst of the 80s.
    • by roard ( 661272 ) on Sunday February 06, 2005 @05:40PM (#11592440) Homepage
      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.

Technology is dominated by those who manage what they do not understand.

Working...