Slashdot Mirror

Porting a native Mac application to Linux doesn't get any easier just because they're both unix-based.

Calling all competent Windows developers:

Contribute to the porting effort of bringing GNUstep to Windows. If we can get GNUstep looking like an authentic Windows application (needs a lot of work, but they already have a theming engine, and work on horizontal menus), then there might be the possibility of building code for X11, Windows, and Cocoa, all from the same source. In other words, something resembling what YellowBox would have been.

GNUstep already makes a good cross X11/Cocoa framework. It takes a little bit of effort, but it's possible to get a GNUstep app to compile on the Mac without modification. (The other direction I'm not so sure of.)

I think somebody's forgetting GNUstep

• Linux
  
• OS X (almost nativeli, with native OS X Cocoa frameworks, no need for GNUstep in some/most of the cases)
  
• BSD
  
• MS Windows
  

• Linux
  
• OS X (almost nativeli, with native OS X Cocoa frameworks, no need for GNUstep in some/most of the cases)
  
• BSD
  
• MS Windows
  

Moreover, if you take care about stuff you use in Cocoa, you can deploy on multiple platforms by using GNUstep - cross-platform set of frameworks that have Cocoa compatible core. Works on Linux, BSD and MS Windows too... So you are not tied to OS X only.

never use absolute values when posting to Slashdot. "Never", "No One", "Nobody", "Always" will just get you into trouble. Why, becaue as of 5 minutes ago... I have downloaded gnustep and I am using it for my own devious purposes.

Now, I understand what you meant, but a lil search shows that at least some people are using it:

apps

The most popular application to use it would probably be Window Maker.

Honestly, I don't care too much about the kernel. I would however love to see open standards for NextStep/Cocoa, and then maybe more people would use it. It is really nice, but Jobs can't have his cake and eat it too.

You're a decade late

There's a free-as-in-speech implementation right here

If you're looking to contribute to the likes of AppKit, take a peek at GNUstep. If you haven't heard of it, it's an opensource implementation of the OPENSTEP specification, of which Cocoa is a proprietary implementation. It's not as shiny as Apple software (yet!), but it allows one, with some care, to write code that will run natively in Mac OS X and any platform with GNUstep. And they can certainly use talented coders!

GNUstep is a possibility. Licensing issues have been raised, however. Many people have reported difficulties getting it to compile as a usable DLL under Windows, which of course makes it virtually unusable for commercial developments.

Well, I believe you are incorrect, at least about the part where GNUstep aims compatibility only with the old OpenStep standard. According to this FAQ entry:

GNUstep aims to be compatible with both the OpenStep specification and with Mac OS X. It should be easy to write an application that compiles cleanly under both GNUstep and Cocoa.

Yeah, I suppose it's true that Cocoa's a moving target, but I don't think they can make it move as much as you seem to fear: doing so would make it an impossible platform to develop for. I believe the goal would be to make it possible to easily use autoconf or something like it to smooth out the differences between platforms, making porting apps (and writing cleanly portable ones too) a lot easier.

Ever heard of GNUstep?

Well, for Cocoa anyway, there's GNUstep, as, if I'm not mistaken, it's an implementation of the OpenStep specification that was created for NeXT and is still used today for MacOS X as Cocoa. Once GNUstep is reasonably completed, it would in theory be possible to have a certain amount of source-compatibility between any platform with GNUstep and Cocoa. Carbon, now that's a different story...

Have you seen GNUStep? check out their poster screenshot: http://www.gnustep.org/images/full-screenshot1.png

Sadly, like the Amiga OS, this will never be get any serious market penetration.

I agree with Ruby and other agile productive languages like Boo, Iron Python and Groovy. Being able to do more with less code that is terse and seperates the signal from the noise will improve productivity, readability and maintainability.

GNUstep may not be anywhere nearly as mature as Qt or Gtk, but it's hardly a non-starter.

A phone is an example of an embedded system. These days a phone is one of the more capable embedded systems.

Ah, now GTK, yes, a cross platform GUI toolkit is very handy. I've said in other threads that I think Cocoa would make a killer cross platform GUI toolkit. Cocoa is based on NextStep (thus why all the classes have an NS prefix). There is an open source implementation of this called GNUStep (http://www.gnustep.org/) which looks very promising. They're even planning to implement parts of Cocoa itself.

