Don't use deprecated wxDataViewCtrl::StartEditor() in the sample.

[wxWidgets.git] / docs / cocoa / install.txt

diff --git a/docs/cocoa/install.txt b/docs/cocoa/install.txt
index 84de896ebfafbe4a302cc91a91d224353a98a143..2235eb0b93b34726e42b31762f143cf4041ea6df 100644 (file)
--- a/docs/cocoa/install.txt
+++ b/docs/cocoa/install.txt
@@ -1,49 +1,42 @@
+----------------------------------------------------------------------------
+NB: This is the old wxCocoa port, you almost certainly want to read
+    docs/osx/install.txt for instructions about building wxOSX/Cocoa instead.
+----------------------------------------------------------------------------
+
 wxCocoa is still a work in progress.
 
 To compile it, you will need Apple's Developer Tools.  However, please
 note that any work to make it suitable for GNUstep (which will require
 a GCC release with Objective-C++) will be much appreciated.
 
-For the time being, the standard configure/make method works.  You will
-want to build static because there are a number of unimplemented functions
-that a shared library will need (becuase of wxWindows code internally using
-them) but that a static library will not (because most of the samples
-don't need it).
+Some users also report success with Metrowerks CodeWarrior IDE and I've even
+on occasion used the command-line MW compilers (see docs/metrowerks) with
+configure instead of GCC and Apple's LD.
+
+Like most UNIX ports, the standard configure/make method works.  You should
+be able to build the library as static or shared.  I usually build static.
 
 On my system I have the following:
 
 Checked out CVS source is in:
-/Users/dfe/devel/wxHEADcommit/wxWindows
+/Users/dfe/devel/wxHEADcommit/wxWidgets
 Debug build directory is:
 /Users/dfe/devel/wxHEADcommit/BUILD_COCOAd
 
 From the debug build directory:
-$ ../wxWindows/configure --with-cocoa --enable-debug --disable-shared
+$ ../wxWidgets/configure --with-cocoa --enable-debug --disable-shared
 $ make
 $ cd samples/minimal
 $ make
-$ ./minimal
-
-You may also need to configure the library --without-expat.  It didn't
-build last time I checked, but then again, several improvements have
-been made since then.
-
-For other samples, you will need to provide at the very least an empty
-resource fork so the OS will recognize it as a GUI application.
-
-From the debug build directory:
-$ cd samples/drawing
-$ make
-$ true | /Developer/Tools/Rez -t APPL -o drawing
-$ ./drawing
-
-Note that the empty resource fork doesn't actually allow the app to be
-started from the Finder (it thinks it's a classic app!) but does allow
-it to run with a menubar and proper event handling from the command line.
-
-I suspect (but am uncertain) that if we provided an empty plist resource
-that the app would be recognized as a proper OS X application.  Obviously,
-bundles would be preferrable, and any work on Bakefile (see
-http://bakefile.sf.net/) would be much appreciated.  wxMac also needs
-bundle building restored since the switch to Bakefile.
-
+$ ./minimal.app/Contents/MacOS/minimal
+
+Like wxMac applications, wxCocoa applications are "bundled".  For development
+purposes all this means is that an executable named "foo" needs to be
+inside a "foo.app/Contents/MacOS" directory.  For deployment you will need
+an appropriate Info.plist and PkgInfo inside the foo.app/Contents directory.
+
+wxCocoa (and Cocoa in general) has no need for Mac OS resources.  It
+certainly has no need for resource forks as no Mach-O applications should
+_ever_ have resource forks (note: Bakefile violates this right now).
+Please see the wxWiki and/or discuss this with wx-users before shipping
+any wxCocoa apps if you are new to the OS X platform.