Re: GNUStep, OpenStep, NextStep, Cocoa port?
Re: GNUStep, OpenStep, NextStep, Cocoa port?
- Subject: Re: GNUStep, OpenStep, NextStep, Cocoa port?
- From: Gregory John Casamento <email@hidden>
- Date: Sat, 8 Mar 2008 21:36:58 -0800 (PST)
Kirk,
"IMNTBHO, OpenStep/GnuStep are not useful means for achieving cross-
platform GUI applications, at least not if the platforms are OS-X and
Win32."
A number of companies mentioned on our wiki are using GNUstep in production environments. I don't currently know of any companies that are using Cocotron in such a way. Nib support is very complete on GNUstep, I'm not sure about Cocotron, but when I last tried it, some of the guis I created didn't look quite correct on Windows, if they loaded at all. With GNUstep you would be able to edit the nib or change it into the alternate gorm format to make changes specific to the target platform.
Cocotron provides a way to build your application on Mac OS X without having to have a windows machine since it provides the toolchain. Granted it would be useful for GNUstep to have a tool chain that works on a Mac so that you could compile your applications using Xcode, but you will need to test the results on the target platform anyway due to the shortcomings in nib loading stated above and as illustrated on Cocotron's own discussion list, which means you'll need the deployment platform to be available in any case. Is there any advantage to this approach then? Why not build on the target platform?
"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."
GNUstep is also "clean room" and "from scratch." Also, please keep in mind that about 70%-80% of all "open source" software is licensed under the GPL and the LGPL. GNUstep is "Free Software" but, at this point, I don't think this is the appropriate place for a license flamewar.
"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."
GNUstep doesn't have this issue our NSThread implementation works fine on all platforms we deploy to. GNUstep currently supports compiling on FreeBSD, NetBSD, OpenBSD, Linux, Solaris, Windows, etc etc etc. With Cocotron, you only get win32 as far as I'm aware.
GNUstep is more than just the Cocoa API, it also has a clone of EOF (GDL) as well as WebObjects (GSWeb). Cocotron doesn't provide these. Additionally, GNUstep has an implementation of CoreData and the DataBuilder application, see here: http://www.nongnu.org/gscoredata/
It is important to remember that the two projects have different aims. Cocotron's purpose appears to be to create a tool-chain that lets youtarget win32 on under Xcode, while GNUstep's purpose is to provide anAPI and development environment that allows developers to createapplications on a wide array of different platforms using the CocoaAPI. They are not competing projects.
Later,
Gregory Casamento -- Principal Consultant - OLC, Inc
# GNUstep Chief Maintainer
----- Original Message ----
From: Kirk Kerekes <email@hidden>
To: email@hidden
Cc: cocoadev cocoadev <email@hidden>
Sent: Saturday, March 8, 2008 10:16:25 PM
Subject: Re: GNUStep, OpenStep, NextStep, Cocoa port?
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 (email@hidden)
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:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden
- Prev by Date:
Re: GNUStep, OpenStep, NextStep, Cocoa port?
- Next by Date:
How do I tell if the mouse button is down, independent of view, etc.?
- Previous by thread:
Re: GNUStep, OpenStep, NextStep, Cocoa port?
- Next by thread:
Re: GNUStep, OpenStep, NextStep, Cocoa port?
- Index(es):