Now, the part of OS X that you wanted open sourced wasn't Cocoa, it was Aqua. Aqua would be roughly equivalent to full blown X plus a heavy window manager (such as Gnome or KDE). You don't start with one of those and pare it down to fit in an embedded system.

I agree though, a GUI toolkit like Cocoa would be great. Hopefully Apple will help out the GNUStep people like they have various other open source projects relevant to them.

Anyway, the original post, to which you replied rudely, by the way, simply stated a belief that Apple's GUI (not just their widget toolkit) was too high-overhead for an embedded device. The OP didn't suggest that you don't need or want the source, he pointed out that your statement that the source to OS X is not available is not entirely correct, that in fact the parts of the source you would want for an embedded project ARE available. Note that Darwin also runs GTK, QT, etc., which are perfectly good toolkits that are appropriate for embedded environments.

There are other api's that are truly cross-platform (Windows, Linux, Mac, Embedded) and don't just "run on top of X http://www.gnustep.org/information/aboutGNUstep.ht ml (and no offense, they look prettier too)

-everphilski-

let me clarify: sure I can code objective-c on my windows/linux/whatever box. But I wont have a decent API (cocoa). So why, please?

It's called GNUstep and yes, it works just fine.

The lists are the best place to start for this. Either discuss-gnustep@gnu.org or gnustep-dev@gnu.org. You can join either. Just go to the following URL to subscribe: http://www.gnustep.org/information/gethelp.html#de vel.

You should simply say you would like to work on something. For base, you should talk to people on this list for contributions to the things which they are responsible for. Myself for gui and Richard Frith-MacDonald for base.

Later. GJC

That wasn't a smart thing to say if you want anyone with even a passing knowledge of the subject to take anything you have to say seriously.

There's no need to debate about this, you can simply read the GNUStep Testimonial and Mission Statement.

GNUStep isn't going for full compatibility, but the technology, APIs, and libraries are very similar, and large parts of it are identical at the API level.

That wasn't a smart thing to say if you want anyone with even a passing knowledge of the subject to take anything you have to say seriously.

There's no need to debate about this, you can simply read the GNUStep Testimonial and Mission Statement.

GNUStep isn't going for full compatibility, but the technology, APIs, and libraries are very similar, and large parts of it are identical at the API level.

try porting an osx objc application to win32/linux? no chance in hell.

Not necessarily.

Hey, there's no email thread on that page...

Looks like it's been slashdotted!

(Btw, "Objective-C gives you the full power of a true object-oriented language with exactly one syntax addition to C and a dozen additional keywords. Its power lies in its elegance and simplicity." -- GNUstep: Introduction)

And don't forget WindowMaker + GNUstep combo. If only there were some more apps (e.g. web browser) written using the GNUstep framework it would actually be a very interesting environment to work with. While both Gnome and KDE are nowadays quite good systems I think their developers should learn a few things from GNUstep (or actually OpenStep) GUI (e.g. document based apps, insanely powerful menu system, clean dialogs (Gnome actually already does these almost correctly), windows (and tear-off menus) stay where you put them, etc etc etc).

> If Aqua was only available for linux... :-(

It is ! But it's called GNUstep

You forgot Poland! ...er...GNUStep.
Sure it may not have all the apps, but, for developers, it's the closest thing to writing for a mac with out acutally writing for a mac.

http://www.gnustep.org

Also you forgot, CDE, XFCE, and Enlightenment.

Gorm is the IDE environment for NextStep. sorry..... I meant GNUStep ;-)

http://www.gnustep.org/experience/Gorm.html

Its still ugly as sin, but its the closest thing OS X has "native" that could also be considered multi-platform.

Cross-platform code that doesn't suck = GNUstep. wxWidgets is not nice - I've written software for both GNUstep/Cocoa and wx.

What, you mean like this?

If you think about it, GNUStep running on Darwin is already damn close to replicating OS X with Free Software. Sure, there's a few things missing (notably, Core*), but if OS X started getting really widespread adoption like this, those holes would be patched up quick.

