See also top-level FAQ page.
List of questions in this category
Please see the downloads page.
The version of wxMac in CVS advances quickly so it is recommended that you download the
the sources from the CVS trunk.
There is also a wxMac 2.3.1 development snapshot.
The author of this port is Stefan Csomor.
wxWidgets 2 can be used to develop and deliver applications on Classic Mac OS (e.g. Mac OS 8.x/9.x) both as Carbon and non-Carbon applications.
A Mac OS X port is in progress in order to be able to build wxWidgets applications using the Apple Developer Tools that are delivered with every copy of Mac OS X.
The Mac OS X port is based on and, for the most part, merged with the Carbon code for Classic Mac OS.
wxMac for Mac OS X shares code both with wxMac for Mac OS and common Unix code in wxWidgets. The aim is to use the same Mac OS Carbon code both for Classic Mac OS and for Mac OS X while leveraging the fact that Mac OS X is a BSD Unix.
This hybrid approach was suggested by Apple to the Fizzilla team working on Mozilla for Mac OS X.
Since the source code is shared between the two ports, any Carbon compliant improvements to wxMac for Classic Mac OS are automatically available in the Mac OS X port.
The following points should be considered when improving wxMac:
- Non Carbon compliant changes for Classic Mac OS will most likely break the Mac OS X port. Such changes should be tested using the Carbon targets in the CodeWarrior projects for Classic Mac OS.
- Non Carbon compliant changes for Mac OS X will most likely break the Classic Mac OS port. Such changes should be tested using CodeWarrior under Mac OS 8.x/9.x.
Under Classic Mac OS, MetroWerks CodeWarrior Pro 5.3 or 6 are required to build wxMac.
Under Mac OS X, the Developer Tools are sufficient to build wxMac. CodeWarrior Pro 6 can also be used to build the Carbon targets.
Before checking out the wxWidgets code using a CVS client under Mac OS 8.x/9.x, be sure your computer is set up to treat xpm and xbm images correctly:
- bring up the Internet control panel, select the Advanced Options tab, click on the File Mapping icon from the list at the left and see if there are is an entry for ".xpm" files and another for ".xbm".
- if an entry exists, click Change... and make sure File Type is
TEXT (just those four capital letters); correct it if necessary. If there is no entry, make one with type set to TEXT and creator set to anything you like; reasonable choices include GKON (Graphic Converter) or CWIE (CodeWarrior).
- if you want to edit
xpm or xbm files in CodeWarrior, set up a file mapping in the CodeWarrior project settings for analogous to ".h" files.
The Mac OS X CVS client does not handle file types and creators at all (just like every Unix command line CVS client). This is an issue only when the checked out files will also be used under Mac OS 8.x/9.x.
All files checked out under Mac OS X will be untyped and CodeWarrior will not recognize them correctly. To correct this, use the autotyper provided in the CVS sources:
- decode and decompress the file
wxWidgets/docs/mac/TypeAsMetrowerksText.sea.hqx
- drag the wxWidgets CVS sandbox directory onto the autotyper and most of the files will be typed according to the file extension
The latest build for Carbon support lead to a few changes that you will have to follow in order to successfully compile the code.
This is also necessary even if you don'want to build the Carbon targets.
- you need CodeWarrior Pro 5.3, i.e. 5.0 with all the upgrades
- you have to download the Universal Interfaces 3.3.2 or later from the Apple Developer web site, Universal Interfaces 3.4 is required for Carbon Printing support
- put the Universal folder into the MacOS Support folder and replace older versions
- remove from the MacOS Support folder the separate OpenTransport folder
- open the file MacOS Support:MacHeaders:MacHeaders.c and add the line
#include <ControlDefinitions.h>
after the line
#include <Controls.h>
- rebuild all MacHeaders from the MacHeaders.mcp project in the same folder
Build the projects (makemac6.mcp for CodeWarrior Pro 6; makemac.mpc for CodeWarrior Pro 5) in the following five directories:
- wxWidgets:src:
- wxWidgets:src:jpeg:
- wxWidgets:src:png:
- wxWidgets:src:tiff:
- wxWidgets:src:zlib:
You need to have the Apple Developer Tools installed. The Developer Tools CD is one of the 3 CDs that are delivered with Mac OS X but must be installed in addition to the default Mac OS X installation.
Building wxMac completely without configure is not supported.
Building wxWidgets directly in the CVS sandbox is not recommended. Instead, wxWidgets should be built in a directory configured relatively to the CVS sandbox.
For instance, to build wxMac with configure, start in the base wxWidgets directory and type:
mkdir macbuild
cd macbuild
../configure or ../configure --enable-debug
make
For some reasons the CodeWarrior project settings may get changed and this may lead to the inability to compile a certain target. In order to verify the settings click on the target tab, double click on the respective target and then select the following items on the tree-view on the left. Here are the important checks:
- under
Target/Access Paths, make sure the first user include does not have a folder icon for recursive search.
- under
Language Settings/C/C++ Language, make sure that the only checked items are:
Enable C++ Exceptions
Enable RTTI
Enable bool Support
Enable wchar_t Support
Relaxed Pointer Type Rules
Use Unsigned Chars
- under
Language Settings/C/C++ Warnings, make sure that the only checked items are:
Illegal Pragmas
Extended Error Checking
Inconsistent Use of 'class' and 'struct' Keywords
Hidden Virtual Functions but be aware that the framework itself has some of these beauty spots
- under
Linker/PPC Linker, make sure that the following items are checked:
Dead-strip Static Initialization Code in order to avoid including libraries that are not needed, especially as things like OpenGL get added to the projects and sources
Smart preprocessing is activated with the -cpp-precomp option and allows much faster preprocessing of the source files by loading precompiled Carbon header files. This option speeds up the compilation of wxMac by a factor of 2 at least.
When compiling wxMac using the Apple Developer Tools, the following error is displayed for certain files:
cpp-precomp: warning: errors during smart preprocessing, retrying in basic mode
This error is due to the smart precompiler which does not fully understand C++ syntax and reverts to basic preprocessing when a smart preprocessing error occurs.
This error can sometimes be corrected or avoided by modifying the source code. However, leaving these errors is not a problem since the preprocessor automatically switches to basic preprocessing if necessary.
Because wxWidgets does not have a specific API for the About menu item or the Help menu, the Mac OS port uses some static variables to help the engine make the right decisions:
- It assumes that the About menu item is part of a Help menu.
- The title of the Help menu is stored in
wxApp::s_macHelpMenuTitleName, it defaults to "&Help", but you can change it in your constructor to your specific menu title.
- The item Id of the About menu is stored in
wxApp::s_macAboutMenuItemID, it defaults to wxID_ABOUT, but can be changed as well to suit your needs.
- The other items of the wxWidgets help menu are appended to the Mac OS Help menu and the translation of Ids is handled transparently for your application.
If you have Mac OS X, you have the icns editor somewhere in the
Utilities folder. Create an icon using this tool and DeRez it, so that you have a .r
file with a 'icns' resource with id (-16455). Include this .r file in
your project and in the CodeWarrior Settings add a check mark under Linker:Output
Flags/Finder Flags/Has Custom Icon.
Sometimes you want to test your application against different versions
of wxWidgets, for example a stable version of wxWidgets versus a development version.
The easiest way to do this is to create a symbolic path.
Under Edit-Preferences in General:Source Trees, type a name (for example WXWIN)
and choose a path for it. Now reselect your include and lib paths for a last
time, in the settings for each configuration, but make them relative to the symbolic name.
From now on you can just change the path associated with the symbolic name.