]> git.saurik.com Git - wxWidgets.git/blobdiff - docs/doxygen/mainpages/platdetails.h
Don't document private event handlers in doc/view frame classes.
[wxWidgets.git] / docs / doxygen / mainpages / platdetails.h
index acf402f62e0b3259c391753076f64e85d517691d..593eb18e40d47ed639d2aa5af6c804cc1663a942 100644 (file)
@@ -3,7 +3,7 @@
 // Purpose:     Platform details page of the Doxygen manual
 // Author:      wxWidgets team
 // RCS-ID:      $Id$
-// Licence:     wxWindows license
+// Licence:     wxWindows licence
 /////////////////////////////////////////////////////////////////////////////
 
 
@@ -19,10 +19,8 @@ requires. This chapter collects notes about differences among supported platform
 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
 @li @ref page_port_wxmotif
 @li @ref page_port_wxmsw
@@ -54,10 +52,10 @@ You will need GTK+ 2.6 or higher which is available from:
 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
@@ -71,72 +69,56 @@ For further information, please see the files in @c docs/gtk
 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.
-
-
-
-@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
-
-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
-on 64-bit architectures.
+@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/mac
+For further information, please see the files in @c docs/osx
 in the distribution.
 
 
-@section page_port_wxmgl wxMGL
 
-wxMGL is a port of wxWidgets using the MGL library available
-from SciTech as the underlying graphics backend. wxMGL draws
-its widgets using the wxUniversal widget set which is part
-of wxWidgets. MGL itself runs on a variety of platforms
-including DOS, Linux hardware (similar to the Linux framebuffer)
-and various graphics systems such as Win32, X11 and OS/2.
-Note that currently MGL for Linux runs only on x86-based systems.
+@subsection page_port_wxosx_cocoa wxOSX/Cocoa
 
-You will MGL 5.0 or higher which is available from
-
-http://www.scitechsoft.com/products/product_download.html
+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.
 
-In order to configure wxWidgets to compile wxMGL you will
+In order to configure wxWidgets to compile wxOSX/Cocoa you will
 need to type:
 
-@verbatim configure --with-mgl --with-universal @endverbatim
+@verbatim configure --with-osx_cocoa @endverbatim
 
-Under DOS, wxMGL uses a dmake based make system.
-
-For further information, please see the files in @c docs/mgl
+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_wxos2 wxOS2
@@ -195,14 +177,12 @@ in the distribution.
 <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
@@ -217,7 +197,7 @@ separate the client area's scrollbars from the border.
 
 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.
 
@@ -422,7 +402,7 @@ or with transparency (for example, using XPMs).
 @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.
@@ -569,7 +549,7 @@ Also change the Linker/Input/Additional Dependencies property to something like
     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
@@ -637,9 +617,14 @@ used by wxWidgets to e.g. use toolkit-specific features.
 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
 
 */