>How can I write portable versions of Mac OS X apps when the Cocoa API doesn't exist outside of Mac OS X
of course it does!
check out gnustep (http://www.gnustep.org/) for a portable version of the cocoa API (works quite well on linux and even on windows ;-)

>and the language Objective C isn't supported outside of Mac OS X
of course, it is supported. gcc ships with objective-c support since AGES and runs on nearly all platforms. gcc 4.1 will even feature obj-c++

Objective-C *does* exist outside of the Mac (gobjc anyone?) and a large portion of the Cocoa API exists in a form known as GNUstep - maybe you've heard of it?

Sure, the .nib's created in Interface Builder do not work in GNUstep, but many other things do.

But, if you're focused on cross platform support, why are you using Cocoa or Carbon anyhow?!

How can I write portable versions of Mac OS X apps when the Cocoa API doesn't exist outside of Mac OS X (don't tell me about YellowBox or what-have-you) and the language Objective C isn't supported outside of Mac OS X (Apple is killing off Cocoa's Java support)? Oh, and the Carbon API doesn't exist outside of Mac OS X either (but at least it uses a widely supported language). You mentioned a software company in the Northwest US, but what about the one in Cupertino? Apps written to their platform are no more portable than Windows apps.

The Cocoa API is semi-complete as part of GNUstep. GCC has built-in support for Objective-C.

As far a Carbon is concerned, for some time now I have been interested in statring a project to re-implement that API in a more open manner so that you could use the Carbon API under GNU/Linux or some other operating system. I just haven't had the time to give it much effort.

Besides that, apps that aren't able to take advantave of the underlying platform's unique features aren't sellable.

On this point I agree 100%. Most "portable" applications are lowest common denominator and support only the small subset of functionallity that is avaliable on all of the platforms and this makes for what is often an unpleasant experience.

Try GNUstep, which is an opensource re-implementation of NeXT/Sun's OPENSTEP standard:

http://www.gnustep.org/

It'll allow you to deploy on Linux, Windows, and possibly even the Sharp Zaurus depending on your project.

They even have a web page up clarifying a mention of it in Aaron Hillegass' _Cocoa Programming on Mac OS X, Second Edition_

http://www.gnustep.org/resources/BookClarification s.html

It's licensed under the LGPL, so should be usable for most tasks.

William

Try GNUstep, which is an opensource re-implementation of NeXT/Sun's OPENSTEP standard:

http://www.gnustep.org/

It'll allow you to deploy on Linux, Windows, and possibly even the Sharp Zaurus depending on your project.

They even have a web page up clarifying a mention of it in Aaron Hillegass' _Cocoa Programming on Mac OS X, Second Edition_

http://www.gnustep.org/resources/BookClarification s.html

It's licensed under the LGPL, so should be usable for most tasks.

William

Essentially:
'Cocoa' and Java.

If you want OS X application bundles, you can have them today if you want.

Stick your app in an appropriate Applications directory and type "openapp Whatever.app".

And if you merely want appbundle-*like* systems, I think there's plenty of them floating around.

``Still, I think that tools like Borland Delphi/Kylix, & yes, even RealBasic 2005 (does Win32, Linux, AND MacOS X code from a single codebase) each are "superior" tools of "RAD" design vs. C/C++ porting between platforms.''

Oh, absolutely. C is an OK language for writing operating systems in, but it's horrible for writing applications. C++ is better, but it has many problems (mostly due to Design by Committee). And with RealBasic (can't vouch for Delphi) you also get a safer language (see Better Languages for Better Software).

Of course, i'd rather you use something truely open for your RAD development - perhaps GORM, or Glade (maybe wxGlade would be a better choice for cross-platform work), or ...

``Drive Letters used in Win32 vs. Device mounting in UNIX based OS like Linux &/or MacOS X BSD heritage.

Well, that & using registry entries in Win32 vs. .ini files (or whatever filetype you use, text even etc.) & such for state storage for apps between runs so they have "memory" between runs.''

Of course, there's always stuff that's going to bite you in the ass when you use it. If you use the Windows registry, it won't work on Unix. If you use Unix sockets, it won't work on Windows. So you need to abstract away from those differences and write code that does what you really want. You want to store settings? Well, write code that stores settings and works on all platforms you support. You want IPC? Write code that does IPC and works on all supported platforms.

Eventually, you'll also have to keep in mind that to write truly great software, you have to also make it fit in with the environment it should run on. Users of all platforms tolerate some inconsistency, but a Kylix app would probably look horribly out of place on a nicely themed modern Linux desktop. The traditional wisdom still holds: separate your user interface from your engine, and then write a dedicated engine for each platform you support.

