GNUstep is a cross-platform, object oriented environment composed of frameworks, tools, and servers (daemons). In the new version, An NSXMLParser class was added. Runtime discovery of the library version is now possible. NSArrays makeObjectsPerformSelector now iterates in same order as Mac OS X. The designated initializers for NSArray, NSDictionary, NSSet, and NSString were changed for Mac OS X compatibility.
GNUstep 1.10.1 Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
for you application, will you be able to just compile your code in Cocoa for a pure OS X look on a mac and then compile it is GNUStep for Linux?
If you use GNUstep on OSX for your development, yes. If not – meaning if you use the Apple toolchain – not.
Apple’s Openstep Classes are enhanced now and contain stuff the original specs did not. Plus, InterfaceBuilder files are in a proprietary format.
Or you can use Renaissance.
http://www.gnustep.it/Renaissance/
Which allow you to create your interface with portable XML files
that is usable on both GNUstep and Cocoa. Or if your project is small,
you may consider creating your interfaces without interface builder.
However, I (imo) think synchronizing your interface between IB and
Gorm doesn’t take too much effort (and porting code between 2
systems also results as some unexpected cleaner code 🙂
Sabastian,
You show your raw ignorance here. In about 95% of all cases, the code will literally compile without change on both platforms. There are some differences, but we have actively worked to minimize those. Writing a GNUstep makefile is simple, and so your claim that the barring issue is actually interfacebuilder’s project format is nothing short of peropsterous. The biggest “hurdle” is the fact that Apple’s NIB format is not documented. As such, it has to be reverse-engineered, which is an ongoing but difficult process. There are ill-conceived alternatives such as Renaissance, but they are not long-term solutions IMHO. In any event, I have quite a decent amount of GNUstep–>OS X and OS X–>GNUstep porting experience, which is more than I can say for you, Sebastian. Next time you go flapping your jaw here, please, do the world a favor and at least know what you’re talking about. Otherwise, please don’t spout bullshit. Your assertion that it is not possible is false, and I doubt you’ve even bothered to try.
“Apple’s Openstep Classes are enhanced now and contain stuff the original specs did not.”
Yes, but the GNUstep team has implemented most of those.
“Plus, InterfaceBuilder files are in a proprietary format.”
That’s why you keep one set of NIBs and one set of .gorm files with the same codebase. Really, Sebastian, I don’t think you have looked into the situation much.
these news are a bit late/inaccurate (but just a bit)… it’s GNUstep BASE 1.10.1, which was released last week, and today it’s the windows installer that was released.
It seems like the Nib format would be pretty easy to reverse engineer, since you can save them in an xml format. I even think there is a script out there that will translate Nib files into Gorm files for you.
But it’s true, most Gnustep apps that also run on OS X just keep a separate pbxproj directory and Nibs for building in Xcode along with Gnumakefiles and Gorm files for building in Gnustep. Look at GNUMail’s source for an example of a program that runs equally well in Gnustep and natively on OS X.
Just because something is stored in XML format doesn’t mean it’s automagically easy to decode. The actual data in the value portion of the key/value pair is still encoded, and since you clearly don’t have a full understanding of that unfortunate fact, you’re oversimplifying the complexity of the problem. We already have good people working on your “idea”, and it’s difficult but not impossible to decode the data that’s stored in the XML files.
Is there a little thing going on between you and Sebastian?
I’m just curious…
“whoop ta do basil!” .. Mike Meyers (Austin Powers)
You’re obviously right. I hadn’t looked closely enough at the format to realize it was encoded. I also didn’t see your earlier post explaining the situation, and wouldn’t have replied if I had. But hey, thanks for the nice attitude!
@RJW
Well, you can trust me that actually is his unique way of expressing nice
gangsters-like attitude
it’s not always about technology
I’m sorry, if I upset you, but I simply answered the question modman asked.
And it’s true, that using Apples toolchain (Xcode, InterfaceBuilder) you can’t simply recompile what you wrote in GNUstep. Nothing more, nothing less.
As for the classes: There are still classes that are unimplemented in GNUstep and always will be – given some proprietary nature. I simply suggested writing for GNUstep first and then “porting” to OSX, since you wouldn’t use any classes that aren’t available.
> Yes, but the GNUstep team has implemented most of those.
That’s part of why I suggested starting development from GNUstep and not from Cocoa. That way you don’t get in trouble with “most”.
> That’s why you keep one set of NIBs and one set of .gorm files with the same codebase.
See, that’s why I answered the original poster the way I did. You can’t compile something written using Apple’s toolchain on GNUstep out-of-the box. That’s what my answers and probably the original poster’s question was all about.
> Really, Sebastian, I don’t think you have looked into the situation much.
As far as the question in the first posting in this thread goes, I guess I have.
I looked over some example tutorials and things and ObjC+GNUStep looked seriously overly complex.
To be fair (with my bias:), I found Objective-C is far less complicate than
either C++ or GObject system (and even Java). It may looks
complex because Obj-C syntax is (IMHO) horridly ugly at
first sight (That’s what was happening to me) but once I
was a bit more familair with it, the learning curve was progressing
really quickly. And that’s why I only use Obj-C for most of my
serious projects these days.
yeah i admit the syntax really threw me, its very.. un C ish if you compare class defintions with c++ / c# / java…
it feels like a script language tacked ontop of C to create messaging etc…
Objective-C is not really “a script language tacked on top of C”, but Smalltalk, a pure object oriented language and one of the first OOP languages, along with other innovations such as the first modern GUI, “tacked on top of C”. Maybe you see it’s similarity (though not in syntax) to Ruby which is a scripting language that’s Smalltalk-influenced.
That always struck me as a bit of an odd decision. Smalltalk is a great language to base the semantics on, but it’s a bit weird to import the syntax wholesale into a language with it’s own distinctive syntax.
i think the bracketed syntax will throw off most at first, espcially people that are used to the C++/Java “dot” syntax. but once you start working in objc, the benefits of the syntax tend to shine, imo.
Yes, it does look like two languages, Smalltalk and C, combined. I was simply mentioning that the language that it is combined with, Smalltalk, was not (originally) a scripting language. Though StepTalk, part of the GNUstep project, is essentially Smalltalk as a scripting “glue” language from what I understand. The typical Smalltalk implementation however is Smalltalk as a world to itself, which isn’t at all a scripting language model – in fact really the opposite.