The text is collected from docs/contributing/release.md and the blog post explaining usage of binaries.
		
			
				
	
	
		
			202 lines
		
	
	
		
			8.3 KiB
		
	
	
	
		
			C
		
	
	
	
	
	
			
		
		
	
	
			202 lines
		
	
	
		
			8.3 KiB
		
	
	
	
		
			C
		
	
	
	
	
	
/////////////////////////////////////////////////////////////////////////////
 | 
						|
// Name:        platdetails.h
 | 
						|
// Purpose:     Platform details page of the Doxygen manual
 | 
						|
// Author:      wxWidgets team
 | 
						|
// Licence:     wxWindows licence
 | 
						|
/////////////////////////////////////////////////////////////////////////////
 | 
						|
 | 
						|
 | 
						|
/**
 | 
						|
 | 
						|
@page page_port Platform Details
 | 
						|
 | 
						|
@tableofcontents
 | 
						|
 | 
						|
wxWidgets defines a common API across platforms, but uses the native graphical
 | 
						|
user interface (GUI) on each platform, so your program will take on the native
 | 
						|
look and feel that users are familiar with. Unfortunately native toolkits and
 | 
						|
hardware do not always support the functionality that the wxWidgets API
 | 
						|
requires. This chapter collects notes about differences among supported
 | 
						|
platforms and ports.
 | 
						|
 | 
						|
 | 
						|
 | 
						|
@section page_port_wxgtk wxGTK
 | 
						|
 | 
						|
wxGTK is a port of wxWidgets using the GTK+ library. It makes use of GTK+'s
 | 
						|
native widgets wherever possible and uses wxWidgets' generic controls when
 | 
						|
needed. GTK+ itself has been ported to a number of systems, but so far only the
 | 
						|
original X11 version is supported. Support for other GTK+ backends is planned,
 | 
						|
such as the new DirectFB backend.
 | 
						|
 | 
						|
All work is being done on GTK+ version 2.0 and above. Support for GTK+ 1.2 will
 | 
						|
be deprecated in a later release.
 | 
						|
 | 
						|
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 great lengths to allow compiling wxWidgets
 | 
						|
applications with the latest version of GTK+, with the resulting binary working
 | 
						|
on systems even with a 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 need use the
 | 
						|
@c \--with-gtk argument to the @c configure script. This is the default for many
 | 
						|
systems.
 | 
						|
 | 
						|
GTK+ 1.2 can still be used, albeit discouraged. For that you can pass
 | 
						|
@c \--with-gtk=1 to the @c configure script.
 | 
						|
 | 
						|
Support for GTK+ 3 is available starting with wxWidgets 2.9.4, use @c configure
 | 
						|
option @c \--with-gtk=3 to enable it.
 | 
						|
 | 
						|
@subpage plat_gtk_install "Build and Install Instructions"
 | 
						|
 | 
						|
@subpage plat_gtk_overview "wxWidgets on the GNOME Desktop"
 | 
						|
 | 
						|
 | 
						|
 | 
						|
@section page_port_wxosx wxOSX/Cocoa
 | 
						|
 | 
						|
wxOSX/Cocoa is the port of wxWidgets for the OS X platform. It requires
 | 
						|
OS X 10.7 or later and fully supports 64 bit builds.
 | 
						|
 | 
						|
@subpage plat_osx_install "Build and Install Instructions"
 | 
						|
 | 
						|
 | 
						|
 | 
						|
 | 
						|
@section page_port_wxx11 wxX11
 | 
						|
 | 
						|
wxX11 is a port of wxWidgets using X11 (The X Window System) as the underlying
 | 
						|
graphics backend. wxX11 draws its widgets using the wxUniversal widget set
 | 
						|
which is now part of wxWidgets. wxX11 is well-suited for a number of special
 | 
						|
applications such as those running on systems with few resources (PDAs) or for
 | 
						|
applications which need to use a special themed look.
 | 
						|
 | 
						|
In order to configure wxWidgets to compile wxX11 you will need to type:
 | 
						|
 | 
						|
@verbatim configure --with-x11 --with-universal @endverbatim
 | 
						|
 | 
						|
@subpage plat_x11_install "Build Instructions"
 | 
						|
 | 
						|
There is also a page on the use of wxWidgets for embedded
 | 
						|
applications on the wxWidgets web site.
 | 
						|
 | 
						|
 | 
						|
 | 
						|
@section page_port_wxmotif wxMotif
 | 
						|
 | 
						|
wxMotif is a port of wxWidgets for X11 systems using Motif libraries. Motif
 | 
						|
libraries provide a clean and fast user interface at the expense of the beauty
 | 
						|
and candy of newer interfaces like GTK.
 | 
						|
 | 
						|
@subpage plat_motif_install "Build Instructions"
 | 
						|
 | 
						|
 | 
						|
 | 
						|
 | 
						|
@section page_port_wxmsw wxMSW
 | 
						|
 | 
						|
wxMSW is a port of wxWidgets for the Windows platforms (Windows XP and later
 | 
						|
are supported). wxMSW provides native look and feel for each Windows version.
 | 
						|
This port can be compiled with several compilers including Microsoft Studio
 | 
						|
VC++ 2003 or later, Borland 5.5, MinGW32, Cygwin as well as cross-compilation
 | 
						|
with a Linux-hosted MinGW32 tool chain.
 | 
						|
 | 
						|
@subpage plat_msw_install "Build and Install Instructions"
 | 
						|
 | 
						|
@subpage plat_msw_binaries "Using pre-built binaries"
 | 
						|
 | 
						|
@subsection page_port_wxmsw_resources Resources and Application Icon
 | 
						|
 | 
						|
All applications using wxMSW should have a Windows resource file (@c .rc
 | 
						|
extension) and this file should include @c include/wx/msw/wx.rc file which
 | 
						|
defines resources used by wxWidgets itself.
 | 
						|
 | 
						|
Among other things, @c wx.rc defines some standard icons, all of which have
 | 
						|
names starting with the "wx" prefix. This normally ensures that any icons
 | 
						|
defined in the application's own resource file come before them in alphabetical
 | 
						|
order which is important because Explorer (Windows shell) selects the first
 | 
						|
icon in alphabetical order to use as the application icon which is displayed
 | 
						|
when viewing its file in the file manager. So if all the icons defined in your
 | 
						|
application start with "x", "y" or "z", they won't be used by Explorer. To
 | 
						|
avoid this, ensure that the icon which is meant to be used as the main
 | 
						|
application icon has a name preceding "wxICON" in alphabetical order.
 | 
						|
 | 
						|
 | 
						|
@subsection page_port_wxmsw_themedborders Themed Borders
 | 
						|
 | 
						|
Starting with wxWidgets 2.8.5, you can specify the @c wxBORDER_THEME style to
 | 
						|
have wxWidgets use a themed border. Using the default XP theme, this is a thin
 | 
						|
1-pixel blue border, with an extra 1-pixel border in the window client
 | 
						|
background colour (usually white) to 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 sunken border style. 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.
 | 
						|
 | 
						|
In general, specifying @c wxBORDER_THEME will cause a border of some kind to be
 | 
						|
used, chosen by the platform and control class. To leave the border decision
 | 
						|
entirely to wxWidgets, pass @c wxBORDER_DEFAULT. This is not to be confused
 | 
						|
with specifying @c wxBORDER_NONE, which says that there should definitely be
 | 
						|
@e no border.
 | 
						|
 | 
						|
@subsubsection page_port_wxmsw_themedborders_details Internal Border Implementation
 | 
						|
 | 
						|
The way that wxMSW decides whether to apply a themed border is as follows. The
 | 
						|
theming code calls wxWindow::GetBorder() to obtain a border. If no border style
 | 
						|
has been passed to the window constructor, GetBorder() calls GetDefaultBorder()
 | 
						|
for this window. If wxBORDER_THEME was passed to the window constructor,
 | 
						|
GetBorder() calls GetDefaultBorderForControl().
 | 
						|
 | 
						|
The implementation of wxWindow::GetDefaultBorder() on wxMSW calls
 | 
						|
wxWindow::CanApplyThemeBorder() which is a virtual function that tells
 | 
						|
wxWidgets whether a control can have a theme applied explicitly (some native
 | 
						|
controls already paint a theme in which case we should not apply it ourselves).
 | 
						|
Note that wxPanel is an exception to this rule because in many cases we wish to
 | 
						|
create a window with no border (for example, notebook pages). So wxPanel
 | 
						|
overrides GetDefaultBorder() in order to call the generic
 | 
						|
wxWindowBase::GetDefaultBorder(), returning wxBORDER_NONE.
 | 
						|
 | 
						|
@section page_port_wxQt wxQt
 | 
						|
 | 
						|
wxQt is a port of wxWidgets using Qt libraries. It requires Qt 5 or later.
 | 
						|
 | 
						|
@subpage plat_qt_install "Build Instructions"
 | 
						|
 | 
						|
@subpage plat_qt_architecture "Architecture Overview"
 | 
						|
 | 
						|
@section page_port_wxiOS wxiOS
 | 
						|
 | 
						|
wxiOS is a port of wxWidgets using Cocoa touch libraries for iOS. It is very
 | 
						|
basic in it current form, but is included for further improvements and very
 | 
						|
simple applications. It requires iOS 9 or later and fully supports 64 bit builds.
 | 
						|
 | 
						|
@subpage plat_ios_install "Build Instructions"
 | 
						|
 | 
						|
@section page_port_nativedocs Native Toolkit Documentation
 | 
						|
 | 
						|
It's sometimes useful to interface directly with the underlying toolkit
 | 
						|
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:
 | 
						|
 | 
						|
- 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/
 | 
						|
- wxOSX port uses the Cocoa API: see Cocoa docs at http://developer.apple.com/cocoa
 | 
						|
 | 
						|
*/
 |