There's GNUstep (an article on which was posted shortly before this one). I don't know how integrated it is with the shell, though. Normally to run an application in your GNUStep-equivalent-for-a-path, you run "openapp ". I've never found GNUstep to be particularly usable.

There's also the ROX Desktop. By default, it doesn't interfere with your shell (how could it, if it's distributed as a series of AppDirs?), but someone's written a patch to Bash so that appdirs in your $PATH are accessed by (the executable in an AppDir is named "AppRun", so obviously the method can't be quite equivalent). I've never used it (I prefer zsh) and it mightn't cleanly apply any more though... (If you run "rox ", then the appdir opens; the command "rox" behaves similarly to open on MacOS X or openapp on GNUStep except that rox doesn't maintain its own path. ROX is, after all, a series of AppDirs.) I run a ROX desktop.

Well some of the applications you were asking for already exist in gnustep versions:
mplayer - MplayerGS (simple gnustep gui with playlist support that starts cmdline mplayer)
emacs - there is an aqua/gnustep version of emacs which is imo one of best emacs versions out there

for another incomplete list of apps check:
http://www.gnustep.org/GSWeb/GSApps.woa

check out the livecd for some examples:
http://www.linuks.mine.nu/gnustep/

happy gnustepping ;)

Heh, they already did

No, Afterstep is only a window manager, that is only working on X11. See here, what the OpenStep specification is about. While you do so, you might also read up the Savoy 1992, Booz-Allen Study results

I'll never get Slashdotters' obsession with KDE and GNOME. Both projects absolutely suck. Their APIs are a joke. GNUStep/OpenStep, on the other hand, is a true object-oriented environment, and it really does make Gnome and KDE obsolete.

I'll never get someone's obsession to shove hideously ugly GUIs down users' throats. This looks like something I used when my Unix terminal was still using a black-and-white screen. This looks like something I used when my Unix desktop was totally useless.

Gnome and KDE can at least be made to look and feel nice. That is all I need to know. I don't care about any "elegant" solutions under the hood.

The OpenStep Standard. And the object oriented C. And how Interface Builder looked on OPENSTEP. And the live CD with the older version (soon to be updated).

The OpenStep Standard. And the object oriented C. And how Interface Builder looked on OPENSTEP. And the live CD with the older version (soon to be updated).

this is going to take on modern GNOME/KDE? I'll try to contain my fear... But with that I must say I will welcome our 1995 overlords with cookies and milk that has past its expiration

Yeah - I don't know which is worse: 1) making such claims just for publicity (flamebait?) 2) or truly believing in it. In either case, the first screenshot you bump into will discredit their claim immediately. Compare it with anything trolltech has to offer with qt4 (or kde4's plasma efforts, koffice kids, etc.) and their development tools... I don't mention GNOME development tools because I'm not familiar with them, but I don't think they will be "obsoleted" either.

(...and now someone will link to GNUstep.)

http://www.gnustep.org/

http://www.gnustep.org/

Write code which should pretty much just port to OS X without too much trouble.

I've always wondered why KDE and Gnome get so much attention.

I think you've just described GORM. It allows you to draw graphical components, and graphically connect Objective-C objects together. It is also possible to add SmallTalk scripts directly in GORM to tie the components together. Oh, and for the database access side, you can use GDL2 which provides an Object-relational mapping - a system for mapping Objective-C objects to rows in a relational database in a database- and schema-independent way. If you want something a little easier to use than GDL2, there is a CoreData implementation for GNUstep in course of construction which will include a graphical object-relational modeller. Oh, and the result will build happily on *NIX and Windows, and with a little tweaking on OS X.

I think you've just described GORM. It allows you to draw graphical components, and graphically connect Objective-C objects together. It is also possible to add SmallTalk scripts directly in GORM to tie the components together. Oh, and for the database access side, you can use GDL2 which provides an Object-relational mapping - a system for mapping Objective-C objects to rows in a relational database in a database- and schema-independent way. If you want something a little easier to use than GDL2, there is a CoreData implementation for GNUstep in course of construction which will include a graphical object-relational modeller. Oh, and the result will build happily on *NIX and Windows, and with a little tweaking on OS X.