Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
GNUStep GUI

GNUstep On LinuxFocus 72

Posted by Hemos from the looking-at-it dept.
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.
This discussion has been archived. No new comments can be posted.

GNUstep On LinuxFocus More

GNUstep On LinuxFocus

Comments Filter:

  • Re:Diversity is the key (Score:1)

    by Anonymous Coward
    You have a point about there being only one word processor, one Web browser and one sound editor in Windows. Of course there are lots, but they all have the same look and feel to them. I can seamlessly switch between (for example) Cool Edit and Sound Forge, and know that I'm going to see similar options like Save and Properties, etc., under the same menu. It's not like I'm going to use (bad example, granted) CC or GCC and see similar optimization options under some menu item. No, I have to load up the man pages and hunt around of the option because it's (for example) -O2 in CC and --optimize-no-framepointer in GCC, because paragraph C, sentence 2 and word II in some obscure license agreement are incompatible with some philosophy of one of the OSS gurus (like Stallman et al.).

    FUD? You say it's FUD, but you don't say that it's not counterproductive to have three different versions of essentially the same software, from the same ancient UNIX source, even!, all with three completely different set of parameters to do something simple. I contend it is.

  • Re:Geek girls?! (Score:1)

    by Anonymous Coward
    I can only speak for myself, but we the "nice and pretty geek girls" tend to have a slightly broader view on life in general. What you geek guys often don't realize is that the computers and technical stuff with which you fill your lives make only a small fraction of a fulfilling life. Passion, art and relationships are by far more significant elements in a Good Life.

    So, I suggest you get yourself a new, non-technical hobby and loosen up your attitude towards non-technical people and who knows, you might very well end up dating even ordinary girls.

    --Cheryl

  • GNUstep is NOT A WindowManager -- It is an implementation of the OpenStep API. Basically an Objective-C framework containing a Foundation Kit (the GNUstep base library) and an Application Kit (GNUstep-GUI).

    GNUstep is aiming to create a NeXTSTEP 3.3-like enviroment.

  • Re:Diversity is the key (Score:1)

    by Anonymous Coward
    One of the greatest strengths we have in Open Source is the ability to choose, at every layer, what works best in each situation.

    And one of its greatest downfalls is the fact that there are five or six different versions, all slightly incompatible, of the same piece of software, simply because the authors disagree on two sentences in a license agreement.

    I love Linux and its stability--don't get me wrong--but the fact that there are so many versions of the same thing drives me nuts. Different command-line options, but essentially the same functionality. I don't have time in my life to learn the vagaries of Mumble vs. GNUmumble versus FreeMumble. And it's for that reason that I cannot use Linux as a development or desktop platform; I'd rather use Windows, even though it's less stable. (Can't get anywhere near the 3D support in Linux that I can in Windows, too.) All I have to do is my work and learn one set of commands and programs, and I'm far more productive than staring at a set of man pages that look almost exactly like another set of man pages, but with a whole different, incompatible set of command-line options (and often TWO sets, at that).

    Like I keep hearing, free software is only free if your time is worth nothing.
  • I agree completly. MacOS using something like bundles on it's dual fork file system (Data fork, Resource fork). I don't know why anybody hasn't came up with something like this yet for unix. It wouldn't be to hard I'd think, but then again, I've never really thought about it.

    I'm not saying I want a dual fork file system, but bundles would be nice. I believe apple has improved on bundles alot in OsX, perhaps the linux community could stand to learn a thing or two about how OsX works and adopt some features in Gnome/KDE.
  • You PAID for your UID? I got paid to take mine.... ;-P

    BTW, you never know what prompts a reply, and what is relevent. I see no harm in asking if there was a link in the artical or relevent info that prompted the person to ask this question.

  • Correlation factor between spelling and IQ is generally thought to be around 0.6, you tell me, how lucky do you feel?
  • How is this relevent to the topic?

    But to answer your question, it's quite simple. People obsessed with thier looks are usually shallow. So, to try to compensate for being shallow, they do the one thing they understand best. Obsessed with looks and visual stimulus, you naturally will be drawn to art. And, by claiming an intrest in art, no one will tell them they are "wrong" (because art is subjective), and they loose some stigma of being shallow because they have a "deep and passionate" interest.

  • So many versions?

    In the "unix" world as oppossed to the "linux" world there are really only two standards. System V and BSD in the way of commands.

    You learn the switches you need that are different between ps on the two systems, and the rest is duck soup! ;-)

    Vi is Vi (or if you must - emacs ;-) so that takes care of the editor argument, and there are some significant issues in programming libs between all the different distros/systems but autoconf/automake seem to help that become manageable too.

    I work as a contractor - and working on multiple platforms is a business necessity - it just aint that hard!
  • so the author needn't worry.

    MSIE under Mac OS X is a *Carbon* app. This means that it runs the same binary as on the usual MacOS.
    --
    Slashdot didn't accept your submission? hackerheaven.org [hackerheaven.org] will!

  • Oh, right... I'm now in MacOS 9.1 (and I don't feel like rebooting to check), but I'll take your word for it.

    I'm still using the public beta as well. Still very satisfied with it. Shipping date is coming soon btw. Three days to X-day! I can't wait :)
    --
    Slashdot didn't accept your submission? hackerheaven.org [hackerheaven.org] will!

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

    Did someone tell marketing?* Apple is running "J2SE Development on Mac OS X" banner ads right now on Slashdot.

    * This is Apple, so my guess is that the answer is No.
    --
  • The popular computing press doesn't ever seem to get this issue either. They are always confusing desktops and window managers and calling Gnome the Linux Desktop appearently not understanding that it will run on BSD, Solaris, etc.
    Apple and Microsoft have spent the last fifteen years trying to convince people that an OS is a giant monolithic entity and shouldn't be altered by the consumer. I mean if MS wants people to belive that a browser or a music/video app is actually a part of the OS what chance do you have telling people that the GUI is not the OS. If you think about it, any *nix is even more layered than you said, more like OS+Libs+Apps+Xserver+Toolkit+WindowMgr+Desktop with all of those components developed independently.
  • Why is too many GUI toolkits a bad thing, but half a dozen RDBMS providers is consumer choice?

    The different RDBMS's are, in theory, different implementations which all support the SQL standard. In practice there are different levels of compliance and different proprietary extensions such as built-in functions and stored procedure languages, but having SQL bind them together is a great strength.

    -Bruce
  • I like the idea of theming in *nix GUIs thesedays. I'm using a NeXT theme on my Window Maker WM today by coincidence. I really can't see the need to go any further 'though.

    Clearly Hemos didn't get the article. He probably didn't even read it.

    Clearly the author of the article doesn't really understand the differences and similarities between NeXT, OSX or even a Window Manager.

    I was very excited when I saw the link and story on ./ I went and read it and came away wondering why anyone even went to the trouble of porting the application development stuff to Linux and BSD just so you could use a package that kind of resembles something that was revolutionary in the 80s. There are lots of GUI IDEs around for *nix thesedays. What makes this important?

    Having read the article, I really don't understand what GnuStep is for and why anyone should care.

    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?
    ----------------------------
  • Wow. Thanks for taking the time to explain that. That was much clearer than the article Hemos posted.

    I think I can see why this is worth thinking about now.
    ----------------------------
  • 'n he didn't even mention the really cool UI stuff... - SERVICES - pipes for GUI apps - sophisticated inter-app window layering See my other posts for an explanation of why the former is good. The latter allows one to readily make use of multiple programs without constant switching.
    --
    Lettering Art in Modern Use
  • In theory, it'd be possible to _recompile_ a GNUstep app for Mac OS X, _but_ there's the matter of the UI. NeXTstep used nibs, and Mac OS X is still using them, I believe (but will be shifting/has shifted to an xml representation), while GNUstep uses gmodels (and GORM isn't finished yet :(

    IF the gmodel were converted to Mac OS X, yes, should work. I suppose one could even come up with a fat binary format across the OSs 'cause both use bundles, but don't count on it.
    --
    Lettering Art in Modern Use
  • Wow, I guess we'll be seeing a flurry of stories about it now :-)

  • Of course the geeks are happily married. They find the one person who will actually sleep with them, and thats the end of it.

  • Does this mean that GNUStep apps will be recognized as Cocoa apps on Mac OS X or did I get relationship between the two wrong?

    Interesting.
  • <i>E... has become the David Lee Roth of Linux.</i><br><br>Hahahaha that's the funniest shit I've heard all day. And so true too. It's too bad Rasterman and Mandrake got all high-brow and became anti-GNOME anti-GNU (for their developments anyway). I think they could have contributed alot. E is certainly a contribution, but I think it's usership is probably on level with GNUStep at this point.
  • There are things other than computers and technical stuff in life? Where? How? Why didn't anyone tell me?

    DanH
    Cav Pilot's Reference Page [cavalrypilot.com]
  • It's the building blocks for windowmaker, but it's not a window manager itself.

    It is good to see that the 'other environments' are getting press, though. Especially with the community. I'm a bit tired of hearing about KDE and Gnome as I use AfterStep. Yes, I use KDE and Gnome applications, but I prefer the AfterStep window manager.

    DanH
    Cav Pilot's Reference Page [cavalrypilot.com]
  • But Window Maker is the 'official window manager' of GNUStep. I do not know if it uses the libraries, but GNUStep is keeping that a primary window manager for it's environment.

    DanH
    Cav Pilot's Reference Page [cavalrypilot.com]
  • I'm over 30, my brain isn't ossified, and I'm running Slackware and WindowMaker. Not because I need to, but because I want to. I'm interested in the technology, the tool. Actually using it is secondary. That makes me different from most of the rest of the world, who just want to get some work done and could care less -- for good reason -- about how the bloody thing works.

    Computers are supposed to be easy, not hard. And, except for a few oddballs like us sods reading ./. most everyone finds computers as exciting as a trash compactor.

    If you want Linux to escape the server ghetto and succeed on the desktop, stop arrogantly insulting the people who comprise that market and start paying attention to what they want.

  • > Apple's Stan Shebs has taken over the GNU Objective C compiler in GCC from Ovidiu Predescu

    Strange move, a couple of years ago Apple refused to offer Ovidiu a job, although he had strong credentials (he's behind lots of stuff at GNUStep, including ObjC runtime, UI, gstep-db and libFoundation) and they initially appeared interested. They also have a long story of biting the hands that feed them - I mean developers. When dealing with NeXT, and later Apple, it always felt like bringing new apps and markets to their platform was the very last thing on their agenda.

  • I definitly would like to add http://www.stepwise.com [stepwise.com] to the list. The people maintaining this site have left us with a very interesting chronicle of ex-NeXTers moving over to MacOS X, and the reaction of the media to it. Stepwise kept the spirit up, in an ever shrinking NeXTSTEP community.

    Some of the older articles contain the obviously outdated or dead links but are in fact revealing the hope from the developers - and size of the challenges facing Apple (both design and corporate) in slipping Mach, BSD and OPENSTEP under MacOS's dusty carpet.

    But most of all these people gave us very nice tutorials and HOWTO's that will give interested people a reality-view on the technology and the developer community.

    And GNUStep is everything but unknown to them.

    I guess everybody out there is getting their apps and schnapps ready for the Mac OS X release next Saturday.

  • The site is down. linuxfocus.org is down for me completely.

    I thought GNUStep was the api layer that allowed for a Next-ish type interface. I know that while WindowMaker was not written using GNUStep, it is compatible.

    You /. editors and anyone else interested could go to the source to learn about GNUStep here. [gnustep.org]

  • Some Cocoa API doesn't have Java bindings. e.g. NSTask which is used to call console commands cannot be called from Java side.
  • in your sig: "80 column hard wrapped e-mail is not a sign of intelligent" does not come close to 80 characters.

    --
  • I didn't get that sense from what I read. He said that WindowMaker is a part of GNUstep, a phrase others are interpretting as meaning it was written with GNUstep. Actually, it doesn't mean that, it's just the official window manager of the GNUstep project.

    This means that while the author didn't use the GNUstep API, which arguably would be overkill for a window manager and wouldn't integrate very well, the window manager is designed to look like NeXTStep, understand that GNUStep apps are running under it, manage those GNUStep apps, etc.

    OpenStep is both the name of later versions of the NextStep operating system and the API NeXT/Apple developed for the *Step environment, hence another reason for apparent confusion from anyone coming to the subject for the first time.

    Essentially, this can be seen in that from 4.0 onwards, NextStep CDs were labelled "OpenStep for Mach". Mach was the underlying kernel, and an implementation of the OpenStep API sat on top of it, with a few BSD, GNU and Unix tools sitting there unacknowledged by the label. You could also get "OpenStep for NT" and even, from Sun, OpenStep for Solaris. But users generally refered to the OpenStep/Mach/BSD/GNU/Unix package as just "OpenStep".

    Mac OS X is, as the article says, the latest version of the whole OpenStep/NextStep family. It's mostly a ground up rewrite, with Mach 4 replacing the older version used, a version of BSD Lites based, in turn, on FreeBSD, replacing the kernel servers that were in the NextStep Mach, the BSD/GNU userland from FreeBSD replacing NextStep's command line userland, and with a rebuilt version of the OpenStep API sitting on top of it (together with a bunch of other funky things, such as Java subsystems and other APIs to help at different levels with MacOS 9 migration.)

    I felt the article was accurate, just somewhat more interested in advocacy than substance. There was an attempt to show how to install it, but frankly you need rather more than what's described in my opinion. It'll be good when someone puts together a "Linux distro" which bundles the lot together in a NextStep like way.
    --
    Keep attacking good things as "communist"

  • but Java adds runtime safety and garbage collection, two really important features.

    While Obj-C doesn't have garbage collection, the Foudation kit does. It's actually very smart and I can't see why other APIs haven't implemented it as well. It's true that there isn't full runtime safety, but once you've learned to retain your objects you very seldom have pointers pointing wrong, and Obj-C does offer some safety with exceptions and the fact that calling a nil object isn't an error (this last thing can be very useful actually, since you don't have to check for nil all the time).

    While not really related, Obj-C does have some really nifty features that I haven't seen in any other programming languages (and I've tried quite a few, though not SmallTalk). One example is when an object doesn't respond to a method call. Then a special function is called with a structure describing the call and the object can do whatever it wishes. For example an array can forward it to all it's elements or a proxy can forward it to some remote object. All completely transparent.

  • This requires a special command to run your commands....why??

    Well, it might be this way right now, but it wouldn't have to be. Since the bundles all have a specific layout you could make a shell that sees the bundle as an executable. Just put the bundle in the path, type the name of it, and the shell knows where to find the executable.

    Of cource, there's no such shell at the moment, but that doesn't make bundles in itself a bad idea. And if you really want to, you can always use symlinks.

  • While Obj-C doesn't have garbage collection, the Foudation kit does.

    The Foundation Kit really only has a some utility classes for helping you keep track of pointers. That's nice, but it's not quite the same.

    but once you've learned to retain your objects you very seldom have pointers pointing wrong,

    Well, the value of safety isn't so much for one's own code, it's to make it easier and safer to use other people's code. Reuse becomes easier because you have to worry less about the memory management policies that another library may use. It becomes safer because a "bad apple" won't usually make your whole program crash.

    One example is when an object doesn't respond to a method call. Then a special function is called with a structure describing the call and the object can do whatever it wishes.

    Like many other features in Objective-C and NeXTStep (libraries, browsers, UI), that actually comes directly from Smalltalk (doesNotUnderstand:). More recent languages like Python also have it.

    It's a real shame that Objective-C wasn't used more when it came out; adding garbage collection and a bit more runtime safety to it is not all that hard, and with a larger user community, that would probably have happened by now.

  • Objective-C's mechanism was considered for Java but dropped in favor of nested classes, which fulfill the same function and have other advantages.

    Proxying in Objective-C is convenient but not safe, while proxying in Java is less convenient but safe. Which is better? Hard to tell. I would err on the side of safety.

    Incidentally, both Objective-C features can be implemented efficiently on top of Java's current runtime; the issue of "C++-style method binding" is a red herring.

  • 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,

    Java gives you the same functionality. In fact, you can build a set of GUI objects and serialize them if you want to.

    And yes, Java comes painfully close, but its C++ legacy perpetrates enough brain damage to cancel the benefits of the ObjectiveC influence.

    Lots of people claim that, but repeating it over and over again doesn't make it true. Yes, the languages are different, but in terms of expressiveness, they don't seem much different. In fact, even Smalltalk has been implemented on top of the JVM. So, can you be more specific? What is it that you think you can't do in Java that you can do in Objective-C?

  • > Why is competition on the desktop so different from competition in any other sector of the market?

    Because the desktop is about user interface, and user interface needs to be consistent to be successful.

    I'm pretty confident if you sat at my machine and tried to use my window manager, it would take you a while to figure out how to move a window or iconify one.

  • > but I think the diversity of the desktop interface is one of the more fun aspects of open source

    It's also what will cause its downfall.

  • It most certainly does not use GNUstep libraries.

  • I love Linux and its stability--don't get me wrong--but the fact that there are so many versions of the same thing drives me nuts.


    Yeah, and there's only one word processor, only one web browser, only one sound editor in Windows.

    All I have to do is my work and learn one set of commands and programs, and I'm far more productive than staring at a set of man pages that look almost exactly like another set of man pages, but with a whole different, incompatible set of command-line options (and often TWO sets, at that).


    FUD

    Like I keep hearing, free software is only free if your time is worth nothing.


    Folks, is this in the Microsoft Employee Handbook yet?
  • 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.
  • So, can you be more specific? What is it that you think you can't do in Java that you can do in Objective-C?
    Short answer: nothing, any language sufficiently advanced can emulate any feature in another. Same could be said for COBOL or, heck, INTERCAL.

    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.
  • Because the other IDEs, frameworks, and object-oriented languages suck.

    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?

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

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

    The 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-make

    This 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-web

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

  • Developing an application that needs a GUI is a pain when you have to support more than 1 GUI-toolkit so it will work on all windowmanagers.

    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.

  • Vi is Vi...

    Yeah. Unless it's vim [freshmeat.net]. Or vile [freshmeat.net]. Or elvis [freshmeat.net]. Or nvi [freshmeat.net].

  • 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 [wildtofu.com]
  • I work every day around people who have used Windows or Mac for years, and couldn't minimize a window without keystrokes if their life depended on it. I only recently learned to manipulate windows completely wiht the keyboard on my own window manager (WindowMaker, BTW). And that highlights the only part of consistency needed; pointing and clicking and using a mouse.

    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.

  • 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.
  • Like you said "in theory". In real life you could not run SQLs designed on oracle on sql-server or vice versa.
  • 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
  • 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.
  • 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.
  • 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. Hemos, where's the 'fun' part? Ok, perhaps at the 'user's side, but definitely not on the developer side. Developing an application that needs a GUI is a pain when you have to support more than 1 GUI-toolkit so it will work on all windowmanagers. So I clearly don't understand why a diversity of GUI's is a cool thing. The more windowmanagers/gui toolkits there are created, the more the application developers have to use OR a windowing library that lays on TOP of all these toolkits and is most of the time slower, OR create more than 1 version for all toolkits OR just pick one and develop for that toolkit/windowmanager and leave the rest.

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

  • 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?
  • > He talks a little bit about Interface Builder, but not a word on the different technologies that power the thing.

    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.

  • If you love the look and feel of the NEXTSTEP user interface widgets, you may want to check out the NiceSTEP project on SourceForge. This project is a set of lightweight Java components that can be used with or without Swing to create applications with that look and feel. It is NOT a part of GNUstep, but it has some of the same virtues; with a modern IDE you can create a significant portion of a useable application without writing code. Plus you can share these apps with Windows users. See http://nicestep.sourceforge.net.

  • (This is slightly offtopic)

    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!

  • NeXTStep managed to package Smalltalk-like convenience with the efficiency of C and a UNIX-like operating system. That was great a decade or two ago. In hindsight, I think the industry made a big mistake not going that way (but Stepstone's and NeXT's lousy corporate strategy didn't help). Even today, I think the GNUstep programming model is much more convenient than Gtk+ or Qt.

    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 [jython.org].

  • List of useful links (Score:3)

    by WillAdams ( 45638 ) on Wednesday March 21, 2001 @07:24AM (#350470) Homepage
    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

  • Re:Please Hemos, where's the fun part? (Score:3)

    by cyber-vandal ( 148830 ) on Wednesday March 21, 2001 @09:08AM (#350471) Homepage
    There should only be one GUI toolkit, just like there should be one PC vendor, one graphics card, one DVD-ROM, one RDBMS, one server architecture, otherwise things are just too hard and confuse the customer. Why is too many GUI toolkits a bad thing, but half a dozen RDBMS providers is consumer choice? A suggestion to all commercial companies developing for Linux - supply the required libraries and install them with the application, much like games will give you the option to install the latest DirectX.
    Diversity is a good thing, don't let a monopoly tell you otherwise.

  • Re:Since when is GNUStep a windowmanager? (Score:4)

    by Psiren ( 6145 ) on Wednesday March 21, 2001 @05:35AM (#350472)
    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.

  • Oh come on (Score:4)

    by rm -rf /etc/* ( 20237 ) on Wednesday March 21, 2001 @05:00AM (#350473) Homepage

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

  • Definition of GnuStep (Score:4)

    by aaroncsmith ( 260292 ) on Wednesday March 21, 2001 @06:15AM (#350474)
    (It ain't a window manager)

    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/ co coa.html

  • Comment removed (Score:5)

    by account_deleted ( 4530225 ) on Wednesday March 21, 2001 @05:56AM (#350475)
    Comment removed based on user account deletion

  • Let's hear some more! (Score:5)

    by update() ( 217397 ) on Wednesday March 21, 2001 @07:38AM (#350476) Homepage
    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.

    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.

  • Confused Article (Score:5)

    by Matthias Wiesmann ( 221411 ) on Wednesday March 21, 2001 @05:26AM (#350477) Homepage Journal

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

Slashdot Top Deals

I've noticed several design suggestions in your code.

Close