and ports.
@li @ref page_port_wxgtk
-@li @ref page_port_wxmac
-@li @ref page_port_wxcocoa
+@li @ref page_port_wxosx
@li @ref page_port_wxos2
@li @ref page_port_wxmgl
@li @ref page_port_wxx11
http://www.gtk.org
The newer version of GTK+ you use, the more native widgets and
-features will be utilized. We have gone to a great extent to
-allow compiling wxWidgets applications with a latest version of
+features will be utilized. We have gone to great lengths to
+allow compiling wxWidgets applications with the latest version of
GTK+, with the resulting binary working on systems even with a
-much lower version of GTK+. You will have to ensure that the
+much earlier version of GTK+. You will have to ensure that the
application is launched with lazy symbol binding for that.
In order to configure wxWidgets to compile wxGTK you will
in the distribution.
-
-
-@section page_port_wxmac wxMac
+@section page_port_wxosx wxOSX
@htmlonly
<img src="logo_osxleopard.png" alt="Mac OS X (Leopard) logo"
title="Mac OS X (Leopard) logo" class="logo">
@endhtmlonly
-wxMac is a port of wxWidgets for the Macintosh OS platform.
-Currently MacOS X 10.4 or higher are supported. wxMac can
+@subsection page_port_wxosx_carbon wxOSX/Carbon
+
+wxOSX/Carbon is a port of wxWidgets for the Macintosh OS platform.
+Currently MacOS X 10.4 or higher are supported. wxOSX/Carbon can
be compiled both using Apple's command line developer tools
-as well as Apple's XCode IDE. wxMac supports both the Intel
+as well as Apple's XCode IDE. wxOSX/Carbon supports both the Intel
and PowerPC architectures and can be used to produce
"universal binaries" in order create application which can run
-both architecture. Unfortunately, wxMac does not support any
+both architecture. Unfortunately, wxOSX/Carbon does not support any
64-bit architecture since Apple decided not to port its Carbon
API entirely to 64-bit.
-For further information, please see the files in @c docs/mac
-in the distribution.
+@note Carbon has been deprecated by Apple as of OS X 10.5 and will likely
+be removed entirely in a future OS version. It's recommended you look into
+switching your app over to wxOSX/Cocoa as soon as possible.
+For further information, please see the files in @c docs/osx
+in the distribution.
-@section page_port_wxcocoa wxCocoa
-@htmlonly
-<img src="logo_osxleopard.png" alt="Mac OS X (Leopard) logo"
- title="Mac OS X (Leopard) logo" class="logo">
-@endhtmlonly
+@subsection page_port_wxosx_cocoa wxOSX/Cocoa
-wxCocoa is another port of wxWidgets for the Macintosh OS
-platform. But in contrast to wxMac, it uses the Cocoa API.
-Much work has gone into this port and many controls are
-functional, but the port has not reached the maturity
-of the wxMac port yet. It should be possible to use wxCocoa
+wxOSX/Cocoa is another port of wxWidgets for the Macintosh OS
+platform. In contrast to wxOSX/Carbon, it uses the Cocoa API
+in place of Carbon. Much work has gone into this port and many
+controls are functional, but the port has not reached the maturity
+of the wxOSX/Carbon port yet. It is possible to use wxOSX/Cocoa
on 64-bit architectures.
-For further information, please see the files in @c docs/mac
+In order to configure wxWidgets to compile wxOSX/Cocoa you will
+need to type:
+
+@verbatim configure --with-osx_cocoa @endverbatim
+
+For further information, please see the files in @c docs/osx
in the distribution.
+@note There was a previous effort towards a Cocoa port called
+wxCocoa, which was implemented totally with Cocoa API unlike the OSX/Cocoa port
+which uses OS X C APIs to share code, and while it is no longer being actively
+developed, docs for it are available in @c docs/cocoa in the distribution.
+
+
@section page_port_wxmgl wxMGL
<img src="logo_win.png" alt="Windows logo" title="Windows logo" class="logo">
@endhtmlonly
-wxMSW is a port of wxWidgets for the Windows platforms
-including Windows 95, 98, ME, 2000, NT, XP in ANSI and
-Unicode mode (for Windows 95 through the MSLU extension
-library). wxMSW ensures native look and feel for XP
-as well when using wxWidgets version 2.3.3 or higher.
-wxMSW can be compile with a great variety of compilers
-including MS VC++, Borland 5.5, MinGW32, Cygwin and
-Watcom as well as cross-compilation with a Linux hosted
+wxMSW is a port of wxWidgets for the Windows platforms including Windows 95,
+98, ME, 2000, NT, XP and Vista in ANSI and Unicode modes (for Windows 9x and
+ME through the MSLU extension library). wxMSW ensures native look and feel for
+XP when using wxWidgets version 2.3.3 or higher.wxMSW can be compiled with a
+great variety of compilers including Microsoft Studio VC++, Borland 5.5,
+MinGW32, Cygwin and Watcom as well as cross-compilation with a Linux-hosted
MinGW32 tool chain.
For further information, please see the files in docs/msw
If you don't specify a border style for a wxTextCtrl in rich edit mode, wxWidgets now gives
the control themed borders automatically, where previously they would take the Windows 95-style
-sunken border. Other native controls such as wxTextCtrl in non-rich edit mode, and wxComboBox,
+sunken border. Other native controls such as wxTextCtrl in non-rich edit mode, and wxComboBox
already paint themed borders where appropriate. To use themed borders on other windows, such
as wxPanel, pass the @c wxBORDER_THEME style, or (apart from wxPanel) pass no border style.
@li Adding controls to wxToolMenuBar is not supported. However, wxToolBar supports
controls.
-Unlike in all other ports, a wxDialog has a wxToolBar, automatically created
+Unlike in all other ports, a wxDialog has a wxToolBar automatically created
for you. You may either leave it blank, or access it with wxDialog::GetToolBar()
and add buttons, then calling wxToolBar::Realize(). You cannot set or recreate
the toolbar.
commctrl.lib winsock.lib wininet.lib</tt>
(since the library names in the wxWidgets workspace were changed by VS 2005).
-Alternately, you could could edit all the names to be identical to the original eVC++
+Alternately, you could edit all the names to be identical to the original eVC++
names, but this will probably be more fiddly.
@subsubsection page_port_wxmsw_wince_issues Remaining issues
In such case (or when you want to e.g. write a port-specific patch) it can be
necessary to use the underlying toolkit API directly:
-@li wxMSW port uses win32 API: see MSDN docs at http://msdn2.microsoft.com/en-us/library/ms649779.aspx
-@li wxGTK port uses GTK+: see GTK+ 2.x docs at http://developer.gnome.org/doc/API/2.0/gtk/index.html
-@li wxMac port uses the Carbon API: see Carbon docs at http://developer.apple.com/carbon
-@li wxCocoa port uses the Cocoa API: see Cocoa docs at http://developer.apple.com/cocoa
+- wxMSW port uses win32 API: see MSDN docs at http://msdn2.microsoft.com/en-us/library/ms649779.aspx
+- wxGTK port uses GTK+ and other lower-level libraries; see
+ - GTK+ docs at http://library.gnome.org/devel/gtk/unstable/
+ - GDK docs at http://library.gnome.org/devel/gdk/unstable/
+ - GLib docs at http://library.gnome.org/devel/glib/unstable/
+ - GObject docs at http://library.gnome.org/devel/gobject/unstable/
+ - Pango docs at http://library.gnome.org/devel/pango/unstable/
+- wxMac port uses the Carbon API: see Carbon docs at http://developer.apple.com/carbon
+- wxCocoa port uses the Cocoa API: see Cocoa docs at http://developer.apple.com/cocoa
*/
projects / wxWidgets.git / blobdiff