IMNTBHO, OpenStep/GnuStep are not useful means for achieving cross-
platform GUI applications, at least not if the platforms are OS-X and
Win32.
Anyone who would disagree should point two out.
OTOH, Cocotron, <http://groups.google.com/group/cocotron-dev> while
spottily incomplete, is Doing It Right. Cocotron is a "clean room"
genuinely open-source (no GPL/LGPL/etc -- _true_ open source)
recreation of the Cocoa API, (roughly circa Panther/Tiger, so far)
from scratch.
Cocotron is developed on Macs, in Cocoa, using XCode. (As such, I
would argue that it is on-topic for this forum.)
It has Foundation variants that work fairly seamlessly across Win32,
Linux and 'nixes.
And a Win32 Appkit that can do the fairly amazing trick of delivering
a standard Win32 native GUI app using UNMODIFIED Mac Cocoa code.
Really. Ugly menus-in-the-windows and all. Built on a Mac using XCode,
as an alternate target to a Mac target.
Obviously, Cocotron is no threat to Apple because:
1. It produces standard ugly W32 apps -- it isn't "OS-X on a PC" in
any way, shape or form.
2. It requires a Mac to do development.
3. It lets Cocoa developers leverage their skills into the W32
marketplace, particularly for in-house specialized app
development. Then the inevitable moment comes when it becomes
obvious that the Mac version is faster,
better looking and more reliable...
I have written several OS-X/Win32 apps using Cocotron, and it is
amazing what one can accomplish. I am tending to push Cocotron's
envelope -- using socket-based cross-platform IPC, using "multimedia",
writing custom compilers for proprietary hardware, etc. As such I tend
to have to fix things, but they do get fixed, and Cocotron is better
for it.
Cocotron is missing far less than the public docs state -- they
haven't been updated in a year or more.
The only way to really know what is working is to download the
development environment <http://www.cocotron.org/Tools/InstallCDT>
-- and the code base (Paste the following into Terminal)
svn checkout
http://cocotron.googlecode.com/svn/trunk/cocotron-read-only
Downside? So far, Cocotron doesn't have a complete Win32 NSThread
implementation, although that is, AFAIK, in work. Where threading is
required to provide Foundation/Appkit functionality it has been done
by direct invocation of the W32 threading mechanism.
It doesn't yet have Objc 2.0, and it doesn't have some of the more
recent OS-X enhancements. Win32 Application icons are not automatic.
The Win32 apps currently come packaged like OS-X app packages -- a
directory with the executable in a "windows" directory several layers
down. This actually works OK in Windows land, if you follow the
Windows convention of sprinkling links to the executable all over the #
$%^& place. I have seen native Windows apps packaged similarly,
including some very expensive ones (Catia, the aerospace CAD package
that the Boeing 787 and Airbus A380 were created with is one example).
And, of course there are some very real issues with the different
filesystem layout assumptions made by OS-X and W32.
And finally, each Cocotron Win32 app has to load DLLs containing
bulging bushel-baskets of Cocoa->Win32 code, and then load the W32
DLLs for the OS services the Cocoa DLLs are using. Weirdly enough, the
Cocotron apps still first-load faster than a lot of native W32 apps do.
But for all of the deficits (which are constantly diminishing), it can
nonetheless take a straightforward overtly single-threaded Cocoa app,
NIBs and all, and create a working Win32 version using XCode -- in a
matter of moments.
Let me restate that for emphasis: You can write a Mac app, debug it on
the Mac, test it on the Mac, and then choose a different target in
XCode and create a native-Win32 GUI version without changing a line of
code, and without sprinkling #ifdef __WIN32__ everywhere.
Really.
Of course, Cocotron is a work in progress.
If you have either Win32 knowledge or Cocoa knowledge, (or both) there
is plenty of room to make contributions to the code base. Cocotron is
pleasantly informal -- you can participate formally, or you can post
code to the developer discussion on Google, and someone more formal
will roll it into the codebase. No bickering, no endless debates over
turf or design patterns. The guiding principle is simple -- "does it
work like Cocoa?".
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
