Amebis/wxWidgets
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge branch 'master' into web-request

Browse Source 
Merge with the latest master in preparation for merging into master.

Rebake to resolve conflicts in generated files.
This commit is contained in:
Vadim Zeitlin
2020-12-12 17:44:45 +01:00
parent 68cbd54db0 86a3578a11
commit 6bdab7b3c8
3934 changed files with 147571 additions and 96246 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/base/readme.txt
View File

@@ -30,7 +30,7 @@ executing simultaneously (portably!) and so on.
--------------------------------------
wxBase can be compiled and used under Win32, mostly any modern Unix system
(including OS X), VMS and BeOS (this release couldn't be tested under
(including macOS), VMS and BeOS (this release couldn't be tested under
these platforms so you might encounter some problems but they should be easy
to solve -- please contact us in this case!)

293
docs/changes.txt
View File

@@ -59,6 +59,54 @@ Changes in behaviour not resulting in compilation errors
return just "N" under Linux and macOS. Use the new GetButtonOrdinal() to
update the existing code if necessary.
- Generic wxDataViewCtrl now always resizes its last column to fill all the
available space, as the GTK+ version always did.
- wxGTK wxNotebook::AddPage() doesn't generate any events any more for the
first page being added, for consistency with the other ports.
- wxGTK wxTextCtrl doesn't generate any wxEVT_TEXT when it's created with
non-empty value, for consistency with the other ports.
- wxDC::GetTextExtent() returns height of 0 for empty string in wxGTK and wxOSX
too now, for consistency with wxMSW and other kinds of wxDC.
- wxMSW wxToolBar height now adapts to the height of embedded controls, making
the toolbar taller if necessary, rather than making the controls smaller. To
return to the previous behaviour, you need to explicitly create controls of
smaller size.
- wxDC::DrawCheckMark() draws the same shape under all platforms now, use the
new wxRendererNative::DrawCheckMark() to draw MSW-specific themed check mark.
- wxTE_PROCESS_ENTER must be used to receive wxEVT_TEXT_ENTER events from even
multiline wxTextCtrl, conforming to the documentation, but contrary to the
previous behaviour in wxMSW, when these events were always generated in this
case. Please add wxTE_PROCESS_ENTER style if you relied on the old behaviour.
- wxGLCanvas now uses physical pixels on high DPI displays under platforms
where they're different from logical ones (wxGTK3, wxOSX). Multiply logical
coordinates, e.g. returned by wxWindow::GetSize() by GetContentScaleFactor()
before using them with OpenGL functions.
- wxGTK now uses wxID_NONE item ID for wxEVT_MENU_HIGHLIGHT events sent when
there is no highlighted menu item, instead of wxID_ANY used before, for
consistency with wxMSW.
- wxListCtrl::GetItemState() in wxMSW now checks the passed in item index for
validity, as the generic version under the other platforms already did.
- wxAuiNotebook::RemovePage() now hides the removed page, so it needs to be
shown again if it is reused in another place.
- wxSizer::RecalcSizes() shouldn't be called directly (note that it was never
supposed to be called, only implemented), call Layout() instead.
- wxFileDialog::GetPath() and wxFileDialog::GetFilename() now assert and return
an empty string if called on dialogs with the wxFD_MULTIPLE style.
- wxGetInstallPrefix() now returns wxString.
Changes in behaviour which may result in build errors
-----------------------------------------------------
@@ -72,6 +120,10 @@ Changes in behaviour which may result in build errors
then you will need to add these libraries to your make or project files
yourself.
- wxPaintEvent objects can no longer be created by the application code. This
was never supposed to work and is now forbidden at compile-time instead of
resulting in errors during run-time.
- WXWIN_OS_DESCRIPTION doesn't exist any longer, use wxGetOsDescription().
- Never documented and not always available private wxGetClipboardData()
@@ -101,6 +153,245 @@ Changes in behaviour which may result in build errors
e.g. if the error is due to spelling an option name wrongly, fixing or
removing its name.
- wxTextValidator::Get{In,Ex}cludes() now return a const reference to
wxArrayString. Please update your code to use the appropriate setter
Set[Char]{In,Ex}cludes(), instead of mutating the internal data directly.
- Under macOS, 10.11 SDK is the minimum SDK, building and deploying under 10.10.5 and
higher is supported, you must use at least Xcode 7.2.1.
- wxPGProperty ctors are not longer public since this class is intended to be
a base class and should not be instantiated directly.
- wxIntProperty::DoValidation() and wxFloatProperty::DoValidation() are
no longer public since they are helpers intended for internal use only.
- wxGridCellAttr ctor taking wxGridCellAttr pointer is now explicit.
- wxAuiPaneButton doesn't exist any more, it was never supposed to be used
outside of the library, but if you did use, just use "int" button instead.
- wxAuiMDIChildFrame now inherits from wxFrame and not wxPanel, you will need
to change your code and XRC definitions accordingly.
3.1.5: (released 2020-10-??)
----------------------------
NOTE: This file is updated only before the release, please use
$ git log --notes=changelog --format='%N' v3.1.4..|grep .
to see all the change log entries since the last release and use
$ git notes --ref=changelog add -m 'wxPort: description.' to update it.
3.1.4: (released 2020-07-22)
----------------------------
INCOMPATIBLE CHANGES SINCE 3.1.3:
- CMake library targets were renamed and now start with 'wx'. In addition,
aliases for the libraries have been added using the 'wx::' namespace. For
example, the core library is now named wxcore and has alias wx::core.
- Building on ARM Apple platforms using configure now targets macOS by
default, and not iOS. Please use --with-osx_iphone explicitly if you need
the latter.
All:
- Add natural sort functions (Hugo Elias, PB).
- Add wxTempFFile class (Dummy).
- Fix bug with multiple leading ".." in wxFileName::Normalize() (Fabian Cenedese).
- Improve brush transparency support in wxSVGFileDC (Maarten Bent).
- Optionally forbid implicit wxString/char* conversions (Arrigo Marchiori).
- Add --disable-tests configure option (Hertatijanto Hartono).
All (GUI):
- Many wxGrid improvements:
- Live-resize wxGrid columns/rows, making it work with wxGTK3 and wxOSX too.
- Add activatable editors support, use it for boolean cells.
- Add support for copying selected cells to clipboard (Kvaz1r).
- Many bug fixes and usability improvements to selection.
- Improve wxGridCellChoiceEditor usability (Ian McInerney).
- Significantly optimize wxGrid::AutoSizeColumns() for big grids.
- Add ellipsization support.
- Add support for wxGenericAnimationCtrl to XRC (Ilya Sinitsin).
- Add wxDD_SHOW_HIDDEN and wxDD_MULTIPLE wxDirDialog flags (Ian McInerney, PB).
- Add wxWebView::SetZoomFactor(float) (Hertatijanto Hartono).
- Add wxWindow::DisableFocusFromKeyboard() (Tomay).
- Allow overriding wxDataViewModal::HasValue() (Jorge Moraleda).
- Call wxAuiManager::UnInit() automatically now.
- Fix crash and layout problem in wxGenericDirCtrl (Maarten Bent).
- Improve AUI appearance in dark mode (Daniel Kulp, Michel Le Bihan).
- Upgrade libjpeg to 9d.
- Enable SIMD use in builtin PNG library (Maarten Bent).
wxGTK:
- Add native wxSearchCtrl implementation (AliKet).
- Several bug fixes and improvements in wxSpinCtrl.
- Implement wxBU_EXACTFIT support in wxButton (Artur Wieczorek).
- Allow using generic wxAnimationCtrl if wanted.
- Fix a regression with crashes when using wxBufferedPaintDC.
- Fix drawing bitmaps with masks using wxGraphicsContext under GTK2.
- Fix position of popup menus on non-primary display.
- Make wxUIActionSimulator much more reliable (AliKet).
- Fix caret colour in wxTextCtrl with custom colours.
wxMSW:
- Add Edge-based wxWebView backend (Tobias Taschner).
- Add wxUSE_DPI_AWARE_MANIFEST option (Maarten Bent).
- Add support for private fonts to Direct2D renderer (Artur Wieczorek).
- Adjust sizer borders on DPI change too (Maarten Bent).
- Allow showing only scalable fonts in wxFontDialog (Gilbert Pelletier).
- Fix building with gcc 10.1 in C++20 mode (PB).
- Fix flicker when resizing MDI frames (Richard Reznicek).
- Fix position of IME in wxSTC (wangqr).
- Fix wxWindow::Reparent() for TLWs (Danail Stoychev).
- Improve TAB handling in wxListBox (Artur Sochirca).
- Make CMake build using MinGW consistent with configure (Maarten Bent).
- Make wxDC::GetExtent() much faster (and a bit less precise).
wxOSX:
- Add support for macOS 11.
- Make wxOverlay work under macOS Mojave and later.
- Allow disabling automatic tabbing (Ian McInerney).
- Avoid duplicate key down events for Ctrl-O.
- Fix event generation, notably for mouse clicks, on wxStaticBitmap.
- Make shaped windows work again.
- Fix bugs in client size computation for some controls.
- Invalidate display cache when system configuration changes.
- Fix not showing more than 13 combobox items under 10.13+ (Dan Korn).
- Fix regression with child process IO redirection in 3.1.3.
- Fix regression with copying to clipboard in 3.1.3.
- Fix wxMediaCtrl::Seek() for sub-second resolution (Scott Talbert).
- Improve wxTextCtrl and wxSpinCtrl sizing (wangqr).
- Send EVT_MENU_HIGHLIGHT when menu items are unhighlighted (Ian McInerney).
- Stop including SDK headers from public wx headers (Lauri Nurmi).
- Support background colour in wxDataViewCtrl attributes (Ian McInerney).
wxiOS:
- Fix bundled libpng to not crash on iOS < 10.13 (maccy2).
- Implement wxMenu.
wxQt:
- Fix build with Qt 5.15 (Stefan Brüns).
3.1.3: (released 2019-10-28)
----------------------------
INCOMPATIBLE CHANGES SINCE 3.1.2:
- New wxTranslations::GetAcceptableTranslations() method was problematic and
was removed, fixing various regressions in wxTranslations::AddCatalog() that
were introduced by it. Thanks to Tomasz Słodkowicz and Dummy for reporting
this and providing fixes for it.
All:
- Add C++20-style wxString::starts_with()/ends_with() functions (Lauri Nurmi).
- Add Croation translations (Milo Ivir).
- Add wxRegEx::QuoteMeta() (Tomay).
- Fix MIME type for wxFSFile obtained from wxHTTP.
- Support nullptr in wxPrintf() etc.
- Allow specifying optional libs in WX_CONFIG_CHECK (Juha Sointusalo).
All (GUI):
- Add support for freezing columns and/or rows in wxGrid (Lucian Rotariu)
- Fix wxInfoBar close button size in high DPI (Stefan Ziegler).
- Make disabling the window before creating it actually work.
- Implement wxAuiNotebook::GetBestSize() (Sebastian Walderich).
- Add support for editing dates (without time) to wxGrid (Pavel Kalugin).
- Allow changing tooltip text for button allowing to enter a new string
in wxPGArrayEditorDialog.
- Fix wxPropertyGrid issues with horizontal scrolling.
- Add wxPG_DIALOG_TITLE wxPGProperty attribute.
- Add support for creating a wxGraphicsPen with a gradient.
- Add support for applying a transformation matrix to a gradient.
- Fix and unify drawing wxBitmap with both alpha channel and mask under all platforms.
- Improve AUI notebook appearance in high DPI (Paul Kulchenko).
- Add XRC handler for wxDataViewCtrl (Anton Triest).
- Add XRC handler for wxInfoBar (Илья Синицын).
- Add support for checkboxes to virtual wxListCtrl too (Maarten Bent).
- Add wxBusyInfo::Update{Text,Label}() (Kvaz1r).
- Add wxDCTextBgColourChanger and wxDCTextBgModeChanger (Vsevolod V Gromov).
- Add wxFD_SHOW_HIDDEN flag to wxFileDialog (Igor Korot).
- Add wxRendererNative::DrawCheckMark() (Maarten Bent).
- Add wxSystemAppearance, notably useful for macOS dark mode checks.
- Allow expanding environment variables in XRC file paths (ousnius).
- Enhance support for underlining in wxTextCtrl.
- Fix spurious asserts in wxBoxSizer when wxSHAPED is used.
- Fix wxWrapSizer minimum size calculations (Илья Синицын).
- Improve popups appearance and behaviour in wxSTC (New Pagodi).
- Improve wxHtmlWindow selection appearance and behaviour (Павел Калугин).
wxGTK:
- Invalidate selection after deleting wxListBox item with GTK+ 3 too.
- Add support for ticks to wxSlider (Iwbnwif Yiw).
- Fix two-finger scrolling under Wayland (Scott Talbert).
- Fix wxEVT_KEY_DOWN for non-ASCII characters (Scott Talbert).
- Fix crash in wxDataViewTreeCtrl::DeleteAllItems().
- Make wxDataViewModel::Cleared() behave consistently with the other ports.
- Fix best size computation for multiline wxTextCtrl.
- Fix best size computation for wxGauge (Iwbnwif Yiw).
wxMSW:
- Add support for per-monitor DPI under new enough OS versions (Maarten Bent).
- Add MSVS 2019 support.
- Fix passing Unicode strings via wxIPC when using DDE.
- Improve wxDataViewCtrl performance with variable line heights (Jens Goepfert).
- Add EVT_COLOURPICKER_CURRENT_CHANGED (Trylz).
- Fix linking of monolithic library with MinGW (Jannick).
- Support fill mode in GDI+ and D2D graphics contexts (Maarten Bent).
- Add wxFileDialog::GetCurrentlySelectedFilterIndex() (QuentinC).
- Add wxPU_CONTAINS_CONTROLS style for popups (New Pagodi).
- Add wxWebViewIE::MSWSetEmulationLevel() (Chilau He).
- Allow showing ToC/search in wxCHMHelpController (Andreas Falkenhahn)
- Fix RegisterHotKey() work with WXK_XXX.
- Fix changing wxSpinCtrl colours (Kvaz1r).
- Fix compilation in deprecated ANSI build mode.
- Fix drawing cross hair on wxDC.
- Fix input handling bugs in text controls with autocompleters.
- Fix pasting very long strings into wxTextCtrl.
- Fix resetting columns images in wxListCtrl (followait).
- Optimize drawing solid vertical and horizontal lines on wxDC
- Recognize UTF-8 system encoding supported in latest MSW 10 versions.
- Work around nVidia bug with OpenGL and coloured buttons.
- Handle Ctrl+A in focused wxTextCtrl instead of always as an accelerator.
wxOSX:
- Support for macOS Mojave and later dark mode.
- Fix crash in wxGauge with wxGA_PROGRESS (Konstantin Matveyev).
- Fix crash when pasting from clipboard (Tim Kosse).
- Fix dragging files (Dan Gudmundsson).
- Fix fetching sub-bitmap from wxBitmap with maskAll
- Fix wxPOPUP_WINDOW style (Dan Korn).
- Make it possible to play wxSound again (frustum).
- Allow setting focus before showing the window.
- Fix order of accelerators handling, giving priority to focused window.
- Don't stop TAB navigation on wxRadioBox when full keyboard access is off.
wxQt:
- Too many changes to list. Thanks to Graham Dawes, Jay Nabonne, Matthew
Griffin, Liam Treacy, Chris Lemin, Cătălin Răceanu, Richard Smith, Mick
Waites and others.
3.1.2: (released 2018-12-10)
----------------------------
@@ -604,7 +895,7 @@ wxMSW:
wxOSX/Cocoa:
- Make wxiOS (iPhone) port build and minimally work again (Tobias Taschner).
- Use more efficient FSEvents (10.7+) in wxFileSystemWatcher (Roberto Perpuly).
- Use more efficient FSEvents in wxFileSystemWatcher (Roberto Perpuly).
- Implement wxWindow::Disable() for non-native controls too (Steve Browne).
- Implement wxTopLevelWindow::EnableCloseButton() (John Roberts).
- Fix wxEVT_CHAR for non-BMP Unicode characters (ARATA Mizuki).

4
docs/changes_30.txt
View File

@@ -733,10 +733,10 @@ All (GUI):
- Support hexadecimal numbers in wxSpinCtrl.
- Respect window max size in wxBoxSizer (Nathan Ridge).
- Add support for searching in wxWebView for MSW and GTK (Allonii).
- Add generic wxFileSystem support to wxWebView with
- Add generic wxFileSystem support to wxWebView with
wxWebViewFSHandler (Nick Matthews).
- Add possibility to disable context menu in wxWebView.
- Add ability to register custom wxWebView backends using
- Add ability to register custom wxWebView backends using
wxWebView::RegisterFactory and a wxWebViewFactory derived class.
- Add possibility to hide and show again wxRibbonBar pages (wxBen).
- Add wxRibbonBar pages highlighting (wxBen).

1
docs/contributing/about-version-numbers.md
View File

@@ -27,7 +27,6 @@ Here is the list of files that need to be updated:
include/wx/osx/config_xcode.h
samples/docview/Info.plist
samples/minimal/Info_cocoa.plist
samples/minimal/borland_ide.cpp [not-micro]
Do not forget to rebake everything after updating version.bkl!

23
docs/contributing/binary-compatibility.md
View File

@@ -10,8 +10,8 @@ wxWidgets.
Releases
--------
General overview of releases can be found in tn0012.txt, but for
completeness the wxWidgets release version number is as follows:
General overview of releases can be found in [wxWidgets naming conventions](about-platform-toolkit-and-library-names.md),
but for completeness the wxWidgets release version number is as follows:
2.6.2
@@ -20,9 +20,9 @@ Where
2 6 2
Major Minor Release
(I.E. Major.Minor.Release).
(i.e. Major.Minor.Release).
All versions with EVEN minor version component (e.g. 2.4.x, 2.6.x etc.)
All versions with EVEN minor version component (e.g. 2.8.x, 3.0.x etc.)
are expected to be binary compatible (ODD minors are development versions
and the compatibility constraints don't apply to them). Note that by
preserving binary compatibility we mean BACKWARDS compatibility only,
@@ -37,8 +37,7 @@ also the section about `wxABI_VERSION`.
What kind of changes are NOT binary compatible
----------------------------------------------
If it's still up, the
[KDE guide](http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++)
[The KDE guide](https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B)
is a good reference.
@@ -68,8 +67,8 @@ Changes which are compatible
- Adding a new non-virtual method to an existing class
- Adding a new constructor to an existing class
- Overriding the implementation of an existing virtual function
(this is considered to be backwards binary compatible until we find a
counter example; currently it's known to work with Apple gcc at least)
(this is considered to be backwards binary compatible until we find a
counter example; currently it's known to work with Apple gcc at least)
- Anything which doesn't result in ABI change at all, e.g. adding new
macros, constants and, of course, private changes in the implementation
@@ -99,7 +98,7 @@ where
2 06 02
Major Minor Release
I.E. it corresponds to the wxWidgets release in (1).
I.e. it corresponds to the wxWidgets release in section Releases.
An example of using `wxABI_VERSION` is as follows for symbols
only in a 2.6.2 release:
@@ -178,11 +177,11 @@ anything which fits the conditions of being `#if`'ed via `wxABI_VERSION`
needs to go here also.
See 'info ld scripts version' on a GNU system, it's online here:
http://www.gnu.org/software/binutils/manual/ld-2.9.1/html_node/ld_25.html
https://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_node/ld_25.html
Or see chapter 5 of the 'Linker and Libraries Guide' for Solaris, available
online here:
http://docsun.cites.uiuc.edu/sun_docs/C/solaris_9/SUNWdev/LLM/p1.html
https://docs.oracle.com/cd/E19120-01/open.solaris/819-0690/chapter5-84101/index.html
The file has the layout as follows:
@@ -210,7 +209,7 @@ so a line like this could be added to version-script.in:
\*wxGenericListCtrl*GetItemFont*;
Allow for the fact that the name mangling is going to vary from compiler to
complier.
compiler.
When adding a class you can match all the symbols it adds with a single
pattern, so long as that pattern is not likely to also match other symbols.

21
docs/contributing/how-to-add-class-documentation.md
View File

@@ -18,10 +18,10 @@ The documentation can then be added in form of Doxygen comments to
the header file.
You may also want to write a separate topic file,
e.g. docs/doxygen/overviews/myclass.h, and add the entry to
docs/doxygen/mainpages/topics.h.
e.g. `docs/doxygen/overviews/myclass.h`, and add the entry to
`docs/doxygen/mainpages/topics.h`.
If applicable, also add an entry to one of the docs/doxygen/mainpages/cat_*.h
If applicable, also add an entry to one of the `docs/doxygen/mainpages/cat_*.h`
files.
You can generate a first raw version of myclass.h simply taking its
@@ -33,8 +33,9 @@ which are implementation details.
Running Doxygen
---------------
First, make sure you have a recent version of Doxygen installed in your system
(currently Doxygen 1.8.8 is used).
First, make sure you have a recent version of Doxygen (currently Doxygen 1.8.8
is used) and Graphviz installed in your system (under Windows Graphviz
location should be in %PATH%).
On Unix:
@@ -57,13 +58,17 @@ Important Dos and Don'ts
DO:
- use present tense verbs in 3rd person singular form to describe functions,
i.e. write "Returns the answer to life, universe and everything", rather than
the imperative mood used in Git commit message ("Return the answer ...").
- Doxygen supports both commands in the form \command and @command;
all wxWidgets documentation uses the @command form.
Follow strictly this rule.
- strive to use dedicated Doxygen commands for e.g. notes, lists,
sections, etc. The "Special commands" page:
http://www.stack.nl/~dimitri/doxygen/commands.html
http://www.doxygen.org/manual/commands.html
is your friend!
It's also very important to make a consistent use of the ALIASES
defined by wxWidgets' Doxyfile. Open that file for more info.
@@ -286,9 +291,9 @@ there is a corresponding link anchor.
The following conventions are used in wxWidgets doxygen comments:
1. all "main" pages of the manual (those which are placed in
docs/doxygen/mainpages) have link anchors which begin with "page_"
docs/doxygen/mainpages) have link anchors which begin with `page_`
2. all topic overviews (those which are placed in docs/doxygen/overviews) have
link anchors which begin with "overview_"
link anchors which begin with `overview_`
3. all @section, @subsection, @subsubsection tags should have as link anchor
name the name of the parent section plus a specific word separated with an
underscore; e.g.:

108
docs/contributing/how-to-add-files-to-build-system.md
View File

@@ -5,26 +5,26 @@ How to add new files and libraries to wxWidgets build system
Regenerating makefiles
----------------------
wxWidgets now uses [Bakefile](http://bakefile.sourceforge.net) to generate
native makefiles. You must have bakefile installed if you want to regenerate
the makefiles. Bakefile currently runs on Unix and Windows systems. You will
need Python 2.x installed on Unix and either use Bakefile installer or have
Python on Windows.
wxWidgets uses the legacy 0.2 branch [Bakefile](https://www.bakefile.org) to
generate native makefiles.
Currently the latest version from legacy-0.2-branch must be used, so you need
to compile it from source, which requires Python 2 headers and libraries.
Once you have installed Bakefile, you can easily regenerate the makefiles using
the bakefile_gen tool. Run it from $(wx)/build/bakefiles directory and it will
regenerate all outdated makefiles. See $(wx)/build/bakefiles/README for more
the `bakefile_gen` tool. Run it from `$(wx)/build/bakefiles` directory and it will
regenerate all outdated makefiles. See `$(wx)/build/bakefiles/README` for more
details.
Note that it generates makefiles for samples, too.
IMPORTANT NOTE: Don't forget to run autoconf in wxWidgets root directory
(after running Bakefile) if you changed any conditional
variable or target condition in .bkl files! You will know that
this happened if $(wx)/autoconf_inc.m4 content changed.
(after running Bakefile) if you changed any conditional
variable or target condition in .bkl files! You will know that
this happened if `$(wx)/autoconf_inc.m4` content changed.
You can use Bakefile to generate makefiles or projects customized to your
needs, too. See Bakefiles.bkgen for details on bakefile commands used to
needs, too. See `Bakefiles.bkgen` for details on bakefile commands used to
generate makefiles. For example, you can use this command to generate
VC++ project files without wxUniversal configurations:
@@ -47,9 +47,9 @@ Or monolithic wxBase:
-DOFFICIAL_BUILD=0 -DUSE_HTML=0 -DUSE_OPENGL=0
-DMONOLITHIC=1 -DUSE_GUI=0 wx.bkl
It is, however, recommended to modify Bakefiles.bkgen (or
Bakefiles.local.bkgen) by means of `<add-flags>` and `<del-flags>` directives
and use bakefile_gen instead of running bakefile directly.
It is, however, recommended to modify `Bakefiles.bkgen` (or
`Bakefiles.local.bkgen)` by means of `<add-flags>` and `<del-flags>` directives
and use `bakefile_gen` instead of running bakefile directly.
Bakefile files organization
@@ -57,42 +57,42 @@ Bakefile files organization
Makefile are generated from .bkl files ("bakefiles") from two places:
- $(wx)/build/bakefiles directory
- `$(wx)/build/bakefiles` directory
- samples directories
$(wx)/build/bakefiles contains bakefiles for main library and support files
`$(wx)/build/bakefiles` contains bakefiles for main library and support files
that simplify writing bakefiles for samples.
Support files are:
- wxwin.py - helper functions
- common.bkl
- common_samples.bkl
- config.bkl - user-configurable build options
- make_dist.mk - implementation of "make dist" on Unix
- `wxwin.py` - helper functions
- `common.bkl`
- `common_samples.bkl`
- `config.bkl` - user-configurable build options
- `make_dist.mk` - implementation of "make dist" on Unix
Files used to build the library are:
- wx.bkl - main file
- files.bkl - lists of source files
- monolithic.bkl - targets for wxWin built as single big library
- multilib.bkl - targets for multilib build
- opengl.bkl - GL library with wxGLCanvas (this one is not
included in monolithic library for historical
reasons, so "monolithic" really means "two libs")
- {expat,jpeg,png,tiff, regex,zlib,odbc}.bkl - 3rd party libraries makefiles
- `wx.bkl` - main file
- `files.bkl` - lists of source files
- `monolithic.bkl` - targets for wxWin built as single big library
- `multilib.bkl` - targets for multilib build
- `opengl.bkl` - GL library with wxGLCanvas (this one is not
included in monolithic library for historical reasons, so "monolithic" really
means "two libs")
- `{expat,jpeg,png,tiff, regex,zlib,odbc}.bkl` - 3rd party libraries makefiles
Adding files to existing library
--------------------------------
**UPDATE:** files.bkl is now itself partially generated from the master file
build/files. If the variable which you need to modify, according to the
instructions below, is already defined in build/files, update it there
and run build/upmake to update files.bkl.
**UPDATE:** `files.bkl` is now itself partially generated from the master file
`build/files`. If the variable which you need to modify, according to the
instructions below, is already defined in `build/files`, update it there and run
`build/upmake` to update `files.bkl`.
All files used by main libraries are listed in files.bkl. The file is
All files used by main libraries are listed in `files.bkl`. The file is
organized into variables for toolkits, platforms and libraries. The variables
come in pairs: there's always `FOO_SRC` for source files and `FOO_HDR` for header
files. Platform or toolkit specific files are grouped together in variable
@@ -100,7 +100,7 @@ with platform or toolkit name in them, e.g. `BASE_WIN32_SRC`, `BASE_UNIX_SRC`,
`GTK_SRC`, `MOTIF_SRC`.
Note: A side effect of this toolkit-centric organization is that one file may
be present several times in files.bkl in different contexts.
be present several times in `files.bkl` in different contexts.
When you are adding a file, you must put it into appropriate variable. This is
easy if you are adding the file to library that is always built from same
@@ -125,7 +125,7 @@ Adding sample
Copy the bakefile from another sample, change the ID and files accordingly.
If the sample uses some data files, make sure to have `<wx-data>` node
in the sample's bakefile (see e.g. samples/image/image.bkl for an example).
in the sample's bakefile (see e.g. `samples/image/image.bkl` for an example).
Make sure to add `<wx-lib>` statements for all libraries from multilib build
that are required by the sample.
@@ -133,11 +133,11 @@ The Windows resource specification should use the central .rc file:
<win32-res>../sample.rc</win32-res>
Run bakefile_gen in $(wx)/build/bakefiles to regenerate the bakefiles.
Run `bakefile_gen` in `$(wx)/build/bakefiles` to regenerate the bakefiles.
Finally commit $(wx)/build/bakefiles/make_dist.mk and all the other modified files.
Finally commit `$(wx)/build/bakefiles/make_dist.mk` and all the other modified files.
Currently we commit the generated makefiles except .dms, .vcp.
Currently we commit all the generated makefiles.
Adding new core library
@@ -150,21 +150,21 @@ called wxFoo.
a) Add files to files.bkl:
* If wxFoo builds from same files on all platforms (e.g. wxNet),
add `FOO_SRC` and `FOO_HDR` variables with lists of sources and headers.
add `FOO_SRC` and `FOO_HDR` variables with lists of sources and headers.
* If wxFoo have no files in common (e.g. wxGL), add `FOO_SRC` and `FOO_HDR`
with toolkit or platform conditions. Have a look at `OPENGL_SRC` for an
example.
with toolkit or platform conditions. Have a look at `OPENGL_SRC` for an
example.
* Otherwise add `FOO_CMN_SRC` and `FOO_CMN_HDR` for common files and
`FOO_{platform}_{SRC,HDR}` or `FOO_{toolkit}_{SRC,HDR}` as appropriate. Add
`FOO_PLATFORM_{SRC,HDR}` into "Define sources for specific libraries"
section that is conditionally set to one of `FOO_xxx_{SRC,HDR}` based on
target platform/toolkit (see `NET_PLATFORM_SRC` definition for an example).
Finally, define `FOO_SRC` and `FOO_HDR` to contain both
`FOO_PLATFORM_{SRC,HDR}` and `FOO_{SRC,HDR}` (see `NET_SRC` definition for an
example).
`FOO_{platform}_{SRC,HDR}` or `FOO_{toolkit}_{SRC,HDR}` as appropriate. Add
`FOO_PLATFORM_{SRC,HDR}` into "Define sources for specific libraries"
section that is conditionally set to one of `FOO_xxx_{SRC,HDR}` based on
target platform/toolkit (see `NET_PLATFORM_SRC` definition for an example).
Finally, define `FOO_SRC` and `FOO_HDR` to contain both
`FOO_PLATFORM_{SRC,HDR}` and `FOO_{SRC,HDR}` (see `NET_SRC` definition for an
example).
* Add `FOO_HDR` to `ALL_GUI_HEADERS` or `ALL_BASE_HEADERS`.
* If wxFoo is wxBase library (doesn't use GUI), add `FOO_SRC` to
`ALL_BASE_SOURCES`.
`ALL_BASE_SOURCES`.
(You can apply different approaches to HDR and SRC variables, if e.g.
headers are all common but sources are not.)
@@ -174,10 +174,10 @@ a) Add files to files.bkl:
b) Modify bakefile system in build/bakefiles/ to recognize wxFoo:
* Add 'foo' to `MAIN_LIBS` and `LIBS_NOGUI` or `LIBS_GUI` (depending on whether
the library depends on wxCore or not) to wxwin.py file.
the library depends on wxCore or not) to wxwin.py file.
* Add extra libraries needed by wxFoo (if any) to EXTRALIBS in wxwin.py
* Add `WXLIB_FOO` definition to common.bkl (into the "Names of component
libraries" section). It looks like this:
libraries" section). It looks like this:
<set var="WXLIB_FOO">
<if cond="MONOLITHIC=='0'">$(mk.evalExpr(wxwin.mkLibName('foo')))</if>
@@ -228,10 +228,10 @@ h) Add this code to one of wxFoo's files (the more often used, the better):
WX_CHECK_BUILD_OPTIONS("wxFoo")
i) Add information about wxFoo to the manual ("Libraries list" section
in libs.tex) and update docs/latex/wx/libs.dia (you need Dia for this)
in libs.tex) and update `docs/latex/wx/libs.dia` (you need Dia for this)
to show the dependencies of the new library.
j) Also please add `#pragma comment(lib, "foo")` (for all build configuration
combinations) to the file include/msvc/wx/setup.h and
add a check for `WXMAKINGDLL_FOO` to the test whether we're building a DLL at
the end of include/wx/msw/chkconf.h.
the end of `include/wx/msw/chkconf.h`.

64
docs/contributing/how-to-add-new-msvs-version.md Normal file
View File

@@ -0,0 +1,64 @@
How to add support for a new MSVS version
=========================================
MSVS versions
-------------
This is confusing because there are several of them:
- Marketing IDE/product version, which is the year of the release, e.g. 2019.
- Actual internal IDE version, visible in `Help|About` dialog, for example,
e.g. 16.1.4.
- Compiler version, visible in `cl /?` output, e.g. 19.21.27702.2. This version
also corresponds to the value of the predefined `_MSC_VER` symbol.
- Toolset version: this is similar to the compiler version, but uses different
format, e.g. it's 14x for compiler version 19, with `x` being 0, 1 or 2
depending on the minor compiler version (00, 14 or 21).
Moreover, historically, different IDE versions corresponded to different major
compiler versions, however this hasn't been the case any more for the last few
releases (2015, 2017, 2019 or 14, 15, 16 IDE versions) that all use the same
major compiler version (19) as they are ABI-compatible. Also, historically,
each compiler used its own toolset, but these last few versions can each use
any of 140, 141, 142 toolset.
wxWidgets uses the IDE version for the project/solution files (but notice that
project files are the same for all MSVS 201x versions) and the toolset version
for the names of build directories.
TODO list
---------
Here is a list of things that need to be done when adding support for the next
MSVS version:
- If the major compiler version changed, add a new `__VISUALCxx__` symbol to
`include/wx/compiler.h` (`xx` here are the first 2 digits of the toolset
version, i.e. basically correspond to the major compiler version, except
that 13 was skipped for superstitious reasons, see the comment in that file).
- Add `wxCOMPILER_PREFIX` definition for the new version to
`include/msvc/wx/setup.h`.
- Add the new solution file `build/msw/wx_vcNN.sln` (where `NN` is the internal
IDE version), typically by opening an existing solution in the new IDE and
letting it to update it.
- Discard changes to the project files that were done by the IDE during the
update and instead update `build/msw/wx_config.props` and add a new condition
checking `VisualStudioVersion` value for choosing the value of
`PlatformToolset`.
- Update the lists of supported compiler versions in the different
documentation files (search for "Microsoft Visual C++" to find the places
that need updating):
- `README.md`
- `docs/doxygen/mainpages/introduction.h`
- `docs/msw/install.md`
- `docs/release.md`
- Update `build/tools/msvs/officialbuild.bat` to support the new toolset version
and also update `build/tools/msvs/buildall.bat` to call it with this new version
(these files are used to build the official binaries for the releases).
- If necessary, i.e. if the warning C4535 appears when compiling
`src/msw/main.cpp` with the new version, check that this warning is still
harmless, i.e. that catching Win32 exceptions still works correctly (this
can be tested with the "Crash" menu item in the except sample) and update
the version check in `include/wx/msw/seh.h` to suppress this warning for the
new version too.

17
docs/contributing/how-to-add-new-sample.md
View File

@@ -10,17 +10,17 @@ samples/ with demos/ where needed).
2. "git add" the sample sources (usually based on minimal.cpp) as well.
Note that unless your sample requires something special you shouldn't
add foo.rc, foo.ico, ... any more, please just reuse the generic sample.*
add foo.rc, foo.ico, ... any more, please just reuse the generic `sample.*`
files in the samples subdirectory.
3. Create the makefiles:
- modify samples/samples.bkl (just copy an existing line)
- create foo.bkl (`sed 's/minimal/foo/g' minimal.bkl > foo.bkl` is usually
enough, but you may need to add more `<wx-lib>` lines if your sample uses
anything not in the core lib)
enough, but you may need to add more `<wx-lib>` lines if your sample uses
anything not in the core lib)
- generate the makefiles for your sample using bakefile. For this you
need to:
- install bakefile (see http://bakefile.sf.net/)
need to:
- install bakefile (see docs/contributing/how-to-add-files-to-build-system.md)
- run bakefile_gen in build/bakefiles which will regenerate all
makefiles which are not up to date
@@ -29,8 +29,6 @@ samples/ with demos/ where needed).
or even add a `-f<compiler>` to generate just the makefiles for the given
compiler (run `bakefile --help` to get the list of possible values).
See how-to-add-files-to-build-system.md for more information.
- currently samples/samples.dsw needs to be updated manually as it's not
generated by bakefile.
4. Modify configure.in Unix compilation:
- if the sample should only be built if `wxUSE_FOO` is enabled, locate
@@ -56,8 +54,7 @@ samples/ with demos/ where needed).
lives in docs/doxygen/mainpages/samples.h; look at the descriptions for
other samples, if you are not familiar with Doxygen.
7. Add any non-standard sample's files to build/bakefiles/make_dist.mk (the
7. Add any non-standard sample's files to `build/bakefiles/make_dist.mk` (the
makefiles copies all bmp, cpp, h, ico, png, rc, xpm and makefiles by
default, you only need to update it if the sample uses some other files)
and run the ./update-manifests.sh script in distrib/scripts (don't forget
to check the changes to manifests/*.rsp files in).
and run the ./update-manifests.sh script in distrib/scripts.

48
docs/contributing/how-to-add-new-wxUSE_XXX.md
View File

@@ -1,15 +1,15 @@
How to add a new `wxUSE_XXX` preprocessor constant
================================================
0. Purpose
----------
Purpose
-------
Detailed description of what needs to be done when you want to add a new
`wxUSE_XXX` compilation flag. The text below assumes you need new `wxUSE_FOO`.
1. Overview
-----------
Overview
--------
wxWidgets uses `wxUSE_XXX` macros for conditionally compiling in (or not)
optional components. In general, whenever a new non critical (i.e. not
@@ -22,12 +22,12 @@ because then `wxUSE_FOO` would be not defined at all if the user directly
includes wx/foo.h, include "wx/defs.h" before testing for `wxUSE_FOO`.
2. Files to update
------------------
Files to update
---------------
The following files need to be modified when adding a new `wxUSE_FOO`:
a) include/wx/setup_inc.h
- `include/wx/setup_inc.h`
This file contains all common `wxUSE_XXXs`, and is used to update wxMSW, wxMac
setup.h and Unix setup.h.in using build/update-setup-h. Please try to add
@@ -39,49 +39,49 @@ a) include/wx/setup_inc.h
After changing this file, run the update-setup-h script (this is probably
better done on a Unix machine although it should work under Cygwin too).
a') include/wx/msw/setup_inc.h for MSW-specific options
- `include/wx/msw/setup_inc.h` for MSW-specific options
This file contains MSW-specific options, so if the new option is only used
under MSW, add it here instead of include/wx/setup_inc.h. The rest of the
instructions is the same as above.
b) include/wx/chkconf.h
- `include/wx/chkconf.h`
Add the check for `wxUSE_FOO` definedness in the corresponding (base or GUI)
section. Please keep the alphabetic order.
If there are any dependencies, i.e. `wxUSE_FOO` requires `wxUSE_BAR` and
`wxUSE_BAZ`, check for thme here too.
`wxUSE_BAZ`, check for them here too.
b') include/wx/msw/chkconf.h for MSW-specific options
- `include/wx/msw/chkconf.h` for MSW-specific options
These options won't be defined for the other ports, so shouldn't be added to
the common include/wx/chkconf.h but to this file instead.
the common `include/wx/chkconf.h` but to this file instead.
c) configure.in
- `configure.in`
Here you need to add `DEFAULT_wxUSE_FOO` define. It should be added in the
block beginning after WX_ARG_CACHE_INIT line and should default to "no" for
"if DEBUG_CONFIGURE = 1" branch (this is used for absolutely minimal builds)
and the same as default value in setup_inc.h in the "else" branch.
block beginning after `WX_ARG_CACHE_INIT` line and should default to "no" for
`if DEBUG_CONFIGURE = 1` branch (this is used for absolutely minimal builds)
and the same as default value in `setup_inc.h` in the "else" branch.
You also need to add a WX_ARG_ENABLE (or, if new functionality can be
reasonably described as support for a 3rd party library, WX_ARG_WITH)
line togetherw with all the existing WX_ARG_ENABLEs.
You also need to add a `WX_ARG_ENABLE` (or, if new functionality can be
reasonably described as support for a 3rd party library, `WX_ARG_WITH`)
line together with all the existing `WX_ARG_ENABLE`s.
If you have a sample/foo which should be only built when `wxUSE_FOO==1`,
then only add it to the SAMPLES_SUBDIRS if `wxUSE_FOO=yes` in configure.
then only add it to the `SAMPLES_SUBDIRS` if `wxUSE_FOO=yes` in configure.
d) build/cmake/options.cmake
- `build/cmake/options.cmake`
To include the option in CMake, add a new line in the appropriate
section of options.cmake.
section of `options.cmake`.
wx_option(wxUSE_FOO "enable FOO")
wx_option(wxUSE_FOO "enable FOO")
As an optional third parameter you may specify `OFF` when the option
should be disabled by default.
e) docs/doxygen/mainpages/const_wxusedef.h
- `docs/doxygen/mainpages/const_wxusedef.h`
Add a brief description of the new constant.

142
docs/contributing/how-to-release.md
View File

@@ -5,6 +5,7 @@ Creating a new release requires a few things before getting started:
* Linux (or another Unix but GNU tar is required).
* Windows 7+ with HTML Help Workshop, and Inno Setup installed.
* 7-Zip, Doxygen 1.8.8, and GraphViz installed on both machines.
* [Bakefile 0.2.12](https://bakefile.org/) installed on the linux machine.
Unless mentioned otherwise, all steps should be run on Linux or OSX so that the
repository export used for the release is primarily using LF line endings. Files
@@ -46,17 +47,34 @@ and then run it using the new DLLs.
## Pre-Release Steps
1. Perform the following steps. You can run `build/tools/pre-release.sh` to do
the straightforward changes like updating the date and version number
automatically, but please also review and update the contents of the README
and announcement text.
* Update `docs/readme.txt`: version needs to be changed, content updated.
* Update `docs/release.md`: also version and reset SHA-1 sums to zeroes.
* Put a date on the release line in `docs/changes.txt`.
* Update the date in the manual (`docs/doxygen/mainpages/manual.h`).
* Update the release announcement post in `docs/publicity/announce.txt`.
Perform the following steps. You can run `build/tools/pre-release.sh` to do
the straightforward changes like updating the dates and checksums
automatically, but please also review and update the contents of the README
and announcement text.
2. Commit the changes and tag the release using your GPG key:
The Post-Release step of the previous release will have updated
the micro version of this release. If this release represents a major
or minor release, these changes will have to be performed manually at
this point.
Note that the best order depends on the release being prepared: for a
development release, `docs/publicity/announce.txt` contains the list of the
major changes since the last stable release and should be updated first, as
this part of it can then be copied verbatim to the corresponding section of
the README file. For the stable releases, it's probably more convenient to
update the README with the details of the changes first.
Here is the list of the files, for reference:
* Update `docs/readme.txt`: version needs to be changed, content updated.
* Update `docs/release.md`: also version and reset SHA-1 sums to zeroes.
* Update `docs/changes.txt`: put the date on the release line and copy the
actual changes from Git notes as instructed in the file.
* Update the date in the manual (`docs/doxygen/mainpages/manual.h`).
* Update the release announcement post in `docs/publicity/announce.txt`.
* Update `docs/msw/binaries.md`: at least the version, but possibly also
the list of supported compilers.
Commit the changes and tag the release using your GPG key:
git tag -s -m 'Tag X.Y.Z release' vX.Y.Z
@@ -112,20 +130,58 @@ Attach the following files to it:
wxWidgets-x.y.z-docs-html.zip
wxWidgets-x.y.z-headers.7z
Create https://docs.wxwidgets.org/x.y.z/ (ask Bryan to do it if not done yet).
## Update documentation
This requires being able to ssh to docs.wxwidgets.org, please ask Bryan if you
think you should be able to do it, but can't.
Once logged in, run `~/update-trunk-docs.sh` script to update files in
`public_html/trunk` directory, copy its contents to `public_html/x.y.z`, switch
any links, such as `3.1` to point to `x.y.z` by doing
$ cd ~/public_html
$ ln -sfn 3.y.z 3.y
and edit `~/public_html/index.html` to add the link to the new release to it.
If the docs must be generated from the tag itself, and not from master, note
that you need to apply the special commit which is always the tip of master
branch in `~/wxWidgets` git repository on this machine.
E.g. to create documentation for `v3.0.z` release:
$ cd ~/wxWidgets
$ git fetch --tags
$ git checkout -b my-tmp-branch v3.0.z
$ git cherry-pick master
$ vi docs/doxygen/Doxyfile
... edit HTML_OUTPUT to create files in ~/public_html/3.0.z
$ cd docs/doxygen
$ PATH="$HOME/doxygen/bin:$PATH" WX_SKIP_DOXYGEN_VERSION_CHECK=1 nice -n 15 ./regen.sh php
# Cleanup
$ git reset --hard master
$ git checkout master
$ git branch -d my-tmp-branch
Note that the docs web site currently uses Cloudflare for caching, which means
that it won't update for several hours after the change, unless you purge the
cache manually in the Cloudflare console (which requires an account).
## Announcement
Update https://www.wxwidgets.org:
* Update release information (at least `version` and `released`) in `_data/relases.yml`.
* Download information can then be updated by running `update_release_info.rb`.
This will update the asset information from GitHub.
* Update release information (at least `version` and `released`) in `_data/releases.yml`.
* Update the list of compilers used for making MSW binaries in
`downloads/index.md` if necessary (note that there is no need to update
anything else, the page will dynamically show the release files with the
specified prefixes).
* Add a news item. Usually a news item is enough but something
more can be called for for major releases
* Push the changes (or create the PR with them) to GitHub. Note that this will
trigger the site rebuild which will fail if the release statistics are not
available yet, so make sure to publish the release on GitHub first (or wait
an hour for the next scheduled site rebuild to happen).
Post `docs/publicity/announce.txt` at least to wx-announce@googlegroups.com and
to wx-users.
@@ -137,27 +193,39 @@ Submit to https://isocpp.org/blog/suggest (need to be logged in to do it).
For major releases, submit the announcement to https://slashdot.org/submission
## Version Updates
## Post-Release Steps
Trac: mark the milestone corresponding to the release as completed and add a
new version for it to allow reporting bugs against it and create the next
milestone (ask Vadim or Robin to do it or to get admin password).
* Trac: mark the milestone corresponding to the release as completed and
add a new version for it to allow reporting bugs against it and create the
next milestone (ask Vadim or Robin to do it or to get admin password).
Update the roadmap at https://trac.wxwidgets.org/wiki/Roadmap to at least
mention the new release there.
* Update the roadmap at https://trac.wxwidgets.org/wiki/Roadmap to at
least mention the new release there.
* Run `misc/scripts/inc_release` to increment micro version,
i.e. replace x.y.z with x.y.z+1.
* Update the C:R:A settings in `build/bakefiles/version.bkl` to C:R+1:A.
Then from the build/bakesfiles directory run
bakefile_gen
and from the root directory run
autoconf -B build/autoconf_prepend-include
* Restore the description of the Git notes use and create a skeleton section
for the next release in `docs/changes.txt`.
Run `misc/scripts/inc_release` to increment micro version, i.e. replace x.y.z
with x.y.z+1 (minor or major versions updates require manual intervention)
and rerun both `bakefile_gen` and `autoconf` afterwards to update the version
in the generated files too.
## MSW Visual Studio Official Builds
To build official x86 and x64 shared binaries the following are prerequisites:
- Visual Studio 2012, 2013, 2015
- Windows SDK 6.1, 7.1 (required for x64 builds for Visual Studio 2008, 2010)
- 7z (required for packaging the files)
- fciv (required for generating the checksums)
- Visual Studio 2008, 2010, 2012, 2013 and 2015
- Windows SDK 6.1, 7.1 (required for x64 builds for Visual Studio 2008, 2010)
- 7z (required for packaging the files)
- fciv (required for generating the checksums)
The VSxxxCOMNTOOLS environment variables are used to locate the tools required
for Visual Studio 2012, 2013 and 2015. There are no Microsoft defined variables
@@ -171,18 +239,22 @@ If either of these are blank they are set to the default install location.
To build binaries for a single compiler, open a command prompt (for Visual
Studio 2008 only an SDK 6.1 developer's command prompt must be used),
cd to the build\msw\tools\msvs folder and run the batch file 'buildofficial'
cd to the build\tools\msvs folder and run the batch file 'officialbuild'
with the vcXXX version number:
Visual Studio 2008 vc90
Visual Studio 2010 vc100
Visual Studio 2012 vc110
Visual Studio 2014 vc120
Visual Studio 2015 vc140
Visual Studio 2008 vc90
Visual Studio 2010 vc100
Visual Studio 2012 vc110
Visual Studio 2014 vc120
Visual Studio 2015 vc14x
The Visual Studio 2015, 2017 and 2019 are binary compatible, allowing the
vc14x binary to be used with any of them.
This will build all of the x86 and x64 binaries for the selected compiler version,
package them in 7z files and calculate the checksums. The 7z files and the
checksums are output to the build\msw\packages folder.
All of the compiler packages can be built at the same time by executing the
build\msw\tools\buildall.bat file (including Visual Studio 2000).
build\tools\msvs\buildall.bat file from a command prompt. Each build will be
launched in its own shell.

7
docs/doxygen/Doxyfile
View File

@@ -6,7 +6,7 @@
DOXYFILE_ENCODING = UTF-8
PROJECT_NAME = wxWidgets
PROJECT_NUMBER = 3.1.3
PROJECT_NUMBER = 3.1.5
PROJECT_BRIEF =
PROJECT_LOGO = logo.png
OUTPUT_DIRECTORY = out
@@ -214,7 +214,7 @@ ALIASES += rightCurly="}"
# For indicating a sample location
ALIASES += sampledir{1}="@e Location: @c samples/\1 subdirectory of your wxWidgets installation or https://github.com/wxWidgets/wxWidgets/tree/master/samples/\1"
# For refering to the corresponding sample in a class document or a overview
# For referring to the corresponding sample in a class document or a overview
# Usually placed in the queue of @see
ALIASES += sample{1}="\ref page_samples_\1"
@@ -384,6 +384,7 @@ GENERATE_CHI = NO
CHM_INDEX_ENCODING =
BINARY_TOC = NO
TOC_EXPAND = NO
TOC_INCLUDE_HEADINGS = 3
#---------------------------------------------------------------------------
@@ -534,7 +535,7 @@ SKIP_FUNCTION_MACROS = YES
#---------------------------------------------------------------------------
TAGFILES =
GENERATE_TAGFILE =
GENERATE_TAGFILE = $(GENERATE_TAGFILE)
ALLEXTERNALS = NO
EXTERNAL_GROUPS = YES
EXTERNAL_PAGES = YES

2
docs/doxygen/groups/class_help.h
View File

@@ -10,7 +10,7 @@
@defgroup group_class_help Help
@ingroup group_class
Classes for loading and displaying help manuals or help informations in general.
Classes for loading and displaying help manuals or help information in general.
*/

2
docs/doxygen/groups/class_webview.h
View File

@@ -10,7 +10,7 @@
@defgroup group_class_webview WebView
@ingroup group_class
The wxWebView library is a set of classes for viewing complex web documents and
The wxWebView library is a set of classes for viewing complex web documents and
for internet browsing. It is built around a series of backends, and exposes
common functions for them.

2
docs/doxygen/groups/funcmacro_atomic.h
View File

@@ -14,7 +14,7 @@ When using multi-threaded applications, it is often required to access or
modify memory which is shared between threads. Atomic integer and pointer
operations are an efficient way to handle this issue (another, less efficient,
way is to use a wxMutex or wxCriticalSection). A native implementation exists
for Windows, Linux, Solaris and OS X; for others, a wxCriticalSection is
for Windows, Linux, Solaris and macOS; for others, a wxCriticalSection is
used to protect the data.
One particular application is reference counting (used by so-called

2
docs/doxygen/groups/funcmacro_locale.h
View File

@@ -19,7 +19,7 @@ and keep in mind that the wxWidgets function takes as last parameter the
locale which should be internally used for locale-dependent operations.
Last, note that when the @c wxHAS_XLOCALE_SUPPORT symbol is not defined,
then wxWidgets will provide implementations of these functions itself
then wxWidgets will provide implementations of these functions itself
and that they are not granted to be thread-safe (and they will work only with the
C locale; see @ref xlocale_avail).

BIN
docs/doxygen/images/appear-propertygrid-msw.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 1.2 KiB

After

Width:  |  Height:  |  Size: 4.4 KiB

BIN
docs/doxygen/images/overview_highdpi_text_144.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 21 KiB

BIN
docs/doxygen/images/overview_highdpi_text_72.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 17 KiB

4
docs/doxygen/mainpages/cat_classes.h
View File

@@ -126,7 +126,7 @@ Controls that are not static can have wxValidator associated with them.
mode
@li wxNotebook: A notebook class
@li wxOwnerDrawnComboBox: A combobox with owner-drawn list items
@li wxPropertyGrid: A complex control to display hierachical, editable information
@li wxPropertyGrid: A complex control to display hierarchical, editable information
@li wxRadioBox: A group of radio buttons
@li wxRadioButton: A round button to be used with others in a mutually
exclusive way
@@ -667,6 +667,7 @@ Related overview: @ref overview_file
@li wxFile: Low-level file input/output class.
@li wxFFile: Another low-level file input/output class.
@li wxTempFile: Class to safely replace an existing file
@li wxTempFFile: Another class to safely replace an existing file
@li wxTextFile: Class for working with text files as with arrays of lines
@li wxStandardPaths: Paths for standard directories
@li wxPathList: A class to help search multiple paths
@@ -702,6 +703,7 @@ Related overview: @ref overview_stream
@li wxFFileInputStream: Another file input stream class
@li wxFFileOutputStream: Another file output stream class
@li wxTempFileOutputStream: Stream to safely replace an existing file
@li wxTempFFileOutputStream: Another stream to safely replace an existing file
@li wxStringInputStream: String input stream class
@li wxStringOutputStream: String output stream class
@li wxLZMAInputStream: LZMA decompression stream class

69
docs/doxygen/mainpages/const_cpp.h
View File

@@ -39,9 +39,9 @@ Notice that for compatibility reasons, this symbol is defined for console
applications under Windows as well, but it should only be used in the GUI code
while <tt>__WINDOWS__</tt> should be used for the platform tests.}
@itemdef{__WXOSX__, OS X GUI using any Apple widget framework (AppKit or UIKit)}
@itemdef{__WXOSX_IPHONE__, OS X iPhone (UIKit)}
@itemdef{__WXOSX_COCOA__, OS X using Cocoa (AppKit)}
@itemdef{__WXOSX_MAC__, OS X (Cocoa)}
@itemdef{__WXOSX_IPHONE__, iPhone (UIKit)}
@itemdef{__WXOSX_COCOA__, macOS using Cocoa (AppKit)}
@itemdef{__WXOSX_MAC__, macOS (Cocoa)}
@itemdef{__WXPM__, OS/2 native Presentation Manager (not used any longer).}
@itemdef{__WXSTUBS__, Stubbed version ('template' wxWin implementation)}
@itemdef{__WXXT__, Xt; mutually exclusive with WX_MOTIF, not implemented in wxWidgets 2.x}
@@ -59,7 +59,7 @@ versions: Cocoa for the desktop and a very early iPhone port. To summarize:
<tt>__WXOSX_MAC__</tt>.
@li If you want to test for wxOSX on the iPhone, use
<tt>__WXOSX_IPHONE__</tt>.
@li If you want to test for any port under OS X, including, for
@li If you want to test for any port under macOS, including, for
example, wxGTK and also wxBase, use <tt>__DARWIN__</tt> (see below).
The convention is to use the <tt>__WX</tt> prefix for these
@@ -120,7 +120,7 @@ compiler used.
@beginDefList
@itemdef{__BORLANDC__, Borland C++. The value of the macro corresponds
to the compiler version: 500 is 5.0.}
to the compiler version: 500 is 5.0 (not used any more).}
@itemdef{__DIGITALMARS__, Digital Mars (not used any more).}
@itemdef{__GNUG__, Gnu C++ on any platform, see also wxCHECK_GCC_VERSION}
@itemdef{__GNUWIN32__, Gnu-Win32 compiler, see also wxCHECK_W32API_VERSION}
@@ -171,6 +171,8 @@ Currently the following symbols exist:
wxBitmapToggleButton class is available in addition to wxToggleButton.}
@itemdef{wxHAS_CONFIG_TEMPLATE_RW, Defined if the currently used compiler
supports template Read() and Write() methods in wxConfig.}
@itemdef{wxHAS_MEMBER_DEFAULT, Defined if the currently used compiler supports
C++11 @c =default.}
@itemdef{wxHAS_LARGE_FILES, Defined if wxFile supports files more than 4GB in
size (notice that you must include @c wx/filefn.h before testing for this
symbol).}
@@ -185,7 +187,11 @@ Currently the following symbols exist:
decide whether some function should be overloaded for both
<code>long</code> and <code>long long</code> types.}
@itemdef{wxHAS_MULTIPLE_FILEDLG_FILTERS, Defined if wxFileDialog supports multiple ('|'-separated) filters.}
@itemdef{wxHAS_NATIVE_ANIMATIONCTRL, Defined if native wxAnimationCtrl class is being used (this symbol only exists in wxWidgets 3.1.4 and later).}
@itemdef{wxHAS_NATIVE_DATAVIEWCTRL, Defined if native wxDataViewCtrl class is being used (this symbol only exists in wxWidgets 3.1.4 and later).}
@itemdef{wxHAS_NATIVE_WINDOW, Defined if wxNativeWindow class is available.}
@itemdef{wxHAS_NOEXCEPT, Defined if the currently used compiler supports C++11 @c noexcept. @c wxNOEXCEPT is defined as this keyword in this case, and as nothing otherwise.}
@itemdef{wxHAS_NULLPTR_T, Defined if the currently used compiler supports C++11 @c nullptr.}
@itemdef{wxHAS_IMAGES_IN_RESOURCES, Defined if <a href="http://en.wikipedia.org/wiki/Resource_(Windows)">
Windows resource files</a> or OS/2 resource files are available on the current platform.}
@itemdef{wxHAS_POWER_EVENTS, Defined if wxPowerEvent are ever generated on the current platform.}
@@ -208,16 +214,47 @@ Currently the following symbols exist:
@section page_cppconst_msvc_setup_h Library Selection for MSVC
@section page_cppconst_msvc_setup_h MSVC-specific Symbols
Microsoft Visual C++ users may use the special @c wx/setup.h file for this
compiler in @c include/msvc subdirectory. This file implicitly links in all the
wxWidgets libraries using MSVC-specific pragmas which usually is much more
convenient than manually specifying the libraries list in all of the project
configurations. However sometimes linking with all the libraries is not
desirable, for example because some of them were not built and this is where
the symbols in this section can be helpful: defining them allows to not link
with the corresponding library. The following symbols are honoured:
configurations.
By default, the pragmas used in this file to actually link with wxWidgets
libraries suppose that the libraries are located in @c vc_lib or @c vc_dll
directory which is used by default. However when using multiple MSVC versions,
or when using the @ref plat_msw_binaries "official binaries", the libraries are
in a directory containing the compiler version number, e.g. @c vc140_dll. To
make linking work in this case, you must predefine @c wxMSVC_VERSION as @c
vc140 <em>before</em> include @c wx/setup.h file, i.e. typically in the MSVS
project options. Alternatively, you can predefine @c wxMSVC_VERSION_AUTO symbol
(without any value), which means that the appropriate compiler version should
be used automatically, e.g. "vc100" for VC 10 (MSVS 2010), "vc140" for VC 14
(MSVS 2015) etc. Additionally, VC 14 is a special case as it has 3 minor
versions: VC 14.0, 14.1 and 14.2, corresponding to MSVS 2015, 2017 and 2019;
that are ABI-compatible with each other. Due to this, it can also be useful to
reuse the single build of wxWidgets with all versions of the compiler and this
is supported if @c wxMSVC_VERSION_ABI_COMPAT is defined: the compiler prefix
"vc14x" is used in this case.
If the makefiles have been used to build the libraries from source and the @c CFG
variable has been set to specify a different output path for that particular
configuration of build then the @c wxCFG preprocessor symbol should be set in
the project that uses wxWidgets to the same value as the @c CFG variable in
order for the correct @c wx/setup.h file to automatically be included for that
configuration.
@subsection page_cppconst_msvc_setup_h_no_libs Library Selection for MSVC
As explained above, MSVC users don't need to explicitly specify wxWidgets
libraries to link with, as this is done by @c wx/setup.h. However sometimes
linking with all the libraries, as is done by default, is not desirable, for
example because some of them were not built and this is where the symbols in
this section can be helpful: defining them allows to not link with the
corresponding library. The following symbols are honoured:
- wxNO_AUI_LIB
- wxNO_HTML_LIB
@@ -238,13 +275,6 @@ with the corresponding library. The following symbols are honoured:
Notice that the base library is always included and the core is always included
for the GUI applications (i.e. those which don't define @c wxUSE_GUI as 0).
If the makefiles have been used to build the libraries from source and the @c CFG
variable has been set to specify a different output path for that particular
configuration of build then the @c wxCFG preprocessor symbol should be set in
the project that uses wxWidgets to the same value as the @c CFG variable in
order for the correct @c wx/setup.h file to automatically be included for that
configuration.
@section page_cppconst_compatibility Compatibility Macros
@@ -345,6 +375,11 @@ more details.
set to 1 for compatibility reasons as @c -DwxNO_UNSAFE_WXSTRING_CONV
can be used only compiling the application code, without rebuilding the
library. Support for this option appeared in wxWidgets 3.1.1.}
@itemdef{wxNO_IMPLICIT_WXSTRING_ENCODING,
this symbol is not defined by wxWidgets itself, but can be defined by
the applications using the library to disable implicit
conversions from and to <tt>const char*</tt> in wxString class.
Support for this option appeared in wxWidgets 3.1.4.}
@itemdef{WXMAKINGDLL_XXX,
used internally and defined when building the
library @c XXX as a DLL; when a monolithic wxWidgets build is used only a

2
docs/doxygen/mainpages/const_stdevtid.h
View File

@@ -29,7 +29,7 @@ identifiers are all in the range between @c wxID_LOWEST and
@c wxID_HIGHEST and, accordingly, the user code should avoid defining its
own constants in this range (e.g. by using wxNewId()).
Refer to @ref page_stockitems "the list of stock items" for the subset of standard IDs
Refer to @ref page_stockitems "the list of stock items" for the subset of standard IDs
which are stock IDs as well.
*/

19
docs/doxygen/mainpages/const_wxusedef.h
View File

@@ -35,11 +35,11 @@ library:
@itemdef{wxUSE_STD_IOSTREAM, Standard C++ classes are used instead of or in
addition to wx stream classes.}
@itemdef{wxUSE_UNICODE, Compiled with Unicode support (default in wxWidgets
3.0, non-Unicode build will be deprecated in the future).}
3.0, non-Unicode build is deprecated and will be removed in the future).}
@itemdef{wxUSE_UNICODE_WCHAR, wxString uses wchar_t buffer for internal storage
(default under MSW).}
@itemdef{wxUSE_UNICODE_UTF8, wxString uses UTF-8 for internal storage (default
under Unix and Mac systems).}
(default).}
@itemdef{wxUSE_UNICODE_UTF8, wxString uses UTF-8 for internal storage (mostly
useful for wxGTK where UTF-8 is used by the underlying toolkit).}
@itemdef{wxUSE_UTF8_LOCALE_ONLY, Library supports running only under UTF-8 (and
C) locale. This eliminates the code necessary for conversions from the
other locales and reduces the library size; useful for embedded systems.}
@@ -146,7 +146,6 @@ library:
@itemdef{wxUSE_IMAGE, Use wxImage and related classes.}
@itemdef{wxUSE_IMAGLIST, Use wxImageList class.}
@itemdef{wxUSE_INTL, Use wxLocale and related classes.}
@itemdef{wxUSE_IOSTREAMH, Use header "iostream.h" instead of "iostream".}
@itemdef{wxUSE_IPC, Use interprocess communication classes.}
@itemdef{wxUSE_IPV6, Use experimental wxIPV6address and related classes.}
@itemdef{wxUSE_JOYSTICK, Use wxJoystick class.}
@@ -170,12 +169,14 @@ library:
@itemdef{wxUSE_MDI_ARCHITECTURE, Use MDI-based document-view classes.}
@itemdef{wxUSE_MEDIACTRL, Use wxMediaCtrl.}
@itemdef{wxUSE_MEMORY_TRACING, Use wxWidgets memory leak detection, not recommended if using another memory debugging tool.}
@itemdef{wxUSE_MENUS, Use wxMenu and related classes.}
@itemdef{wxUSE_MENUS, Use wxMenu and wxMenuItem.}
@itemdef{wxUSE_MENUBAR, Use wxMenubar.}
@itemdef{wxUSE_METAFILE, Use wxMetaFile and related classes.}
@itemdef{wxUSE_MIMETYPE, Use wxFileType class.}
@itemdef{wxUSE_MINIFRAME, Use wxMiniFrame class.}
@itemdef{wxUSE_MOUSEWHEEL, Support mouse wheel events.}
@itemdef{wxUSE_MSGDLG, Use wxMessageDialog class and wxMessageBox function.}
@itemdef{wxUSE_NATIVE_DATAVIEWCTRL, Use native wxDataViewCtrl class (this option is new since wxWidgets 3.1.4).}
@itemdef{wxUSE_NATIVE_STATUSBAR, Use native wxStatusBar class.}
@itemdef{wxUSE_NOTEBOOK, Use wxNotebook and related classes.}
@itemdef{wxUSE_NUMBERDLG, Use wxNumberEntryDialog class.}
@@ -319,12 +320,13 @@ library:
@itemdef{wxUSE_ACCESSIBILITY, Enable accessibility support}
@itemdef{wxUSE_ACTIVEX, Use wxActiveXContainer and related classes.}
@itemdef{wxUSE_COMBOCTRL_POPUP_ANIMATION, See wx/msw/combo.h file.}
@itemdef{wxUSE_COMCTL32_SAFELY, See src/msw/treectrl.cpp file.}
@itemdef{wxUSE_COMMON_DIALOGS, Enable use of windows common dialogs from header commdlg.h; example PRINTDLG.}
@itemdef{wxUSE_CRASHREPORT, Use wxCrashReport class.}
@itemdef{wxUSE_DATEPICKCTRL_GENERIC, Use generic wxDatePickerCtrl implementation in addition to the native one.}
@itemdef{wxUSE_DC_CACHEING, cache temporary wxDC objects.}
@itemdef{wxUSE_DDE_FOR_IPC, See wx/ipc.h file.}
@itemdef{wxUSE_DPI_AWARE_MANIFEST, Set the DPI awareness of the application
(0=none, 1=system, 2=per-monitor. Used by CMake and when wxUSE_RC_MANIFEST is enabled.}
@itemdef{wxUSE_ENH_METAFILE, Use wxEnhMetaFile.}
@itemdef{wxUSE_HOTKEY, Use wxWindow::RegisterHotKey() and wxWindow::UnregisterHotKey}
@itemdef{wxUSE_INKEDIT, Use InkEdit library. Related to Tablet PCs.}
@@ -349,6 +351,9 @@ compilers. See also wxUSE_NO_MANIFEST.}
@itemdef{wxUSE_WIN_METAFILES_ALWAYS, Use wxMetaFile even when wxUSE_ENH_METAFILE=1.}
@itemdef{wxUSE_WINRT, Enable WinRT support.}
@itemdef{wxUSE_WXDIB, Use wxDIB class.}
@itemdef{wxUSE_WINSOCK2, Include @c <winsock2.h> instead of @c <winsock.h>.
Turned on automatically if wxUSE_IPV6 is on (this option is new since
wxWidgets 3.1.3).}
@endDefList

4
docs/doxygen/mainpages/copyright.h
View File

@@ -11,7 +11,7 @@
@section section_copyright wxWidgets Copyrights and Licenses
Copyright (c) 1992-2018 Julian Smart, Vadim Zeitlin, Stefan Csomor, Robert
Copyright (c) 1992-2020 Julian Smart, Vadim Zeitlin, Stefan Csomor, Robert
Roebling, and other members of the wxWidgets team, please see the
acknowledgements section below.
@@ -103,7 +103,7 @@ without express or implied warranty.
@verbinclude "lgpl.txt"
@page page_copyright_xserver The Open Group and DEC License
@verbinclude "xserver.txt"
*/

21
docs/doxygen/mainpages/devtips.h
View File

@@ -28,10 +28,6 @@ following section before any other includes:
// For compilers that support precompilation, includes "wx.h".
#include <wx/wxprec.h>
#ifdef __BORLANDC__
# pragma hdrstop
#endif
#ifndef WX_PRECOMP
// Include your minimal set of headers here, or wx.h
# include <wx/wx.h>
@@ -44,8 +40,8 @@ The file @c "wx/wxprec.h" includes @c "wx/wx.h". Although this incantation may
seem quirky, it is in fact the end result of a lot of experimentation, and
several Windows compilers to use precompilation which is largely automatic for
compilers with necessary support. Currently it is used for Visual C++
(including embedded Visual C++), Borland C++ and newer versions of GCC. Some
compilers might need extra work from the application developer to set the build
(including embedded Visual C++) and newer versions of GCC. Some compilers
might need extra work from the application developer to set the build
environment up as necessary for the support.
@@ -110,11 +106,10 @@ and this must not be changed.
On Microsoft Windows, wxWidgets has a different set of makefiles for each
compiler, because each compiler's @c 'make' tool is slightly different. Popular
Windows compilers that we cater for, and the corresponding makefile extensions,
include: Microsoft Visual C++ (.vc), Borland C++ (.bcc) and MinGW/Cygwin
(.gcc). Makefiles are provided for the wxWidgets library itself, samples,
demos, and utilities.
include: Microsoft Visual C++ (.vc) and MinGW/Cygwin (.gcc). Makefiles are
provided for the wxWidgets library itself, samples, demos, and utilities.
On Linux and OS X, you use the @c 'configure' command to generate the
On Linux and macOS, you use the @c 'configure' command to generate the
necessary makefiles. You should also use this method when building with
MinGW/Cygwin on Windows.
@@ -127,7 +122,7 @@ On Windows using a compiler other than MinGW/Cygwin, you would build the
wxWidgets library from the @c "build/msw" directory which contains the relevant
makefiles.
On Windows using MinGW/Cygwin, and on Unix and OS X, you invoke
On Windows using MinGW/Cygwin, and on Unix and macOS, you invoke
'configure' (found in the top-level of the wxWidgets source hierarchy), from
within a suitable empty directory for containing makefiles, object files and
libraries.
@@ -136,7 +131,7 @@ For details on using makefiles, configure, and project files, please see
@c "docs/xxx/install.txt" in your distribution, where @c "xxx" is the platform
of interest, such as @c msw, @c gtk, @c x11, @c mac.
All wxWidgets makefiles are generated using Bakefile <http://www.bakefile.org/>.
All wxWidgets makefiles are generated using Bakefile <https://www.bakefile.org/>.
wxWidgets also provides (in the @c "build/bakefiles/wxpresets" folder) the
wxWidgets bakefile presets. These files allow you to create bakefiles for your
own wxWidgets-based applications very easily.
@@ -259,7 +254,7 @@ its own run-time type information system, implemented using macros.
@subsection page_multiplatform_cpp_precompiledheaders Precompiled Headers
Some compilers, such as Borland C++ and Microsoft C++, support precompiled
Some compilers, such as Microsoft C++, support precompiled
headers. This can save a great deal of compiling time. The recommended approach
is to precompile @c "wx.h", using this precompiled header for compiling both
wxWidgets itself and any wxWidgets applications. For Windows compilers, two

24
docs/doxygen/mainpages/introduction.h
View File

@@ -41,8 +41,9 @@ Compared to the other similar libraries, wxWidgets is:
3. Open source and free for use in both open source and commercial projects.
wxWidgets provides a simple, easy to learn, yet very rich API. It is also
mature and stable, and the applications written using wxWidgets 2.0
wxWidgets provides a simple, easy to learn, yet very rich API, while also
proposing a simple way to define application UI in the external XML files.
It is also mature and stable, and the applications written using wxWidgets 2.0
pre-releases almost 20 years ago can still be built today with wxWidgets 3
almost unchanged. wxWidgets has a large, active and friendly community of
people, including both the users and developers of the library. It is also
@@ -59,7 +60,7 @@ paragraphs, but here are some of the benefits:
@li Extensive documentation (almost 200,000 lines of it).
@li Straightforward API.
@li Simple but powerful layout system.
@li Run-time loadable or compile-time embeddable resources.
@li Run-time loadable or compile-time embeddable resources for UI definition.
@li Flexible event system.
@li All the usual and quite a few of more rare GUI controls.
@li And also all the standard dialogs.
@@ -79,7 +80,7 @@ wxWidgets first-tier "ports", ie implementations of wxWidgets API, are:
@li wxMSW: This is the native port for Microsoft Windows systems (from Windows
XP up to Windows 10), either 32 or 64 bits. The primarily supported compilers
are Microsoft Visual C++ (versions 2003 up to 2017 are supported, at least 2005
are Microsoft Visual C++ (versions 2003 up to 2019 are supported, at least 2005
is recommended) and GNU g++ (either from the traditional MinGW, TDM-GCC or
MinGW-w64 distributions).
@@ -90,12 +91,12 @@ NetBSD, Solaris, AIX, ...) and require GTK+ 2.6 or later or GTK+ 3.x. The
primary supported compiler is GNU g++.
@li wxOSX/Cocoa: This is the native port for Apple computers. wxOSX/Cocoa
supports 32 or 64 bit Intel Macs running OS X 10.7 or later. The port can be
supports 32 or 64 bit Intel Macs running macOS 10.10 or later. The port can be
built either with g++ or clang.
Other platforms (e.g. iOS - with a minimum requirement of iOS 9), compilers (Borland C++
under Windows, Sun CC, HP-UX aCC, IBM xlC or SGI mipsPro under Unix) and ports (
wxQT, wxGTK1, wxX11, wxDFB...) are also supported but to a lesser extent.
Other platforms (e.g. iOS - with a minimum requirement of iOS 13), compilers
(Sun CC, HP-UX aCC, IBM xlC or SGI mipsPro under Unix) and ports (wxQT, wxGTK1,
wxX11, wxDFB...) are also supported but to a lesser extent.
Please see the @subpage page_port "platform details page" for more information.
There are no CPU speed requirements but the faster (and more) CPU(s) you have,
@@ -110,13 +111,12 @@ configurations but at least 1GB and possibly more is required.
@section page_introduction_where Where to get wxWidgets and support for it
The download links can be found at https://www.wxwidgets.org. The primary
download location is https://github.com/wxWidgets/wxWidgets/releases/latest.
The download links can be found at https://www.wxwidgets.org/downloads/.
Additionally, the latest version can always be retrieved from our version
control system using Git (https://github.com/wxWidgets/wxWidgets).
wxWidgets documentation that you are reading is also available online at
https://docs.wxwidgets.org/trunk/ and please also visit our wiki at
The latest version of wxWidgets documentation that you are reading is available
online at https://docs.wxwidgets.org/trunk/ and please also see
https://wiki.wxwidgets.org/ for user-contributed contents.
And if you have any questions, you can join wxWidgets community using

2
docs/doxygen/mainpages/manual.h
View File

@@ -14,7 +14,7 @@
@author Julian Smart, Vadim Zeitlin, Robin Dunn, Stefan Csomor,
Bryan Petty, Francesco Montorsi, Robert Roebling et al
@date December 10, 2018
@date July 22, 2020
Welcome to wxWidgets, a stable and powerful open source framework for
developing native cross-platform GUI applications in C++!

104
docs/doxygen/mainpages/platdetails.h
View File

@@ -23,45 +23,36 @@ platforms and ports.
@section page_port_wxgtk wxGTK
wxGTK is a port of wxWidgets using the GTK+ library. It makes use of GTK+'s
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.
needed.
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:
You will need GTK+ 2.6 or higher which is available from:
https://www.gtk.org
http://www.gtk.org
The newer version of GTK+ you use, the more native widgets and features will be
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
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
In order to configure wxWidgets to compile wxGTK you will need to 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.
GTK 3 is the default starting with wxWidgets 3.1.4.
Use @c configure option @c \--with-gtk=2 to use GTK 2.
@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.
wxOSX/Cocoa is the port of wxWidgets for the macOS platform. It requires
a minimum SDK 10.11, Xcode 7.2.1 or greater (runs under 10.10.5 and higher),
and fully supports amd64 as well ARM builds and deploying under 10.10.
@subpage plat_osx_install "Build and Install Instructions"
@@ -82,16 +73,12 @@ In order to configure wxWidgets to compile wxX11 you will need to type:
@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.
wxMotif is a port of wxWidgets for X11 systems using Motif libraries.
It is no longer actively maintained and by now rather obsolete.
@subpage plat_motif_install "Build Instructions"
@@ -102,9 +89,9 @@ and candy of newer interfaces like GTK.
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.
This port can be compiled with several compilers including Microsoft
VC++ 2003 or later, MinGW, Cygwin as well as cross-compilation with a
Linux-hosted MinGW tool chain.
@subpage plat_msw_install "Build and Install Instructions"
@@ -127,45 +114,6 @@ 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.
@@ -189,13 +137,13 @@ 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
- wxMSW port uses Win32 API: see MSDN docs at https://docs.microsoft.com/en-us/windows/win32/controls/window-controls
- wxGTK port uses GTK and other lower-level libraries; see
- GTK docs at https://developer.gnome.org/gtk/
- GDK docs at https://library.gnome.org/devel/gdk/
- GLib docs at https://library.gnome.org/devel/glib/
- GObject docs at https://library.gnome.org/devel/gobject/
- Pango docs at https://library.gnome.org/devel/pango/
- wxOSX port uses the Cocoa API: see Cocoa docs at https://developer.apple.com/cocoa
*/

21
docs/doxygen/mainpages/samples.h
View File

@@ -307,23 +307,6 @@ wxProcess::Exists().
@sampledir{exec}
@section page_samples_flash Flash Sample
The flash sample demonstrates embedding of Adobe Flash into a wxWidgets
program. Currently it only works under Windows as it uses the Flash ActiveX
control to achieve this but we hope to be able to extend it to also work under
other platforms in the future. The sample also currently requires Microsoft
Visual C++ compiler as it uses COM support extensions specific to this
compiler.
The sample comes with 2 Flash files (SWF), showing a simple Flash animation
which can be controlled using the "Play", "Stop" and "Back"/"Forward" buttons
in the sample as well as a Flash form which shows how Flash and wxWidgets
program can exchange data: calling "GetText" function without arguments returns
the text of the text control defined inside Flash and calling "SetText" with an
argument sets the control contents to the given string. Finally clicking on the
button generates an event which is caught by the C++ program.
@section page_samples_font Font Sample
The font sample demonstrates wxFont,
@@ -669,7 +652,7 @@ first argument of @c save, @c load or @c delete, followed by the "service" and
"user" arguments as used by wxSecretStore methods. After storing some password,
you can check that it can be retrieved later and also that it can be seen in
the OS-provided password manager (e.g. credential manager under MSW or keychain
utility under OS X).
utility under macOS).
@sampledir{secretstore}
@@ -914,7 +897,7 @@ control.
The wxWebView sample demonstarates the various capabilities of the wxWebView
control. It is set up as a simple single window web browser, but with support
for many of the more complex wxWebView features, including browsing through
for many of the more complex wxWebView features, including browsing through
archives.
@sampledir{webview}

1
docs/doxygen/mainpages/topics.h
View File

@@ -99,5 +99,6 @@ topics related to building applications with wxWidgets.
@li @subpage overview_windowdeletion
@li @subpage overview_envvars
@li @subpage overview_customwidgets
@li @subpage overview_high_dpi
*/

5
docs/doxygen/mainpages/translations.h
View File

@@ -466,11 +466,6 @@ Here are the steps you should follow:
-# Send the finished translation to <a href="mailto:vadim@wxwidgets.org">Vadim Zeitlin</a>
and it will be added to the next wxWidgets release or snapshot.
In addition, please consider subscribing to the very low volume
<a href="https://www.wxwidgets.org/support/mailing-lists/">
wxWidgets translators mailing list</a> on which the news especially important
for the translators are announced.
Thank you in advance for your help!
*/

2
docs/doxygen/mainpages/utilities.h
View File

@@ -13,7 +13,7 @@
In addition to the wxWidgets libraries (see @ref page_libs), some utilities
are available to the users in the @c utils hierarchy (even if some of them are
explicitly conceived for wxWidgets maintainance and will probably be of
explicitly conceived for wxWidgets maintenance and will probably be of
little use to others).
Please note that these utilities only represent the utilities developed and

2
docs/doxygen/overviews/backwardcompatibility.h
View File

@@ -108,7 +108,7 @@ compatible but can also be binary compatible.
Binary compatibility makes it possible to get the maximum benefit from using
shared libraries, also known as dynamic link libraries (DLLs) on Windows or
dynamic shared libraries on OS X.
dynamic shared libraries on macOS.
For example, suppose several applications are installed on a system requiring
wxWidgets 2.6.0, 2.6.1 and 2.6.2. Since 2.6.2 is backward compatible with the

2
docs/doxygen/overviews/bitmap.h
View File

@@ -82,7 +82,7 @@ XPM nor BMP formats are appropriate as they don't have support for alpha and
another format, typically PNG, should be used. wxWidgets provides a similar
helper for PNG bitmaps called wxBITMAP_PNG() that can be used to either load
PNG files embedded in resources (meaning either Windows resource section of the
executable file or OS X "Resource" subdirectory of the application bundle) or
executable file or macOS "Resource" subdirectory of the application bundle) or
arrays containing PNG data included into the program code itself.
@see @ref group_class_gdi

12
docs/doxygen/overviews/bookctrl.h
View File

@@ -41,12 +41,12 @@ The mapping consists of:
@beginTable
@row2col{ ::wxBookCtrl, wxChoicebook or wxNotebook }
@row2col{ @c wxEVT_COMMAND_BOOKCTRL_PAGE_CHANGED,
@c wxEVT_COMMAND_CHOICEBOOK_PAGE_CHANGED or
@c wxEVT_COMMAND_NOTEBOOK_PAGE_CHANGED }
@row2col{ @c wxEVT_COMMAND_BOOKCTRL_PAGE_CHANGING,
@c wxEVT_COMMAND_CHOICEBOOK_PAGE_CHANGING or
@c wxEVT_COMMAND_NOTEBOOK_PAGE_CHANGING }
@row2col{ @c wxEVT_BOOKCTRL_PAGE_CHANGED,
@c wxEVT_CHOICEBOOK_PAGE_CHANGED or
@c wxEVT_NOTEBOOK_PAGE_CHANGED }
@row2col{ @c wxEVT_BOOKCTRL_PAGE_CHANGING,
@c wxEVT_CHOICEBOOK_PAGE_CHANGING or
@c wxEVT_NOTEBOOK_PAGE_CHANGING }
@row2col{ @c EVT_BOOKCTRL_PAGE_CHANGED(id\, fn),
@c EVT_CHOICEBOOK_PAGE_CHANGED(id, fn) or
@c EVT_NOTEBOOK_PAGE_CHANGED(id, fn) }

10
docs/doxygen/overviews/cmake.md
View File

@@ -5,7 +5,7 @@ CMake Overview {#overview_cmake}
CMake allows building wxWidgets on various platforms with your preferred build
system.
Most linux distributions contain CMake as a package on Windows and OS X you can
Most linux distributions contain CMake as a package on Windows and macOS you can
download an installer at the [CMake Page](https://cmake.org).
Using the CMake GUI {#cmake_gui}
@@ -26,11 +26,11 @@ Using the CMake Command Line {#cmake_cli}
2. Change into the created folder
3. Run `cmake -G "Unix Makefiles" path_to_wxWidgets_root`
4. After that you can run `cmake --build .` to start the build process or
directly use your choosen build system.
directly use your chosen build system.
Run `cmake --help` to see a list of available generators on your platform.
These can than be specified using the -G command line option. On Windows it
is recommended to use Visual Studio and on OS X Xcode is recommended.
is recommended to use Visual Studio and on macOS Xcode is recommended.
Various build options can be specified using -D see
[available options](#cmake_options).
@@ -64,7 +64,7 @@ or specified via the -D command line option when running the cmake command.
Option Name | Type | Default | Description
------------------------- | ----- | ------- | ----------------------------
wxBUILD_SHARED | BOOL | ON | Build shared libraries
wxBUILD_SHARED | BOOL | ON | Build shared or static libraries
wxBUILD_TESTS | STRING | OFF | CONSOLE_ONLY, ALL or OFF
wxBUILD_SAMPLES | STRING | OFF | SOME, ALL or OFF
wxBUILD_DEMOS | BOOL | OFF | Build demo applications
@@ -122,5 +122,5 @@ Your *CMakeLists.txt* would look like this:
...
add_subdirectory(libs/wxWidgets)
add_executable(myapp myapp.cpp)
target_link_libraries(myapp net core base)
target_link_libraries(myapp wx::net wx::core wx::base)
~~~

2
docs/doxygen/overviews/customwidgets.h
View File

@@ -12,7 +12,7 @@
@tableofcontents
Typically combining the existing @ref group_class_ctrl controls in wxDialogs
and wxFrames is sufficient to fullfill any GUI design. Using the wxWidgets
and wxFrames is sufficient to fulfill any GUI design. Using the wxWidgets
standard controls makes your GUI looks native on all ports and is obviously
easier and faster.

2
docs/doxygen/overviews/datetime.h
View File

@@ -106,7 +106,7 @@ just @c wxDateTime::Now() + wxDateSpan::Month()).
@section overview_datetime_arithmetics Date Arithmetics
@section overview_datetime_arithmetics Date Arithmetic
Many different operations may be performed with the dates, however not all of
them make sense. For example, multiplying a date by a number is an invalid

2
docs/doxygen/overviews/debugging.h
View File

@@ -21,7 +21,7 @@ debugging. Both assertions and debug logging are also used by wxWidgets itself
so you may encounter them even if you don't use either of these features
yourself.
@see wxLog, @ref group_funcmacro_log, @ref group_funcmacro_debug
@see wxLog, @ref group_funcmacro_log, @ref group_funcmacro_debug

2
docs/doxygen/overviews/docview.h
View File

@@ -86,7 +86,7 @@ use Wx ':docview'; # import constants (optional)
@endcode
@endWxPerlOnly
@see @ref group_class_docview,
@see @ref group_class_docview,

114
docs/doxygen/overviews/eventhandling.h
View File

@@ -98,10 +98,11 @@ First define one or more <em>event handlers</em>. They
are just simple methods of the class that take as a parameter a
reference to an object of a wxEvent-derived class and have no return value (any
return information is passed via the argument, which is why it is non-const).
You also need to insert a macro
You also need to insert a line with the macro indicating that the class uses an
event table, like this:
@code
wxDECLARE_EVENT_TABLE()
wxDECLARE_EVENT_TABLE();
@endcode
somewhere in the class declaration. It doesn't matter where it appears but
@@ -132,7 +133,7 @@ private:
// obligation to do that; this one is an event handler too:
void DoTest(wxCommandEvent& event);
wxDECLARE_EVENT_TABLE()
wxDECLARE_EVENT_TABLE();
};
@endcode
@@ -224,7 +225,7 @@ global scope as with the event tables), call its Bind<>() method like this:
@code
MyFrame::MyFrame(...)
{
Bind(wxEVT_COMMAND_MENU_SELECTED, &MyFrame::OnExit, this, wxID_EXIT);
Bind(wxEVT_MENU, &MyFrame::OnExit, this, wxID_EXIT);
}
@endcode
@@ -323,7 +324,7 @@ MyFrameHandler myFrameHandler;
MyFrame::MyFrame()
{
Bind( wxEVT_COMMAND_MENU_SELECTED, &MyFrameHandler::OnFrameExit,
Bind( wxEVT_MENU, &MyFrameHandler::OnFrameExit,
&myFrameHandler, wxID_EXIT );
}
@endcode
@@ -345,7 +346,7 @@ void HandleExit( wxCommandEvent & )
MyFrame::MyFrame()
{
Bind( wxEVT_COMMAND_MENU_SELECTED, &HandleExit, wxID_EXIT );
Bind( wxEVT_MENU, &HandleExit, wxID_EXIT );
}
@endcode
@@ -366,7 +367,7 @@ MyFunctor myFunctor;
MyFrame::MyFrame()
{
Bind( wxEVT_COMMAND_MENU_SELECTED, myFunctor, wxID_EXIT );
Bind( wxEVT_MENU, myFunctor, wxID_EXIT );
}
@endcode
@@ -376,7 +377,7 @@ separate functor class:
@code
MyFrame::MyFrame()
{
Bind(wxEVT_COMMAND_MENU_SELECTED,
Bind(wxEVT_MENU,
[](wxCommandEvent&) {
// Do something useful
},
@@ -406,7 +407,7 @@ MyFrame::MyFrame()
{
function< void ( wxCommandEvent & ) > exitHandler( bind( &MyHandler::OnExit, &myHandler, _1 ));
Bind( wxEVT_COMMAND_MENU_SELECTED, exitHandler, wxID_EXIT );
Bind( wxEVT_MENU, exitHandler, wxID_EXIT );
}
@endcode
@@ -427,7 +428,7 @@ MyFrame::MyFrame()
function< void ( wxCommandEvent & ) > exitHandler(
bind( &MyHandler::OnExit, &myHandler, EXIT_FAILURE, _1, "Bye" ));
Bind( wxEVT_COMMAND_MENU_SELECTED, exitHandler, wxID_EXIT );
Bind( wxEVT_MENU, exitHandler, wxID_EXIT );
}
@endcode
@@ -614,7 +615,7 @@ custom event types.
Finally, you will need to generate and post your custom events.
Generation is as simple as instancing your custom event class and initializing
its internal fields.
For posting events to a certain event handler there are two possibilities:
For posting events to a certain event handler there are two possibilities:
using wxEvtHandler::AddPendingEvent or using wxEvtHandler::QueueEvent.
Basically you will need to use the latter when doing inter-thread communication;
when you use only the main thread you can also safely use the former.
@@ -675,13 +676,15 @@ void MyWindow::SendEvent()
Under certain circumstances, you must define your own event class e.g., for
sending more complex data from one place to another. Apart from defining your
event class, you also need to define your own event table macro if you want to
use event tables for handling events of this type.
event class, you also need to define your own event table macro if you still
need to use event tables (now considered legacy) for handling events of this type.
See ChessBoardEvent in the event sample for a full working implementation
of a new wxEvent-derived class.
Here is an example:
Here is a simple example:
@code
// define a new event class
// create a new event class derived from wxEvent
class MyPlotEvent: public wxEvent
{
public:
@@ -701,40 +704,51 @@ private:
const wxPoint m_pos;
};
// we define a single MY_PLOT_CLICKED event type associated with the class
// above but typically you are going to have more than one event type, e.g. you
// could also have MY_PLOT_ZOOMED or MY_PLOT_PANNED &c -- in which case you
// would just add more similar lines here
wxDEFINE_EVENT(MY_PLOT_CLICKED, MyPlotEvent);
// We use a single myEVT_PLOT_CLICKED event type associated with the class
// above but often you are going to have more than one event type, e.g. you
// could also have myEVT_PLOT_ZOOMED or myEVT_PLOT_PANNED etc. -- in which case
// you would just add more similar lines here.
//
// Note that this macro, as all declarations, should be in the header, and
// there should be a matching definition macro in some source file (see
// wxDEFINE_EVENT below).
wxDECLARE_EVENT(myEVT_PLOT_CLICKED, MyPlotEvent);
// if you want to support old compilers you need to use some ugly macros:
// --- Skip this part if you're only going to use Bind() (as recommended) ---
// The following typedef and macro are needed only when the new event class
// still needs to be used with the legacy approach to handling events - event
// table macros or Connect() - to cast the type of a function handling it to
// the type expected by the legacy event handling machinery.
typedef void (wxEvtHandler::*MyPlotEventFunction)(MyPlotEvent&);
#define MyPlotEventHandler(func) wxEVENT_HANDLER_CAST(MyPlotEventFunction, func)
// if your code is only built using reasonably modern compilers, you could just
// do this instead:
#define MyPlotEventHandler(func) (&func)
// If the new event is to be used with event tables, a macro for creating
// event table entries for the new event type must be defined.
#define EVT_PLOT_CLICKED(id, func) \
wx__DECLARE_EVT1(myEVT_PLOT_CLICKED, id, MyPlotEventHandler(func))
// finally define a macro for creating the event table entries for the new
// event type
//
// remember that you don't need this at all if you only use Bind<>() and that
// you can replace MyPlotEventHandler(func) with just &func unless you use a
// really old compiler
#define MY_EVT_PLOT_CLICK(id, func) \
wx__DECLARE_EVT1(MY_PLOT_CLICKED, id, MyPlotEventHandler(func))
// --- End of the part which is only relevant when using event tables ---
// example of code handling the event (you will use one of these methods, not
// both, of course):
// Up until now, we only had declarations that would typically appear in a
// header file. Starting from now we have the definitions, which must occur
// only once in the program and so need to be in a source file.
// This defines the event type declared above. If you use multiple event types,
// you need to do it for each of them.
wxDEFINE_EVENT(myEVT_PLOT_CLICKED, MyPlotEvent);
// example of code handling the event (you will use one of these methods,
// not both, of course):
wxBEGIN_EVENT_TABLE(MyFrame, wxFrame)
EVT_PLOT(ID_MY_WINDOW, MyFrame::OnPlot)
EVT_PLOT_CLICKED(ID_MY_WINDOW, MyFrame::OnPlot)
wxEND_EVENT_TABLE()
MyFrame::MyFrame()
{
Bind(MY_PLOT_CLICKED, &MyFrame::OnPlot, this, ID_MY_WINDOW);
Bind(myEVT_PLOT_CLICKED, &MyFrame::OnPlot, this, ID_MY_WINDOW);
}
void MyFrame::OnPlot(MyPlotEvent& event)
@@ -746,7 +760,7 @@ void MyFrame::OnPlot(MyPlotEvent& event)
// example of code generating the event:
void MyWindow::SendEvent()
{
MyPlotEvent event(MY_PLOT_CLICKED, GetId(), wxPoint(...));
MyPlotEvent event(myEVT_PLOT_CLICKED, GetId(), wxPoint(...));
event.SetEventObject(this);
ProcessWindowEvent(event);
}
@@ -864,6 +878,32 @@ If you use wxNewId() consistently in your application, you can be sure that
your identifiers don't conflict accidentally.
@subsection overview_events_with_mouse_capture Event Handlers and Mouse Capture
Some events are generated in response to a user action performed using the
mouse and, often, the mouse will be captured (see wxWindow::CaptureMouse()) by
the window generating the event in this case. This happens when the user is
dragging the mouse, i.e. for all events involving resizing something (e.g. @c
EVT_SPLITTER_SASH_POS_CHANGING), but also, perhaps less obviously, when
selecting items (e.g. @c EVT_LIST_ITEM_SELECTED).
When the mouse is captured, the control sending events will continue receiving
all mouse events, meaning that the event handler can't do anything relying on
getting them in any other window. Most notably, simply showing a modal dialog
won't work as expected, as the dialog won't receive any mouse input and appear
unresponsive to the user.
The best solution is to avoid showing modal dialogs from such event handlers
entirely, as it can be jarring for the user to be interrupted in their workflow
by a dialog suddenly popping up. However if it's really indispensable to show a
dialog, you need to forcefully break the existing mouse capture by capturing
(and then releasing, because you don't really need the capture) it yourself:
@code
dialog.CaptureMouse();
dialog.ReleaseMouse();
@endcode
@subsection overview_events_custom_generic Generic Event Table Macros
@beginTable

2
docs/doxygen/overviews/grid.h
View File

@@ -84,6 +84,7 @@ Here is a list of classes related to wxGrid:
number.
@li wxGridCellBoolRenderer: Renderer showing the cell as checked or unchecked
box.
@li wxGridCellDateRenderer: Renderer showing the cell as date.
@li wxGridCellEditor: Base class for objects used to edit the cell value.
@li wxGridCellStringEditor: Editor for cells containing text strings.
@li wxGridCellNumberEditor: Editor for cells containing integer numbers.
@@ -91,6 +92,7 @@ Here is a list of classes related to wxGrid:
@li wxGridCellBoolEditor: Editor for boolean-valued cells.
@li wxGridCellChoiceEditor: Editor allowing to choose one of the predefined
strings (and possibly enter new one).
@li wxGridCellDateEditor: Editor for cells containing dates without time component.
@li wxGridEvent: The event sent by most of wxGrid actions.
@li wxGridSizeEvent: The special event sent when a grid column or row is
resized.

4
docs/doxygen/overviews/helloworld.h
View File

@@ -15,6 +15,10 @@ This page shows a very simple wxWidgets program that can be used as a skeleton
for your own code. While it does nothing very useful, it introduces a couple of
important concepts and explains how to write a working wxWidgets application.
Note that this simple example creates the UI entirely from C++ code which is
fine for a simple example, but more realistic examples will typically define
their UI at least partially in @ref overview_xrc "XRC resource files".
First, you have to include wxWidgets' header files, of course. This can be done
on a file by file basis (such as @c wx/window.h) or using one global include
(@c wx/wx.h) which includes most of the commonly needed headers (although not

149
docs/doxygen/overviews/high_dpi.md Normal file
View File

@@ -0,0 +1,149 @@
High DPI Support in wxWidgets {#overview_high_dpi}
=============================
[TOC]
Introduction
============
Many modern displays have way more pixels on the same surface than used to be
the norm, resulting in much higher values of DPI (dots, i.e. pixels, per inch)
than the traditionally used values. This allows to render texts, or geometric
shapes in general much more smoothly.
As an illustration here are two scaled up views of the same text in 11 pt
Helvetica using up the same space on screen. First on an original Mac display
at 72 dpi, then on a High DPI Display, called "Retina" by Apple with twice as
many pixels in both dimensions (144 dpi), thus 4 times the number of pixels on
the same surface. Using these the contours are much more detailed.
![11 pt Helvetica at 72 DPI](overview_highdpi_text_72.png)
![11 pt Helvetica at 144 DPI](overview_highdpi_text_144.png)
To the user the DPI is typically expressed using a scaling factor, by which the
baseline DPI value is multiplied. For example, MSW systems may use 125% or 150%
scaling, meaning that they use DPI of 120 or 144 respectively, as baseline DPI
value is 96. Similarly, Linux systems may use "2x" scaling, resulting in DPI
value of 192. Macs are slightly different, as even they also may use "2x"
scaling, as in the example above, the effective DPI corresponding to it is 144,
as the baseline value on this platform is 72.
The Problem with High DPI Displays
----------------------------------
If high DPI displays were treated in the same way as normal ones, existing
applications would look tiny of them. For example, a square window 500 pixels
in size would take half of a standard 1920×1080 ("Full HD") display vertically,
but only a quarter on a 3840×2160 ("4K UHD") display. To prevent this from
happening, most platforms automatically scale the windows by the scaling
factor, defined above, when displaying them on high DPI displays. In this
example, scaling factor is 2 and so the actual size of the window on screen
would become 1000 when automatic scaling is in effect.
Automatic scaling is convenient, but doesn't really allow the application to
use the extra pixels available on the display. Visually, this means that the
scaled application appears blurry, in contrast to sharper applications using
the full display resolution, so a better solution for interpreting pixel values
on high DPI displays is needed: one which allows to scale some pixel values
(e.g. the total window size), but not some other ones (e.g. those used for
drawing, which should remain unscaled to use the full available resolution).
Pixel Values in wxWidgets
=========================
Logical and Device-Independent Pixels
-------------------------------------
Some systems like eg Apple's OSes automatically scale all the coordinates by
the DPI scaling factor, however not all systems supported by wxWidgets do it --
notably, MSW does not. This means that **logical pixels**, in which all
coordinates and sizes are expressed in wxWidgets API, do _not_ have the same
meaning on all platforms when using high DPI displays. So while on macOS you
can always pass in a size of (500,500) to create the window from the previous
paragraph, whatever the resolution of the display is, you would have to
increase this to (1000,1000) on MSW when working on a 200% display. To hide
this difference from the application, wxWidgets provides **device-independent
pixels**, abbreviated as "DIP", that are always of the same size on all
displays and all platforms.
Thus, the first thing do when preparing your application for high DPI support
is to stop using raw pixel values. Actually, using any pixel values is not
recommended and replacing them with the values based on the text metrics, i.e.
obtained using wxWindow::GetTextExtent(), or expressing them in dialog units
(see wxWindow::ConvertDialogToPixels()) is preferable. However the simplest
change is to just replace the pixel values with the values in DIP: for this,
just use wxWindow::FromDIP() to convert from one to the other.
For example, if you have the existing code:
```cpp
myFrame->SetClientSize(wxSize(400, 300));
```
you can just replace it with
```cpp
myFrame->SetClientSize(myFrame->FromDIP(wxSize(400, 300)));
```
Physical Pixels
---------------
In addition to (logical) pixels and DIPs discussed above, you may also need to
work in physical pixel coordinates, corresponding to the actual display pixels.
Physical pixels are never scaled, on any platform, and must be used when
drawing graphics elements to ensure that the best possible resolution is used.
For example, all operations on wxGLCanvas use physical pixels.
To convert between logical and physical pixels, you can use
wxWindow::GetContentScaleFactor(): this is a value greater than or equal to 1,
so a value in logical pixels needs to be multiplied by it in order to obtain
the value in physical pixels.
For example, in a wxGLCanvas created with the size of 100 (logical) pixels, the
rightmost physical pixel coordinate will be `100*GetContentScaleFactor()`.
High-Resolution Images and Artwork
==================================
In order to benefit from the increased detail on High DPI devices you might want
to provide the images or artwork your application uses in higher resolutions as
well. Note that it is not recommended to just provide a high-resolution version
and let the system scale that down on 1x displays. Apart from performance
consideration also the quality might suffer, contours become more blurry.
You can use vector based graphics like SVG or you can add the same image at different
sizes / resolutions.
[comment]: # (TODO: API and Use Cases)
Platform-Specific Build Issues
==============================
Generally speaking, all systems handle applications not specifically marked as
being "DPI-aware" by emulating low-resolution display for them and scaling them
up, resulting in blurry graphics and fonts, but globally preserving the
application appearance. For the best results, the application needs to be
explicitly marked as DPI-aware in a platform-dependent way.
MSW
---
The behaviour of the application when running on a high-DPI display depends on
the values in its [manifest][1]. If your application include `wx/msw/wx.rc`
from its resource file, you need to predefine `wxUSE_DPI_AWARE_MANIFEST` to
opt-in into [high DPI support][2]: define it as `1` for minimal DPI awareness and
`2` for full, per-monitor DPI awareness supported by Windows 10 version 1703 or
later.
[1]: https://docs.microsoft.com/en-us/windows/win32/sbscs/application-manifests
[2]: https://docs.microsoft.com/en-us/windows/win32/hidpi/high-dpi-desktop-application-development-on-windows
macOS
-----
DPI-aware applications must set their `NSPrincipalClass` to `wxNSApplication`
(or at least `NSApplication`) in their `Info.plist` file. Also see Apple [high
resolution guidelines][2] for more information.
[2]: https://developer.apple.com/library/archive/documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Explained/Explained.html

2
docs/doxygen/overviews/html.h
View File

@@ -13,7 +13,7 @@
The wxHTML library provides classes for parsing and displaying HTML.
It is not intended to be a high-end HTML browser. If you are looking for
something like that try <http://www.mozilla.org/>.
something like that use wxWebView.
wxHTML can be used as a generic rich text viewer - for example to display
a nice About Box (like those of GNOME apps) or to display the result of

11
docs/doxygen/overviews/internationalization.h
View File

@@ -59,6 +59,11 @@ Translating your application involves several steps:
given language: see wxLocale.
@note Under macOS you also need to list all the supported languages under
@c CFBundleLocalizations key in your application @c Info.plist file
in order to allow the application to support the corresponding locale.
@section overview_i18n_mofiles Installing translation catalogs
The .mo files with compiled catalogs must be included with the application.
@@ -75,12 +80,12 @@ locations when possible.
Depending on the platform, the default location differs. On Windows, it is
alongside the executable. On Unix, translations are expected to be in
"$prefix/share/locale". On OS X, application bundle's @em Resources subdirectory
"$prefix/share/locale". On macOS, application bundle's @em Resources subdirectory
is used.
In all cases, translations are searched for in subdirectories named using the
languages codes from ISO 639. The .mo file(s) should be located either directly
in that directory or in LC_MESSAGES subdirectory. On OS X, ".lproj" extension
in that directory or in LC_MESSAGES subdirectory. On macOS, ".lproj" extension
is used for the per-languages Resources subdirectories.
Here's how an app would typically install the files on Unix:
@@ -89,7 +94,7 @@ Here's how an app would typically install the files on Unix:
/usr/share/locale/de/LC_MESSAGES/myapp.mo
/usr/share/locale/fr/LC_MESSAGES/myapp.mo
@endcode
And on OS X:
And on macOS:
@code
MyApp.app/Contents/MacOS/MyApp
MyApp.app/Contents/Resources/de.lproj/myapp.mo

12
docs/doxygen/overviews/log.h
View File

@@ -19,9 +19,9 @@ as well as several standard implementations of it and a family of functions to
use with them.
First of all, no knowledge of wxLog classes is needed to use them. For this,
you should only know about @ref group_funcmacro_log "wxLogXXX() functions".
All of them have the same syntax as @e printf() or @e vprintf() , i.e. they
take the format string as the first argument and respectively a variable number
you should only know about @ref group_funcmacro_log "wxLogXXX() functions".
All of them have the same syntax as @e printf() or @e vprintf() , i.e. they
take the format string as the first argument and respectively a variable number
of arguments or a variable argument list pointer. Here are all of them:
@li wxLogFatalError() which is like wxLogError(), but also terminates the program
@@ -161,8 +161,8 @@ works.
wxWidgets has the notion of a <em>log target</em>: it is just a class deriving
from wxLog. As such, it implements the virtual functions of the base class
which are called when a message is logged. Only one log target is @e active at
any moment, this is the one used by @ref group_funcmacro_log "wxLogXXX() functions".
The normal usage of a log object (i.e. object of a class derived from wxLog) is
any moment, this is the one used by @ref group_funcmacro_log "wxLogXXX() functions".
The normal usage of a log object (i.e. object of a class derived from wxLog) is
to install it as the active target with a call to @e SetActiveTarget() and it
will be used automatically by all subsequent calls to
@ref group_funcmacro_log "wxLogXXX() functions".
@@ -263,7 +263,7 @@ GUI is (already/still) available when your log target as used as wxWidgets
automatically switches to using wxLogStderr if it isn't.
There are several methods which may be overridden in the derived class to
customize log messages handling: wxLog::DoLogRecord(), wxLog::DoLogTextAtLevel()
customize log messages handling: wxLog::DoLogRecord(), wxLog::DoLogTextAtLevel()
and wxLog::DoLogText().
The last method is the simplest one: you should override it if you simply

2
docs/doxygen/overviews/printing.h
View File

@@ -84,7 +84,7 @@ The scaling of the drawn image typically differs from the screen to the preview
and printed images. This class provides a set of routines named
FitThisSizeToXXX(), MapScreenSizeToXXX(), and GetLogicalXXXRect, which can be
used to set the user scale and origin of the wxPrintout's DC so that your class
can easily map your image to the printout withough getting into the details of
can easily map your image to the printout without getting into the details of
screen and printer PPI and scaling. See the printing sample for examples of how
these routines are used.

11
docs/doxygen/overviews/propgrid.h
View File

@@ -733,10 +733,10 @@ accomplish the task:
@code
// Have property editor focus on Enter
propgrid->AddActionTrigger( wxPG_ACTION_EDIT, WXK_RETURN );
// Have Enter work as action trigger even when editor is focused
propgrid->DedicateKey( WXK_RETURN );
// Let Enter also navigate to the next property
propgrid->AddActionTrigger( wxPG_ACTION_NEXT_PROPERTY, WXK_RETURN );
@@ -807,10 +807,9 @@ See wxPGMultiButton class reference.
@subsection propgrid_customeventhandling Handling Events Passed from Properties
<b>wxEVT_COMMAND_BUTTON_CLICKED </b>(corresponds to event table macro EVT_BUTTON):
Occurs when editor button click is not handled by the property itself
(as is the case, for example, if you set property's editor to TextCtrlAndButton
from the original TextCtrl).
@c wxEVT_BUTTON: Occurs when editor button click is not handled by the property
itself (as is the case, for example, if you set property's editor
to TextCtrlAndButton from the original TextCtrl).
@subsection propgrid_attributes Property Attributes

6
docs/doxygen/overviews/richtextctrl.h
View File

@@ -42,7 +42,7 @@ list styles with a renumber option.
There are a few disadvantages to using wxRichTextCtrl. It is not native, so
does not behave exactly as a native wxTextCtrl, although common editing
conventions are followed. Users may miss the built-in spelling correction on
OS X, or any special character input that may be provided by the native
macOS, or any special character input that may be provided by the native
control. It would also be a poor choice if intended users rely on screen
readers that would be not work well with non-native text input implementation.
You might mitigate this by providing the choice between wxTextCtrl and
@@ -415,7 +415,7 @@ set the focus back to the top-level object.
An event will be sent to the control when the focus changes.
When the user clicks on the control, wxRichTextCtrl determines which container
to set as the current object focus by calling the found container's overrided
to set as the current object focus by calling the found container's overridden
wxRichTextObject::AcceptsFocus function. For example, although a table is a
container, it must not itself be the object focus because there is no text
editing at the table level. Instead, a cell within the table must accept the
@@ -495,7 +495,7 @@ tables, text boxes, and floating images, in addition to a simplified-HTML mode f
There are also things that could be done to take advantage of the underlying
text capabilities of the platform; higher-level text formatting APIs are
available on some platforms, such as OS X, and some of translation from
available on some platforms, such as macOS, and some of translation from
high level to low level wxDC API is unnecessary. However this would require
additions to the wxWidgets API.

51
docs/doxygen/overviews/roughguide.h
View File

@@ -11,28 +11,40 @@
@tableofcontents
To set a wxWidgets application going, you will need to derive a wxApp class and
override wxApp::OnInit.
@section overview_roughguide_structure Application Structure
An application must have a top-level wxFrame or wxDialog window. Each frame may
contain one or more instances of classes such as wxPanel, wxSplitterWindow or
other windows and controls.
To set a wxWidgets application going, you will need to derive a wxApp class and
override wxApp::OnInit() in which you will typically create your application
main top-level window.
This window can be a wxFrame or a wxDialog and may contain one or more
instances of classes such as wxPanel, wxSplitterWindow or other windows and
controls. These windows can be created from C++ code or loaded from resource
definitions in @ref overview_xrc "XRC format".
A frame can have a wxMenuBar, a wxToolBar, a wxStatusBar, and a wxIcon for when
the frame is iconized.
A wxPanel is used to place controls (classes derived from wxControl) which are
used for user interaction. Examples of controls are wxButton, wxCheckBox,
wxChoice, wxListBox, wxRadioBox, and wxSlider.
wxChoice, wxListBox, wxRadioBox, and wxSlider. Such controls need to be
positioned correctly -- and also repositioned when the top-level window is
resized by the user -- and to do this you use wxSizer-derived classes, such as
wxBoxSizer and wxFlexGridSizer, to layout everything correctly.
Instances of wxDialog can also be used for controls and they have the advantage
of not requiring a separate frame.
of not requiring a separate panel inside them.
Instead of creating a dialog box and populating it with items, it is possible
to choose one of the convenient common dialog classes, such as wxMessageDialog
and wxFileDialog.
You never draw directly onto a window - you use a <em>device context</em> (DC).
@section overview_roughguide_draw Drawing on the Screen
You never draw directly onto a window -- you use either one of the older
<em>device context</em> (DC) classes or the newer <em>graphics context</em>
(GC) one, that support features such as alpha transparency or anti-aliasing.
wxDC is the base for wxClientDC, wxPaintDC, wxMemoryDC, wxPostScriptDC,
wxMemoryDC, wxMetafileDC and wxPrinterDC. If your drawing functions have wxDC
as a parameter, you can pass any of these DCs to the function, and thus use the
@@ -40,20 +52,19 @@ same code to draw to several different devices. You can draw using the member
functions of wxDC, such as wxDC::DrawLine and wxDC::DrawText. Control colour on
a window (wxColour) with brushes (wxBrush) and pens (wxPen).
To intercept events, you add a wxDECLARE_EVENT_TABLE macro to the window class
declaration, and put a wxBEGIN_EVENT_TABLE ... wxEND_EVENT_TABLE block in the
implementation file. Between these macros, you add event macros which map the
event (such as a mouse click) to a member function. These might override
predefined event handlers such as for wxKeyEvent and wxMouseEvent.
With wxGraphicsContext, you create it using one of the methods of
wxGraphicsRenderer and then construct your drawing from wxGraphicsPath objects,
finally using wxGraphicsContext::StrokePath() or wxGraphicsContext::FillPath().
Most modern applications will have an on-line, hypertext help system; for this,
you need wxHelp and the wxHelpController class to control wxHelp.
GUI applications aren't all graphical wizardry. List and hash table needs are
catered for by wxList and wxHashMap. You will undoubtedly need some
platform-independent @ref group_funcmacro_file, and you may find it handy to
maintain and search a list of paths using wxPathList. There's many
@ref group_funcmacro_misc of operating system methods and other functions.
@section overview_roughguide_events Event Handling
GUI programs spend most of their time waiting for the user-initiated events --
and then processing them. To do it, you use wxEvtHandler::Bind() to specify the
handler for an event of the given time. Event handlers receive the object
describing the event, such as wxKeyEvent or wxMouseEvent, and perform whichever
action corresponds to it. See @ref overview_events "events handling" overview
for much more information about this subject.
@see @ref group_class

20
docs/doxygen/overviews/sizer.h
View File

@@ -15,7 +15,7 @@ Sizers, as represented by the wxSizer class and its descendants in the
wxWidgets class hierarchy, have become the method of choice to define the
layout of controls in dialogs in wxWidgets because of their ability to create
visually appealing dialogs independent of the platform, taking into account
the differences in size and style of the individual controls.
the differences in size and style of the individual controls.
The next section describes and shows what can be done with sizers. The
following sections briefly describe how to program with individual sizer
@@ -211,7 +211,7 @@ window will preserve it is original size, @c wxGROW flag (same as @c wxEXPAND) f
the window to grow with the sizer, and @c wxSHAPED flag tells the window to change
it is size proportionally, preserving original aspect ratio. When @c wxGROW flag
is not used, the item can be aligned within available space. @c wxALIGN_LEFT,
@c wxALIGN_TOP, @c wxALIGN_RIGHT, @c wxALIGN_BOTTOM, @c wxALIGN_CENTER_HORIZONTAL
@c wxALIGN_TOP, @c wxALIGN_RIGHT, @c wxALIGN_BOTTOM, @c wxALIGN_CENTER_HORIZONTAL
and @c wxALIGN_CENTER_VERTICAL do what they say. @c wxALIGN_CENTRE (same as
@c wxALIGN_CENTER) is defined as (<tt>wxALIGN_CENTER_HORIZONTAL | wxALIGN_CENTER_VERTICAL</tt>).
Default alignment is <tt>wxALIGN_LEFT | wxALIGN_TOP</tt>.
@@ -267,7 +267,7 @@ MyDialog::MyDialog(wxFrame *parent, wxWindowID id, const wxString &title )
}
@endcode
Note that the recommended way of specifying flags to wxSizer is via wxSizerFlags.
Note that the recommended way of specifying flags to wxSizer is via wxSizerFlags.
This class greatly eases the burden of passing flags to a wxSizer.
Here's how you'd do the previous example with wxSizerFlags:
@@ -313,18 +313,18 @@ MyDialog::MyDialog(wxFrame *parent, wxWindowID id, const wxString &title )
@section overview_sizer_types Other Types of Sizers
wxStdDialogButtonSizer is a sizer that creates button layouts in dialogs
which conform to the standard button spacing and ordering defined by
wxStdDialogButtonSizer is a sizer that creates button layouts in dialogs
which conform to the standard button spacing and ordering defined by
the platform or toolkit's user interface guidelines (if such things exist).
As a convenience, wxDialog::CreateButtonSizer() can be used to create this sizer.
wxWrapSizer is a sizer that lays out its items in a single line, like a box
sizer -- as long as there is space available in that direction. Once all available
space in the primary direction has been used, a new line is added and items
are added there.
wxWrapSizer is a sizer that lays out its items in a single line, like a box
sizer -- as long as there is space available in that direction. Once all available
space in the primary direction has been used, a new line is added and items
are added there.
wxGridBagSizer is a rather special kind of sizer which, unlike the other
classes, allows to directly put the elements at the given position in the
sizer.
sizer.
*/

32
docs/doxygen/overviews/string.h
View File

@@ -135,7 +135,7 @@ to buffer overflows. At last, C++ has a standard string class (@c std::string).
why the need for wxString? There are several advantages:
@li <b>Efficiency:</b> Since wxWidgets 3.0 wxString uses @c std::string (in UTF8
mode under Linux, Unix and OS X) or @c std::wstring (in UTF16 mode under Windows)
mode under Linux, Unix and macOS) or @c std::wstring (in UTF16 mode under Windows)
internally by default to store its contents. wxString will therefore inherit the
performance characteristics from @c std::string.
@li <b>Compatibility:</b> This class tries to combine almost full compatibility
@@ -236,12 +236,40 @@ arguments should take <tt>const wxString&</tt> (this makes assignment to the
strings inside the function faster) and all functions returning strings
should return wxString - this makes it safe to return local variables.
Finally note that wxString uses the current locale encoding to convert any C string
Note that wxString uses by default the current locale encoding to convert any C string
literal to Unicode. The same is done for converting to and from @c std::string
and for the return value of c_str().
For this conversion, the @a wxConvLibc class instance is used.
See wxCSConv and wxMBConv.
It is also possible to disable any automatic conversions from C
strings to Unicode. This can be useful when the @a wxConvLibc encoding
is not appropriate for the current software and platform. The macro @c
wxNO_IMPLICIT_WXSTRING_ENCODING disables all implicit conversions, and
forces the code to explicitly indicate the encoding of all C strings.
Finally note that encodings, either implicitly or explicitly selected,
may not be able to represent all the string's characters. The result
in this case is undefined: the string may be empty, or the
unrepresentable characters may be missing or wrong.
@code
wxString s;
// s = "world"; does not compile with wxNO_IMPLICIT_WXSTRING_ENCODING
s = wxString::FromAscii("world"); // Always compiles
s = wxASCII_STR("world"); // shorthand for the above
s = wxString::FromUTF8("world"); // Always compiles
s = wxString("world", wxConvLibc); // Always compiles, explicit encoding
s = wxASCII_STR("Grüße"); // Always compiles but encoding fails
const char *c;
// c = s.c_str(); does not compile with wxNO_IMPLICIT_WXSTRING_ENCODING
// c = s.mb_str(); does not compile with wxNO_IMPLICIT_WXSTRING_ENCODING
c = s.ToAscii(); // Always compiles, encoding may fail
c = s.ToUTF8(); // Always compiles, encoding never fails
c = s.utf8_str(); // Alias for the above
c = s.mb_str(wxConvLibc); // Always compiles, explicit encoding
@endcode
@subsection overview_string_iterating Iterating wxString Characters

2
docs/doxygen/overviews/unicode.h
View File

@@ -182,7 +182,7 @@ aware of the potential problems covered by the following section.
wxWidgets uses the system @c wchar_t in wxString implementation by default
under all systems. Thus, under Microsoft Windows, UCS-2 (simplified version of
UTF-16 without support for surrogate characters) is used as @c wchar_t is 2
bytes on this platform. Under Unix systems, including OS X, UCS-4 (also
bytes on this platform. Under Unix systems, including macOS, UCS-4 (also
known as UTF-32) is used by default, however it is also possible to build
wxWidgets to use UTF-8 internally by passing @c \--enable-utf8 option to
configure.

5
docs/doxygen/overviews/windowsizing.h
View File

@@ -116,4 +116,9 @@ some simple explanations of things.
the constraints algorithm is run. The @c Layout() method is what is called by
the default @c EVT_SIZE handler for container windows.
@li wxTopLevelWindow::Layout(): this overridden version does the same thing as
the base wxWindow::Layout() except, for convenience, it will also resize
the only child of the top-level window to cover its entire client area if
there is no sizer associated with the window. Note that this only happens
if there is exactly one child.
*/

4
docs/doxygen/overviews/xrc.h
View File

@@ -196,10 +196,10 @@ void MyClass::ShowDialog()
if (!wxXmlResource::Get()->LoadDialog(&dlg, NULL, "SimpleDialog"))
return;
XRCCTRL(dlg, "text", wxTextCtrl)->Bind(wxEVT_COMMAND_TEXT_UPDATED,
XRCCTRL(dlg, "text", wxTextCtrl)->Bind(wxEVT_TEXT,
wxTextEventHandler(MyClass::OnTextEntered), this, XRCID("text"));
XRCCTRL(dlg, "clickme_btn", wxButton)->Bind(wxEVT_COMMAND_BUTTON_CLICKED,
XRCCTRL(dlg, "clickme_btn", wxButton)->Bind(wxEVT_BUTTON,
wxCommandEventHandler(MyClass::OnClickme), this, XRCID("clickme_btn"));
dlg.ShowModal();

96
docs/doxygen/overviews/xrc_format.h
View File

@@ -115,7 +115,7 @@ These come in two varieties:
("\<label\>Cancel\</label\>"), but they may use nested subelements too (e.g.
@ref overview_xrcformat_type_font "font property"). A property can only be
listed once in an object's definition.
-# Child objects. Window childs, sizers, sizer items or notebook pages
-# Child objects. Window children, sizers, sizer items or notebook pages
are all examples of child objects. They are represented using nested
@c \<object\> elements and are can be repeated more than once. The specifics
of which object classes are allowed as children are class-specific and
@@ -352,6 +352,9 @@ wxFileSystem URL) of the bitmap to use. For example:
The value is interpreted as path relative to the location of XRC file where the
reference occurs.
Bitmap file paths can include environment variables that are expanded if
wxXRC_USE_ENVVARS was passed to the wxXmlResource constructor.
Alternatively, it is possible to specify the bitmap using wxArtProvider IDs.
In this case, the property element has no textual value (filename) and instead
has the @c stock_id XML attribute that contains stock art ID as accepted by
@@ -389,6 +392,16 @@ Examples:
@endcode
@subsection overview_xrcformat_type_showeffect Show Effect
One of the @ref wxShowEffect values.
Example:
@code
<showeffect>wxSHOW_EFFECT_EXPAND</showeffect>
@endcode
@subsection overview_xrcformat_type_font Font
XRC uses similar, but more flexible, abstract description of fonts to that
@@ -756,6 +769,11 @@ Refer to the section @ref xrc_wxtoolbar for more details.
@hdr3col{property, type, description}
@row3col{default, @ref overview_xrcformat_type_bool,
Should this button be the default button in dialog (default: 0)?}
@row3col{close, @ref overview_xrcformat_type_bool,
If set, this is a special "Close" button using system-defined appearance,
see wxBitmapButton::NewCloseButton(). If this property is set, @c bitmap
and @c style are ignored and shouldn't be used. Available since wxWidgets
3.1.5.}
@row3col{bitmap, @ref overview_xrcformat_type_bitmap,
Bitmap to show on the button (default: none).}
@row3col{selected, @ref overview_xrcformat_type_bitmap,
@@ -944,6 +962,9 @@ The wxCommandLinkButton contains a main title-like @c label and an optional
concatenated into a single string using a new line character between them
(notice that the @c note part can have more new lines in it).
Since wxWidgets 3.1.5 it also supports @c default and @c bitmap properties,
just as @ref xrc_wxbutton wxButton.
@beginTable
@hdr3col{property, type, description}
@row3col{label, @ref overview_xrcformat_type_text,
@@ -951,6 +972,10 @@ concatenated into a single string using a new line character between them
will be made when the button is pressed (default: empty). }
@row3col{note, @ref overview_xrcformat_type_text,
Second line of text describing the action performed when the button is pressed (default: none). }
@row3col{bitmap, @ref overview_xrcformat_type_bitmap,
Bitmap to display in the button (optional).}
@row3col{default, @ref overview_xrcformat_type_bool,
Should this button be the default button in dialog (default: 0)?}
@endTable
@@ -1021,6 +1046,25 @@ Example:
@endTable
@subsubsection xrc_wxdataviewctrl wxDataViewCtrl
No additional properties.
@subsubsection xrc_wxdataviewlistctrl wxDataViewListCtrl
No additional properties.
@subsubsection xrc_wxdataviewtreectrl wxDataViewTreeCtrl
@beginTable
@hdr3col{property, type, description}
@row3col{imagelist, @ref overview_xrcformat_type_imagelist,
Image list to use for the images (default: none).}
@endTable
@subsubsection xrc_wxdatepickerctrl wxDatePickerCtrl
No additional properties.
@@ -1153,6 +1197,14 @@ objects. If sizer child is used, it sets
Ignored, preserved only for compatibility.}
@endTable
@subsubsection xrc_wxgenericanimationctrl wxGenericAnimationCtrl
This handler is identical to the one for @ref xrc_wxanimationctrl
"wxAnimationCtrl", please see it for more information. The only difference is
that, for the platforms with a native wxAnimationCtrl implementation, using
this handler creates a generic control rather than a native one.
@subsubsection xrc_wxgenericdirctrl wxGenericDirCtrl
@beginTable
@@ -1199,6 +1251,40 @@ page.
@endTable
@subsubsection xrc_wxinfobar wxInfoBar
@beginTable
@hdr3col{property, type, description}
@row3col{showeffect, @ref overview_xrcformat_type_showeffect,
The effect to use when showing the bar (optional).}
@row3col{hideeffect, @ref overview_xrcformat_type_showeffect,
The effect to use when hiding the bar (optional).}
@row3col{effectduration, integer,
The duration of the animation used when showing or hiding the bar
(optional).}
@row3col{button, object,
Add a button to be shown in the info bar (see wxInfoBar::AddButton);
this property is of class "button" has name (can be one of standard
button ID) and has optional label property. If no buttons are added
to the info bar, the default "Close" button will be shown.}
@endTable
Example:
@code
<object class="wxInfoBar">
<effectduration>1000</effectduration>
<showeffect>wxSHOW_EFFECT_EXPAND</showeffect>
<hideeffect>wxSHOW_EFFECT_SLIDE_TO_RIGHT</hideeffect>
<object class="button" name="wxID_UNDO"/>
<object class="button" name="wxID_REDO">
<label>Redo Custom Label</label>
</object>
</object>
@endcode
@since 3.1.3
@subsubsection xrc_wxlistbox wxListBox
@beginTable
@@ -1745,7 +1831,7 @@ objects have the following properties:
@endTable
A wxRibbonPage may have children of any type derived from wxRibbonControl.
Most commontly, wxRibbonPanel is used. As a special case, the @c panel
Most commonly, wxRibbonPanel is used. As a special case, the @c panel
pseudo-class may be used instead of @c wxRibbonPanel when used as wxRibbonPage
children.
@@ -2589,15 +2675,15 @@ should be processed on. It is filtered out and ignored on any other platforms.
Possible elemental values are:
@beginDefList
@itemdef{ @c win, Windows }
@itemdef{ @c mac, OS X (or Mac Classic in wxWidgets version supporting it) }
@itemdef{ @c unix, Any Unix platform @em except OS X }
@itemdef{ @c mac, macOS (or Mac Classic in wxWidgets version supporting it) }
@itemdef{ @c unix, Any Unix platform @em except macOS }
@endDefList
Examples:
@code
<label platform="win">Windows</label>
<label platform="unix">Unix</label>
<label platform="mac">OS X</label>
<label platform="mac">macOS</label>
<help platform="mac|unix">Not a Windows machine</help>
@endcode

52
docs/doxygen/regen.sh
View File

@@ -6,7 +6,7 @@
# readable.
#
# Usage:
# ./regen.sh [html|chm|xml|latex|all]
# ./regen.sh [html|chm|xml|latex|docset|all]
#
# Pass "x" to regen only the X output format and "all" to regen them all.
# If no arguments are passed, HTML is regenerated (just like passing "html").
@@ -17,6 +17,8 @@
me=$(basename $0)
path=${0%%/$me} # path from which the script has been launched
cd "$path"
SCRIPTS_DIR="$(pwd)/scripts"
if [[ -z "$WXWIDGETS" ]]; then
# Notice the use of -P to ensure we get the canonical path even if there
# are symlinks in the current path. This is important because Doxygen
@@ -80,6 +82,7 @@ case "$1" in
docset)
export GENERATE_DOCSET="YES"
export GENERATE_HTML="YES"
export GENERATE_TAGFILE="$path/out/wxWidgets.tag"
;;
latex)
export GENERATE_LATEX="YES"
@@ -166,7 +169,11 @@ if [[ "$1" = "docset" ]]; then
ATOMDIR="https://docs.wxwidgets.org/docsets"
XAR="$BASENAME.xar"
XARDIR="https://docs.wxwidgets.org/docsets"
XCODE_INSTALL=`xcode-select -print-path`
# See if xcode is installed
if [ -x "$(command -v xcode-select)" ]; then
XCODE_INSTALL=`xcode-select -print-path`
fi
cd out/html
DESTINATIONDIR=`pwd`/../docset
@@ -177,19 +184,38 @@ if [[ "$1" = "docset" ]]; then
make DOCSET_NAME=$DESTINATIONDIR/$DOCSETNAME
defaults write $DESTINATIONDIR/$DOCSETNAME/Contents/Info CFBundleVersion 1.3
defaults write $DESTINATIONDIR/$DOCSETNAME/Contents/Info CFBundleShortVersionString 1.3
defaults write $DESTINATIONDIR/$DOCSETNAME/Contents/Info CFBundleName "wxWidgets 3.1"
defaults write $DESTINATIONDIR/$DOCSETNAME/Contents/Info DocSetFeedURL $ATOMDIR/$ATOM
defaults write $DESTINATIONDIR/$DOCSETNAME/Contents/Info DocSetFallbackURL https://docs.wxwidgets.org
defaults write $DESTINATIONDIR/$DOCSETNAME/Contents/Info DocSetDescription "API reference and conceptual documentation for wxWidgets 3.0"
defaults write $DESTINATIONDIR/$DOCSETNAME/Contents/Info NSHumanReadableCopyright "Copyright 1992-2018 wxWidgets team, Portions 1996 Artificial Intelligence Applications Institute"
defaults write $DESTINATIONDIR/$DOCSETNAME/Contents/Info isJavaScriptEnabled true
defaults write $DESTINATIONDIR/$DOCSETNAME/Contents/Info dashIndexFilePath index.html
defaults write $DESTINATIONDIR/$DOCSETNAME/Contents/Info DocSetPlatformFamily wx
# Choose which plist modification utility to use
if [ -x "$(command -v defaults)" ]; then
PLIST_WRITE_CMD="defaults write"
else
PLIST_WRITE_CMD="python $SCRIPTS_DIR/write_info_tag.py"
fi
$XCODE_INSTALL/usr/bin/docsetutil package -atom $DESTINATIONDIR/$ATOM -download-url $XARDIR/$XAR -output $DESTINATIONDIR/$XAR $DESTINATIONDIR/$DOCSETNAME
# Modify the Info.plist file
$PLIST_WRITE_CMD $DESTINATIONDIR/$DOCSETNAME/Contents/Info CFBundleVersion 1.3
$PLIST_WRITE_CMD $DESTINATIONDIR/$DOCSETNAME/Contents/Info CFBundleShortVersionString 1.3
$PLIST_WRITE_CMD $DESTINATIONDIR/$DOCSETNAME/Contents/Info CFBundleName "wxWidgets 3.1"
$PLIST_WRITE_CMD $DESTINATIONDIR/$DOCSETNAME/Contents/Info DocSetFeedURL $ATOMDIR/$ATOM
$PLIST_WRITE_CMD $DESTINATIONDIR/$DOCSETNAME/Contents/Info DocSetFallbackURL https://docs.wxwidgets.org
$PLIST_WRITE_CMD $DESTINATIONDIR/$DOCSETNAME/Contents/Info DocSetDescription "API reference and conceptual documentation for wxWidgets 3.0"
$PLIST_WRITE_CMD $DESTINATIONDIR/$DOCSETNAME/Contents/Info NSHumanReadableCopyright "Copyright 1992-2020 wxWidgets team, Portions 1996 Artificial Intelligence Applications Institute"
$PLIST_WRITE_CMD $DESTINATIONDIR/$DOCSETNAME/Contents/Info isJavaScriptEnabled true
$PLIST_WRITE_CMD $DESTINATIONDIR/$DOCSETNAME/Contents/Info dashIndexFilePath index.html
$PLIST_WRITE_CMD $DESTINATIONDIR/$DOCSETNAME/Contents/Info DocSetPlatformFamily wx
echo "Creating docset database"
if ! [ -z "$XCODE_INSTALL" ]; then
# Use xcode to create the docset if it is installed
$XCODE_INSTALL/usr/bin/docsetutil package -atom $DESTINATIONDIR/$ATOM -download-url $XARDIR/$XAR -output $DESTINATIONDIR/$XAR $DESTINATIONDIR/$DOCSETNAME
else
# Use doxytag2zealdb to create the database
# This requires the python package doxytag2zealdb installed
python -m doxytag2zealdb --tag $DESTINATIONDIR/../wxWidgets.tag --db $DESTINATIONDIR/$DOCSETNAME/Contents/Resources/docSet.dsidx --include-parent-scopes --include-function-signatures
fi
# Copy the icon
cp $SCRIPTS_DIR/../../../art/wxwin16x16.png $DESTINATIONDIR/$DOCSETNAME/icon.png
cp $SCRIPTS_DIR/../../../art/wxwin32x32.png $DESTINATIONDIR/$DOCSETNAME/icon@2x.png
cd ../..
fi

12
docs/doxygen/scripts/c_tools.py
View File

@@ -16,14 +16,14 @@ class CBuilder:
output_dir = os.path.abspath(os.path.join(self.output_dir, "c"))
if not os.path.exists(output_dir):
os.makedirs(output_dir)
for aclass in self.doxyparser.classes:
# This bit doesn't work, because the aclass.name is not the same as
# those listed in common
if aclass.name in excluded_classes:
#print "Skipping %s" % aclass.name
continue
self.make_c_header(output_dir, aclass)
@@ -46,7 +46,7 @@ class CBuilder:
def make_c_methods(self, aclass):
retval = ""
wxc_classname = 'wxC' + aclass.name[2:].capitalize()
for amethod in aclass.constructors:
@@ -59,13 +59,13 @@ class CBuilder:
if amethod.name.startswith('m_'):
# for some reason, public members are listed as methods
continue
args = '(' + wxc_classname + '* obj'
if amethod.argsstring.find('()') != -1:
args += ')'
else:
else:
args += ', ' + amethod.argsstring[1:].strip()
retval += """
// %s
%s %s%s;\n

4
docs/doxygen/scripts/common.py
View File

@@ -15,7 +15,7 @@ excluded_classes = [
"wxArchiveIterator",
"wxArchiveNotifier",
"wxArchiveOutputStream",
"wxArray< T >",
"wxArray< T >",
"wxArrayString",
"wxAutomationObject",
"wxBufferedInputStream",
@@ -160,5 +160,5 @@ def make_enums(aclass):
retval += ", "
retval += "\n"
retval += "};\n\n"
return retval

56
docs/doxygen/scripts/doxymlparser.py
View File

@@ -38,23 +38,23 @@ class ClassDefinition:
self.includes = []
self.bases = []
self.enums = {}
def __str__(self):
str_repr = """
Class: %s
Bases: %s
Includes: %s
Brief Description:
Brief Description:
%s
Detailed Description:
%s
""" % (self.name, string.join(self.bases, ", "), self.includes, self.brief_description, self.detailed_description)
str_repr += "Methods:\n"
for method in self.methods:
str_repr += str(method)
return str_repr
class MethodDefinition:
@@ -66,20 +66,20 @@ class MethodDefinition:
self.params = []
self.brief_description = ""
self.detailed_description = ""
def __str__(self):
str_repr = """
Method: %s
Return Type: %s
Params: %r
Prototype: %s
Brief Description:
Brief Description:
%s
Detailed Description:
%s
""" % (self.name, self.return_type, self.params, self.definition + self.argsstring, self.brief_description, self.detailed_description)
return str_repr
return str_repr
def getTextValue(node, recursive=False):
text = ""
@@ -89,7 +89,7 @@ def getTextValue(node, recursive=False):
if child.nodeType == child.TEXT_NODE:
# Add a space to ensure we have a space between qualifiers and parameter names
text += child.nodeValue.strip() + " "
return text.strip()
def doxyMLToText(node):
@@ -104,7 +104,7 @@ class DoxyMLParser:
for aclass in self.classes:
if aclass.name == name:
return aclass
return None
def get_enums_and_functions(self, filename, aclass):
@@ -119,17 +119,17 @@ class DoxyMLParser:
def is_derived_from_base(self, aclass, abase):
base = get_first_value(aclass.bases)
while base and base != "":
if base == abase:
return True
parentclass = self.find_class(base)
if parentclass:
base = get_first_value(parentclass.bases)
else:
base = None
return False
def parse(self, filename):
@@ -138,7 +138,7 @@ class DoxyMLParser:
new_class = self.parse_class(node)
self.classes.append(new_class)
self.get_enums_and_functions(filename, new_class)
def parse_class(self, class_node):
new_class = ClassDefinition()
new_class.name = getTextValue(class_node.getElementsByTagName("compoundname")[0])
@@ -156,21 +156,21 @@ class DoxyMLParser:
self.parse_methods(new_class, class_node)
return new_class
def parse_enum(self, new_class, enum, root):
enum_name = ""
enum_values = []
for node in enum.childNodes:
if node.nodeName == "name":
enum_name = getTextValue(node)
elif node.nodeName == "enumvalue":
enum_values.append(getTextValue(node.getElementsByTagName("name")[0]))
new_class.enums[enum_name] = enum_values
def parse_methods(self, new_class, root):
for method in root.getElementsByTagName("memberdef"):
for method in root.getElementsByTagName("memberdef"):
new_method = MethodDefinition()
for node in method.childNodes:
if node.nodeName == "name":
@@ -187,10 +187,10 @@ class DoxyMLParser:
if child.nodeType == child.ELEMENT_NODE:
param[child.nodeName] = getTextValue(child)
new_method.params.append(param)
if self.verbose:
print "Adding %s" % (new_method.name + new_method.argsstring)
if new_method.name == new_class.name:
new_class.constructors.append(new_method)
elif new_method.name == "~" + new_class.name:
@@ -199,30 +199,30 @@ class DoxyMLParser:
new_class.methods.append(new_method)
if __name__ == "__main__":
option_dict = {
option_dict = {
"report" : (False, "Print out the classes and methods found by this script."),
"verbose" : (False, "Provide status updates and other information."),
}
parser = optparse.OptionParser(usage="usage: %prog [options] <doxyml files to parse>\n" + __description__, version="%prog 1.0")
for opt in option_dict:
default = option_dict[opt][0]
action = "store"
if type(default) == types.BooleanType:
action = "store_true"
parser.add_option("--" + opt, default=default, action=action, dest=opt, help=option_dict[opt][1])
options, arguments = parser.parse_args()
if len(arguments) < 1:
parser.print_usage()
sys.exit(1)
doxyparse = DoxyMLParser(verbose = options.verbose)
for arg in arguments:
doxyparse.parse(arg)
doxyparse.parse(arg)
if options.report:
for aclass in doxyparse.classes:

20
docs/doxygen/scripts/make_bindings.py
View File

@@ -12,42 +12,42 @@ import swig_tools
from common import *
if __name__ == "__main__":
option_dict = {
option_dict = {
"output_dir" : ("output", "Directory to output bindings to"),
"sip" : (True, "Produce SIP bindings"),
"swig" : (True, "Produce SWIG bindings."),
"c" : (True, "Produce C wrappers."),
}
parser = optparse.OptionParser(usage="usage: %prog <doxyml files to parse>\n" , version="%prog 1.0")
for opt in option_dict:
default = option_dict[opt][0]
action = "store"
if type(default) == types.BooleanType:
action = "store_true"
parser.add_option("--" + opt, default=default, action=action, dest=opt, help=option_dict[opt][1])
options, arguments = parser.parse_args()
if len(arguments) < 1:
parser.print_usage()
sys.exit(1)
doxyparse = doxymlparser.DoxyMLParser()
for arg in arguments:
doxyparse.parse(arg)
if options.sip:
builder = sip_tools.SIPBuilder(doxyparse, options.output_dir)
builder.make_bindings()
if options.swig:
builder = swig_tools.SWIGBuilder(doxyparse, options.output_dir)
builder.make_bindings()
if options.c:
builder = c_tools.CBuilder(doxyparse, options.output_dir)
builder.make_bindings()

22
docs/doxygen/scripts/sip_tools.py
View File

@@ -11,12 +11,12 @@ class SIPBuilder:
output_dir = os.path.abspath(os.path.join(self.output_dir, "sip"))
if not os.path.exists(output_dir):
os.makedirs(output_dir)
for aclass in self.doxyparser.classes:
if aclass.name in excluded_classes:
print "Skipping %s" % aclass.name
continue
header_name = aclass.name[2:].lower()
filename = os.path.join(output_dir, "_" + header_name + ".sip")
enums_text = make_enums(aclass)
@@ -24,7 +24,7 @@ class SIPBuilder:
base_class = get_first_value(aclass.bases)
if base_class != "":
base_class = ": %s" % base_class
text = """
%s
class %s %s
@@ -45,12 +45,12 @@ public:
def make_sip_methods(self, aclass):
retval = ""
for amethod in aclass.constructors + aclass.methods:
transfer = ""
# FIXME: we need to come up with a way of filtering the methods out by various criteria
# including parameters and method name, and how to deal with overloads
# including parameters and method name, and how to deal with overloads
if aclass.name in ignored_methods:
should_ignore = False
for method in ignored_methods[aclass.name]:
@@ -66,19 +66,19 @@ public:
print "param type = %s, amethod.param type = %s" % (params[i], amethod.params[i]["type"])
should_ignore = False
break
if should_ignore:
continue
# We need to let SIP know when wx is responsible for deleting the object.
# We do this if the class is derived from wxWindow, since wxTLW manages child windows
# and wxApp deletes all wxTLWs on shutdown
if amethod in aclass.constructors and self.doxyparser.is_derived_from_base(aclass, "wxWindow"):
transfer = "/Transfer/"
if amethod.name.startswith("operator"):
continue
retval += " %s %s%s%s;\n\n" % (amethod.return_type.replace("virtual ", ""), amethod.name, amethod.argsstring, transfer)
return retval

18
docs/doxygen/scripts/swig_tools.py
View File

@@ -11,13 +11,13 @@ class SWIGBuilder:
output_dir = os.path.abspath(os.path.join(self.output_dir, "swig"))
if not os.path.exists(output_dir):
os.makedirs(output_dir)
for aclass in self.doxyparser.classes:
header_name = aclass.name[2:].lower()
if aclass.name in excluded_classes:
#print "Skipping %s" % aclass.name
continue
filename = os.path.join(output_dir, "_" + header_name + ".i")
enums_text = make_enums(aclass)
method_text = self.make_swig_methods(aclass)
@@ -37,25 +37,25 @@ public:
afile.write(text)
afile.close()
def make_swig_methods(self, aclass):
retval = ""
retval += """
%%pythonAppend %s "self._setOORInfo(self)"
%%pythonAppend %s() ""
%%typemap(out) %s*; // turn off this typemap
""" % (aclass.name, aclass.name, aclass.name)
for amethod in aclass.constructors:
retval += " %s%s;\n\n" % (amethod.name, amethod.argsstring)
retval += """
// Turn it back on again
%%typemap(out) %s* { $result = wxPyMake_wxObject($1, $owner); }
%%typemap(out) %s* { $result = wxPyMake_wxObject($1, $owner); }
""" % aclass.name
for amethod in aclass.methods:
retval += " %s %s%s;\n\n" % (amethod.return_type, amethod.name, amethod.argsstring)
return retval

41
docs/doxygen/scripts/write_info_tag.py Executable file
View File

@@ -0,0 +1,41 @@
#
# write_info_tag.py
# Write a key/value pair to an Info.plist file created by Doxygen
# while generating docsets.
#
# Author: Ian McInerney (https://github.com/imciner2)
import sys
import plistlib
# The first argument is the plist filename without the extension
fname = sys.argv[1] + ".plist"
# The second argument is the key to replace
key = sys.argv[2]
# The third argument is the value of the key
val = sys.argv[3]
# Handle boolean values
if val.lower() == "true":
val = True
elif val.lower() == "false":
val = False
if sys.version_info >= (3, 4, 0):
# Use the new API if python 3.4 is used
with open( fname, 'rb' ) as plist_file:
pl = plistlib.load( plist_file )
pl[key] = val
with open( fname, 'wb' ) as plist_file:
pl = plistlib.dump( pl, plist_file )
else:
# Use the old API otherwise (supports python 2.7 as well)
pl = plistlib.readPlist( fname )
pl[key] = val
plistlib.writePlist( pl, fname )

32
docs/gpl.txt
View File

@@ -1,12 +1,12 @@
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
675 Mass Ave, Cambridge, MA 02139, USA
Copyright (C) 1989, 1991 Free Software Foundation, Inc.,
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Preamble
Preamble
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
@@ -15,7 +15,7 @@ software--to make sure the software is free for all its users. This
General Public License applies to most of the Free Software
Foundation's software and to any other program whose authors commit to
using it. (Some other Free Software Foundation software is covered by
the GNU Library General Public License instead.) You can apply it to
the GNU Lesser General Public License instead.) You can apply it to
your programs, too.
When we speak of free software, we are referring to freedom, not
@@ -56,7 +56,7 @@ patent must be licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution and
modification follow.
GNU GENERAL PUBLIC LICENSE
GNU GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License applies to any program or other work which contains
@@ -255,7 +255,7 @@ make exceptions for this. Our decision will be guided by the two goals
of preserving the free status of all derivatives of our free software and
of promoting the sharing and reuse of software generally.
NO WARRANTY
NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
@@ -277,9 +277,9 @@ YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
END OF TERMS AND CONDITIONS
Appendix: How to Apply These Terms to Your New Programs
How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way to achieve this is to make it
@@ -291,7 +291,7 @@ convey the exclusion of warranty; and each file should have at least
the "copyright" line and a pointer to where the full notice is found.
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) 19yy <name of author>
Copyright (C) <year> <name of author>
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
@@ -303,16 +303,16 @@ the "copyright" line and a pointer to where the full notice is found.
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
You should have received a copy of the GNU General Public License along
with this program; if not, write to the Free Software Foundation, Inc.,
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
Also add information on how to contact you by electronic and paper mail.
If the program is interactive, make it output a short notice like this
when it starts in an interactive mode:
Gnomovision version 69, Copyright (C) 19yy name of author
Gnomovision version 69, Copyright (C) year name of author
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show c' for details.
@@ -335,5 +335,5 @@ necessary. Here is a sample; alter the names:
This General Public License does not permit incorporating your program into
proprietary programs. If your program is a subroutine library, you may
consider it more useful to permit linking proprietary applications with the
library. If this is what you want to do, use the GNU Library General
library. If this is what you want to do, use the GNU Lesser General
Public License instead of this License.

375
docs/gtk/install.md
View File

@@ -1,20 +1,8 @@
wxWidgets for GTK+ installation {#plat_gtk_install}
wxWidgets for GTK installation {#plat_gtk_install}
-------------------------------
[TOC]
IMPORTANT NOTE:
If you experience problems installing, please re-read these
instructions and other related files (todo.txt, bugs.txt and
osname.txt for your platform if it exists) carefully before
mailing wxwin-users or the author. Preferably, try to fix the
problem first and then send a patch to the author.
When sending bug reports tell us what version of wxWidgets you are
using (including the beta) and what compiler on what system. One
example: wxGTK 3.0.0, GCC 4.8.1, Fedora 19
Installation {#gtk_install}
============
@@ -23,7 +11,7 @@ The simplest case {#gtk_simple}
-------------------
If you compile wxWidgets on Linux for the first time and don't like to read
install instructions just do (in the base dir):
install instructions just do the following in wxWidgets directory:
> mkdir buildgtk
> cd buildgtk
@@ -44,73 +32,42 @@ If you want to remove wxWidgets on Unix you can do this:
> make uninstall
> ldconfig
Note that by default, GTK+ 2.x is used. GTK+ 3 can be specified
with --with-gtk=3.
Note that by default, GTK 3 is used. GTK 2 can be specified
with --with-gtk=2.
The expert case {#gtk_expert}
-----------------
If you use CMake, please see @ref overview_cmake for
building wxWidgets using it.
If you want to do some more serious cross-platform programming with wxWidgets,
such as for GTK+ and Motif, you can now build two complete libraries and use
them concurrently. To do this, create a separate directory for each build
of wxWidgets - you may also want to create different versions of wxWidgets
and test them concurrently. Most typically, this would be a version configured
with --enable-debug and one without.
For building three versions (one GTK+, one Motif and a debug version of the GTK
source) you'd do this:
Troubleshooting {#gtk_errors_simple}
---------------
mkdir buildmotif
cd buildmotif
../configure --with-motif
make
cd ..
IMPORTANT NOTE:
mkdir buildgtk
cd buildgtk
../configure --with-gtk
make
cd ..
When sending bug reports tell us what version of wxWidgets you are
using (including the beta) and what compiler on what system. One
example: wxGTK 3.0.5, GCC 9.3.1, Fedora 31.
mkdir buildgtkd
cd buildgtkd
../configure --with-gtk --enable-debug
make
cd ..
Note that you can install all those libraries concurrently, you just need to
pass the appropriate flags when using them.
The simplest errors {#gtk_errors_simple}
---------------------
For any configure errors: please look at config.log file which was generated
For any configure errors: please look at `config.log` file which was generated
during configure run, it usually contains some useful information.
configure reports, that you don't have GTK+ 1.2/2.0/3.0 installed although you
are very sure you have. Well, you have installed it, but you also have another
version of the GTK+ installed, which you may need to remove including other
versions of glib (and its headers). Or maybe you installed it in a non-default
location and configure can't find it there, so please check that your PATH
variable includes the path to the correct gtk-config/pkg-config. Also check
that your LD_LIBRARY_PATH or equivalent variable contains the path to GTK+
libraries if they were installed in a non-default location.
If configure reports that you don't have GTK installed, please
check that the appropriate _development_ package is available on
your system and not just the GTK libraries themselves. You can
use `pkg-config --modversion gtk+-3.0` (or `2.0`) to check that
this is the case.
You get errors from make: please use GNU make instead of the native make
program. Currently wxWidgets can be built only with GNU make, BSD make and
Solaris make. Other versions might work or not (any which don't have VPATH
support definitely won't).
Solaris make. Other versions might work or not.
You get errors during compilation: The reason is that you probably have a
broken compiler. GCC 2.8 and earlier versions and egcs are likely to cause
problems due to incomplete support for C++ and optimisation bugs. Best to use
GCC 2.95 or later.
You get immediate crashes when starting any sample or application: This may
be due to having compiled the library with different flags or
compiler options than your program or using the headers from a
different version of the library that is being used during
run-time. If you have multiple versions of wxWidgets installed,
please try uninstalling the ones you don't need and rebuilding.
You get immediate segfault when starting any sample or application: This is
either due to having compiled the library with different flags or options than
your program - typically you might have the `__WXDEBUG__` option set for the
library but not for your program - or due to using a compiler with optimisation
bugs.
The simplest program {#gtk_simple_app}
----------------------
@@ -119,96 +76,43 @@ Now create your super-application myfoo.cpp and compile anywhere with
g++ myfoo.cpp `wx-config --libs --cxxflags` -o myfoo
GUI libraries {#gtk_libs_gui}
---------------
wxWidgets/GTK+ requires the GTK+ library to be installed on your system. It has
to be a stable version, preferably GTK+ 2.x.y, where x is an even number.
GTK+ version 1.2 is highly discouraged, but if you decide to still use it,
please use version 1.2.10 (at least 1.2.3 is required, 1.2.7 is strongly recommended).
You can get the newest version of the GTK+ from the GTK+ homepage at:
http://www.gtk.org
We also mirror GTK+ at my ftp site. You'll find information about downloading
at my homepage.
Additional libraries {#gtk_libs_misc}
----------------------
wxWidgets/Gtk requires a thread library and X libraries known to work with
threads. This is the case on all commercial Unix-Variants and all
Linux-Versions that are based on glibc 2 except RedHat 5.0 which is broken in
many aspects. As of writing this, virtually all Linux distributions have
correct glibc 2 support.
You can disable thread support by running
./configure --disable-threads
make
su <type root password>
make install
ldconfig
exit
Building wxGTK on Cygwin {#gtk_cygwin}
--------------------------
The normal build instructions should work fine on Cygwin. The one difference
with Cygwin is that when using the "--enable-shared" configure option (which
is the default) the API is exported explicitly using __declspec(dllexport)
is the default) the API is exported explicitly using `__declspec(dllexport)`
rather than all global symbols being available.
This shouldn't make a difference using the library and should be a little
more efficient. However if an export attribute has been missed somewhere you
will see linking errors. If this happens then you can work around the
problem by setting LDFLAGS=-Wl,--export-all-symbols. Please also let us know
problem by setting `LDFLAGS=-Wl,--export-all-symbols`. Please also let us know
about it on the wx-dev mailing list.
Create your configuration {#gtk_config}
---------------------------
Usage:
./configure options
If you want to use system's C and C++ compiler,
set environment variables CC and CXX as
% setenv CC cc
% setenv CXX CC
% ./configure [options]
to see all the options please use:
./configure --help
It is recommended to build wxWidgets in another directory (maybe a
subdirectory of your wxWidgets installation) as this allows you to
have multiple configurations (for example, debug and release or GTK
and Motif) simultaneously.
General options {#gtk_options}
Configure options {#gtk_options}
-----------------
Given below are the commands to change the default behaviour,
i.e. if it says "--disable-threads" it means that threads
are enabled by default.
This section documents some of the most important configure
options. It is not exhaustive, please refer to `configure --help`
for the full list of options.
Normally, you won't have to choose a toolkit, because when
you download wxGTK, it will default to --with-gtk etc. But
if you use the git repository you have to choose a toolkit.
You must do this by running configure with either of:
Note that the options documented below are given in the form
indicating how to change the default behaviour, i.e. if it says
"--disable-optimise" it means that optimizations are enabled by
default.
--with-gtk=2 Use the GTK+ 2.0. Default.
--with-gtk=3 Use the GTK+ 3.
--with-gtk=1 Use the GTK+ 1.2.
All standard configure options are supported, e.g. you can choose
`--prefix` to select the directory to install the libraries to.
Also note that cross-compiling is fully supported, just specify
the `--host` option as usual (please refer to autoconf manual for
more information).
The following options handle the kind of library you want to build.
--disable-threads Compile without thread support.
The following options can be used to specify the kind and number
of libraries to build:
--disable-shared Do not create shared libraries, but
build static libraries instead.
@@ -217,16 +121,61 @@ The following options handle the kind of library you want to build.
of as several smaller libraries (which is
the default since wxWidgets 2.5.0).
--disable-optimise Do not optimise the code. Can
sometimes be useful for debugging
and is required on some architectures
such as Sun with gcc 2.8.X which
would otherwise produce segvs.
Options for third party dependencies: wxWidgets may use other
libraries present on the current system. For some of these
libraries, wxWidgets also provides built-in versions, that can be
linked into wx libraries themselves, which can be useful to
minimize external dependencies.
--enable-unicode Enable Unicode support.
--disable-sys-libs Don't use system libraries at all.
Use built-in ones when possible or
disable support for the corresponding
feature otherwise.
--enable-profile Add profiling info to the object
files. Currently broken, I think.
--without-libpng Disables PNG image format code.
Don't use libpng (although GTK
itself still uses it).
--without-libjpeg Disables JPEG image format code.
Don't use libjpeg.
--without-libtiff Disables TIFF image format code.
Don't use libtiff.
--without-expat Disable XML classes based on Expat parser.
Don't use expat library.
--without-liblzma Disable LZMA compression support.
Don't use liblzma.
--without-opengl Disable OpenGL integration with wxGLCanvas.
Don't use OpenGL or EGL libraries.
--disable-glcanvasegl Disable EGL support even if it is available
(it would be used if it is, by default).
--disable-mediactrl Disable wxMediaCtrl.
Don't use GStreamer libraries.
--disable-webview Disable wxWebView.
Don't use webkit2gtk and its multiple
dependencies.
Normally, you won't have to choose a toolkit, because configure
defaults to wxGTK anyhow. However you need to use this option to
explicitly specify the version of GTK to use, e.g.:
--with-gtk=3 Use GTK 3. Default.
--with-gtk=2 Use GTK 2.
--with-gtk=1 Use GTK 1.2. Obsolete.
Some other general compilation options:
--disable-optimise Do not optimise the code. Can be useful
for debugging but shouldn't be used
for production builds.
--disable-unicode Disable Unicode support. Not recommended.
--enable-no_rtti Enable compilation without creation of
C++ RTTI information in object files.
@@ -236,18 +185,7 @@ The following options handle the kind of library you want to build.
--enable-no_exceptions Enable compilation without creation of
C++ exception information in object files.
This will speed-up compilation and reduce
binary size. Also fewer crashes during the
actual compilation...
--enable-permissive Enable compilation without checking for strict
ANSI conformance. Useful to prevent the build
dying with errors as soon as you compile with
Solaris' ANSI-defying headers.
--enable-mem_tracing Add built-in memory tracing.
--enable-dmalloc Use the dmalloc memory debugger.
Read more at www.letters.com/dmalloc/
binary size.
--enable-debug_info Add debug info to object files and
executables for use with debuggers
@@ -267,22 +205,9 @@ The following options handle the kind of library you want to build.
option instead of --enable-debug_info/flag ones
separately.
Feature Options {#gtk_feature_options}
-----------------
When producing an executable that is linked statically with wxGTK
you'll be surprised at its immense size. This can sometimes be
drastically reduced by removing features from wxWidgets that
are not used in your program. The most relevant such features
are
--without-libpng Disables PNG image format code.
--without-libjpeg Disables JPEG image format code.
--without-libtiff Disables TIFF image format code.
--without-expat Disable XML classes based on Expat parser.
To reduce the final libraries (or executables, when linking
statically) size, many wxWidgets features may be disabled. Here
is a list of some of them:
--disable-pnm Disables PNM image format code.
@@ -302,8 +227,6 @@ are
--disable-clipboard Disables Clipboard.
--disable-serial Disables object instance serialisation.
--disable-streams Disables the wxStream classes.
--disable-file Disables the wxFile class.
@@ -314,82 +237,64 @@ are
--disable-validators Disables validators.
--disable-accel Disables accelerators support.
Apart from disabling certain features you can very often "strip"
the program of its debugging information resulting in a significant
reduction in size.
Please see the output of "./configure --help" for comprehensive list
of all configurable options.
Please remember that the full list of options can be seen in
`configure --help` output.
Compiling {#gtk_compling}
-----------
The following must be done in the base directory (e.g. ~/wxGTK
or ~/wxWin or whatever)
Building the libraries {#gtk_compling}
----------------------
Now the makefiles are created (by configure) and you can compile
the library by typing:
make
make yourself some coffee, as it will take some time. On an old
386SX possibly two weeks. During compilation, you'll get a few
warning messages depending in your compiler.
If you want to be more selective, you can change into a specific
directory and type "make" there.
After running configure, just run `make` from the same directory.
Building can take some time and it's strongly recommended to use
`--jobs` option with GNU make, e.g. `make -j8` if you have 8
logical CPU cores.
Then you may install the library and its header files under
/usr/local/include/wx and /usr/local/lib respectively. You
have to log in as root (i.e. run "su" and enter the root
password) and type
`/usr/local/include/wx` and `/usr/local/lib` respectively. You
have to perform the following command as root, using either `su`
or `sudo`:
make install
You can remove any traces of wxWidgets by typing
After installing, you can run `make clean` in the original
directory or just remove it entirely if you don't plan to build
wxWidgets again in the near future.
make uninstall
Note that installing the library is _not_ required and it can
also be used from the build directory by simply specifying the
full path to `wx-config` script located in it when building your
application.
If you want to save disk space by removing unnecessary
object-files:
make clean
Building your project {#gtk_new_project}
---------------------
in the various directories will do the work for you.
Creating a new Project {#gtk_new_project}
--------------------------
1. The first way uses the installed libraries and header files
automatically using wx-config
You need to use the compilation flags returned by `wx-config
--cxxflags` and linking flags returned by `wx-config --libs`,
which may be combined into a single invocation:
g++ myfoo.cpp `wx-config --cxxflags --libs` -o myfoo
Using this way, a make file for the minimal sample would look
like this
A simple makefile for a program using wxWidgets could be written
in the following way (note that if you are copying and pasting
this into your makefile, the leading spaces must be replaced by a
`TAB` character):
CXX = g++
```make
program: program.o
$(CXX) -o program program.o `wx-config --libs`
minimal: minimal.o
$(CXX) -o minimal minimal.o `wx-config --libs`
program.o: program.cpp
$(CXX) `wx-config --cxxflags` -c program.cpp -o program.o
minimal.o: minimal.cpp
$(CXX) `wx-config --cxxflags` -c minimal.cpp -o minimal.o
clean:
$(RM) program.o program
.PHONY: clean
```
clean:
rm -f *.o minimal
If your application uses only some of wxWidgets libraries, you can
specify required libraries when running wx-config. For example,
`wx-config --libs=html,core` will only output link command to link
with libraries required by core GUI classes and wxHTML classes. See
the manual for more information on the libraries.
2. The other way creates a project within the source code
directories of wxWidgets. For this endeavour, you'll need
GNU autoconf version 2.14 and add an entry to your Makefile.in
to the bottom of the configure.in script and run autoconf
and configure before you can type make.
If your application uses only some of wxWidgets libraries, you can
specify required libraries when running wx-config. For example,
`wx-config --libs=html,core` will only output link command to link
with libraries required by core GUI classes and wxHTML classes. See
the manual for more information on the libraries.

12
docs/gtk/nonnative.txt
View File

@@ -1,14 +1,8 @@
List of classes which should use their native GTK+ equivalents but don't:
- wxSearchCtrl
Should use GtkSearchEntry (GTK+ 3.6+)
- wxStatusBar:
Problem with multiple fields, GtkStatusbar only seems to support one pane
- wxTreeCtrl
Ryan Norton has implemented this
- wxListCtrl
Could be reimplemeted in terms of wxDataViewCtrl?
@@ -16,12 +10,8 @@ List of classes which should use their native GTK+ equivalents but don't:
Not possible because GTK's GtkHPane and GtkVPane
only support either horizontal or vertical panes
(therefore their names) whereas wxSplitterWindow
supports both and can even change orientiation at
supports both and can even change orientation at
runtime.
- wxDatePickerCtrl
- wxCalendarCtrl
Use GtkCalendar
- wxWizard
Can GtkAssistant be used?

134
docs/gtk/overview.md
View File

@@ -1,134 +0,0 @@
# wxWidgets on the GNOME Desktop {#plat_gtk_overview}
wxWidgets is a C++ cross-platform GUI library, whose distintive feature is the
use of native calls and native widgets on the respective platform, i.e. an
application compiled for the Linux platform will use the [GTK+][] library for
displaying the various widgets. There is also a version ("port") of wxWidgets
which uses the Motif toolkit for displaying its widgets (this port is commonly
referred to as wxMotif) and another one, which only uses X11 calls and which
draws its widgets entirely itself, without using any outside library. This port
is called wxX11 or sometimes more generally wxUniv (short for wxUniversal),
since this widget set (implemented entirely within wxWidgets) is available
wherever wxWidgets is available. Since this short overview is mainly about how
to write wxWidgets applications for the [GNOME][] desktop, I will focus on the
GTK+ port, which is generally referred to as wxGTK.
wxGTK still supports the old version GTK+ 1.2, but it now defaults to the
uptodate version GTK+ 2.X, which is the basis for the current GNOME desktop. By
way of using GTK+ 2.X and its underlying text rendering library [Pango][], wxGTK
fully supports the Unicode character set and it can render text in any language
and script, that is supported by Pango.
[GTK+]: http://www.gtk.org/
[GNOME]: https://www.gnome.org/
[Pango]: http://www.pango.org/
## Design Principles
The three main design goals of the wxWidgets library are portability across the
supported platforms, complete integration with the supported platforms and a
broad range of functionality covering most aspects of GUI and non-GUI
application programming. Sometimes, various aspects of these design goals
contradict each other and this holds true especially for the Linux platform
which – from the point of view of the desktop environment integration – is
lagging behind the other two major desktops (Windows and OS X) mostly because of
the schism between the GTK+ based GNOME desktop and the [Qt][] based [KDE][]
desktop. So far, the typical wxWidgets user targeted Windows, maybe OS X and
Linux _in general_, so the aim was to make wxGTK applications run as well as
possible on as many versions of Linux as possible, including those using the KDE
environment. Luckily, most of these distributions included the GTK+ library (for
running applications like the GIMP, GAIM, Evolution or Mozilla) whereas the
GNOME libraries were not always installed by default. Also, the GNOME libraries
didn't really offer substantial value so that the hassle of installing them was
hardly justified. Therefore, much effort was spent on making wxGTK fully
functional without relying on the GNOME libraries, mostly by reimplementing as
much as sensible of the missing functionality. This included a usable file
selection dialog, a printing system for PostScript output, code for querying
MIME-types and file-icon associations, classes for storing application
preferences and configurations, the possibility to display mini-apps in the
taskbar, a full-featured HTML based help system etc. With all that in place you
can write a pretty fully featured wxWidgets application on an old Linux system
with little more installed than X11 and GTK+.
[Qt]: http://www.qt.io/
[KDE]: https://www.kde.org/
## Recent Developments
Recently, several key issues have been addressed by the GNOME project. Sometimes
integrated into the newest GTK+ releases (such as the file selecter), sometimes
as part of the GNOME libraries (such as the new printing system with Pango
integration or the mime-types handling in gnome-vfs), sometimes as outside
projects (such as the media/video backend based on the [Gstreamer][] project).
Also, care has been taken to unify the look and feel of GNOME applications by
writing down a number of rules (modestly called
["Human Interface Guidelines"][GNOME-HIG]) and more and more decisions are taken
in a desktop neutral way (for both GNOME and KDE), mostly as part of the
[FreeDesktop][] initiative. This development together with the rising number of
OpenSource projects using wxWidgets mainly for the Linux and more specifically
GNOME desktop has led to a change of direction within the wxWidgets project, now
working on making more use of GNOME features when present. The general idea is
to call the various GNOME libraries if they are present and to offer a
reasonable fallback if not. I'll detail on the various methods chosen below:
[Gstreamer]: http://gstreamer.freedesktop.org/
[GNOME-HIG]: http://developer.gnome.org/projects/gup/hig
[FreeDesktop]: http://www.freedesktop.org/
## Printing System
The old printing system ....
## MIME-type Handling
The old mime-type system used to simply query some files stored in "typical"
locations for the respective desktop environment. Since both the format and the
location of these files changed rather frequently, this system was never fully
working as desired for reading the MIME-types and it never worked at all for
writing MIME-types or icon/file associations. ...
## File Dialogs
Previously, wxGTK application made use of a file dialog written in wxWidgets
itself, since the default GTK+ file dialog was simplistic to say the least. This
has changed with version GTK+ 2.4, where a nice and powerful dialog has been
added. wxGTK is using it now.
## File Configuration and Preferences
The usual Unix way of saving file configuration and preferences is to write and
read a so called "dot-file", basically a text file in a user's home directory
starting with a dot. This was deemed insufficient by the GNOME desktop project
and therefore they introduced the so called GConf system, for storing and
retrieving application and sessions information....
## Results and Discussion
One of wxWidgets' greatest merits is the ability to write an application that
not only runs on different operating systems but especially under Linux even on
rather old systems with only a minimal set of libraries installed – using a
single application binary. This was possible since most of the relevant
functionality was either located in the only required library (GTK+) or was
implemented within wxWidgets. Recent development outside the actual GTK+ project
has made it necessary to rethink this design and make use of other projects'
features in order to stay uptodate with current techological trends. Therefore,
a system was implemented within wxWidgets that queries the system at runtime
about various libraries and makes use of their features whenever possible, but
falls back to a reasonable solution if not. The result is that you can create
and distribute application binaries that run on old Linux systems and integrate
fully with modern desktops, if they are available. This is not currently
possible with any other software.
Copyright 2004 © Robert Roebling, MD. No reprint permitted without written prior
authorisation. Last modified 14/11/04.
## About the Author
Robert Roebling works as a medical doctor in the Department of Neurology at the
University clinic of Ulm in Germany. He has studied Computer Sciences for a few
semesters and is involved in the wxWidgets projects since about 1996. He has
started and written most of wxGTK port (beginning with GTK+ around 0.9) and has
contributed to quite a number projects within wxWidgets, ranging from the image
classes to Unicode support to making both the Windows and the GTK+ ports work on
embedded platform (mostly PDAs). He is happily married, has two children and
never has time.

57
docs/gtk/readme.txt
View File

@@ -1,35 +1,25 @@
Welcome to wxWidgets for GTK+
-----------------------------
Welcome to wxWidgets for GTK
----------------------------
You have downloaded the GTK+ port of the wxWidgets GUI library.
You have downloaded the GTK port of the wxWidgets GUI library.
It is required to use at least GTK+ 2.6 and some features are
only available when using GTK+ 2.10 or higher. Note that even if
you compile wxWidgets against a later GTK+ version, your application
will still work with older GTK+ version down to version 2.6 as wxWidgets
tests for the presence of newer features at run-time and it
will fall back to a generic implementation if these features
are not present in the GTK+ version used.
This port works best with GTK 3, but also supports versions as
old as GTK 2.6 (although some features are only available when
using GTK+ 2.10 or higher). Note that even if you compile
wxWidgets against a later GTK version, your application will
still work with older GTK versions with the same major version
as wxWidgets tests for the presence of newer features at run-time
and it will fall back to a generic implementation if these
features are not present in the GTK version used.
wxWidgets 2.9.4 adds support for GTK+ 3, which can be enabled
with configure option --with-gtk=3.
wxWidgets 2.8 still supports GTK+ 1.2, but no development
is done on that port anymore and support for GTK+ 1.2 will
probably be dropped entirely. Indeed, one of the major steps
in the development cycle leading up to wxWidgets 2.8 was
that the codebase for GTK+ 1.2 and GTK+ 2.0 were separated
so that improvements and clean-ups to the GTK+ 2.0 port
could be done without caring for GTK+ 1.2.
More info about the wxWidgets project (including all the
More information about the wxWidgets project (including all the
other ports and version of wxWidgets) can be found at the
main wxWidgets homepage at:
https://www.wxwidgets.org/
Information on how to install can be found in the file
INSTALL.txt, but if you cannot wait, this should work on
install.md, but if you cannot wait, this should work on
many systems:
mkdir build_gtk
@@ -40,10 +30,8 @@ many systems:
make install
ldconfig
In order to use wxGTK with GTK 1.2 you need to use --with-gtk=1
configure option. To build the library in Unicode mode (all
strings will be wide strings and so on) you need to configure
with GTK 2.0 and add --enable-unicode.
In order to use wxGTK with GTK 2 you need to use --with-gtk=2
configure option.
Please note that it is strongly advised to build the library in
a separate directory, as shown above, as it allows you to have
@@ -51,21 +39,8 @@ different builds of it (for example with and without debug) in
parallel. If you build in the source directory, don't forget to
do "make clean" before changing the configuration!
When you run into problems, please read the INSTALL.txt and
follow those instructions. If you still don't have any success,
please send a bug report to one of our mailing list, INCLUDING
A DESCRIPTION OF YOUR SYSTEM AND YOUR PROBLEM, SUCH AS YOUR
VERSION OF GTK, WXGTK, WHAT DISTRIBUTION YOU USE AND WHAT ERROR
WAS REPORTED. I know this has no effect, but I tried...
Please send problems concerning installation, feature requests,
bug reports or comments to the wxWidgets users list. These can
be found at https://www.wxwidgets.org/support/mailing-lists/
wxWidgets doesn't come with any guarantee whatsoever. It
might crash your harddisk or destroy your monitor. It doesn't
claim to be suitable for any special or general purpose.
Regards,
Robert Roebling
Please see the manual for further information.

2
docs/index.htm
View File

@@ -127,7 +127,7 @@
<h1>Contributor Notes</h1>
<p>Contributor notes contain information useful only to wxWidgets developers
for the maintainance of the project:</p>
for the maintenance of the project:</p>
<ul>
<li><a href="contributing/">Index of Contributor Notes</a></li>

2
docs/ios/install.md
View File

@@ -5,7 +5,7 @@ wxiOS is far from a full supported port, but can be used
as base for simple applications and future improvements.
It requires Xcode with iOS SDK 9.0 or later. Xcode is available
for free in the OS X app store.
for free in the macOS app store.
To build wxiOS you should use Xcode to open the minimal samples
Xcode project file located at:

676
docs/lgpl.txt
View File

@@ -1,171 +1,155 @@
GNU LIBRARY GENERAL PUBLIC LICENSE
==================================
Version 2, June 1991
GNU LIBRARY GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright (C) 1991 Free Software Foundation, Inc.
675 Mass Ave, Cambridge, MA 02139, USA
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
[This is the first released version of the library GPL. It is
numbered 2 because it goes with version 2 of the ordinary GPL.]
Preamble
Preamble
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General
Public Licenses are intended to guarantee your freedom to share
and change free software--to make sure the software is free for
all its users.
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
Licenses are intended to guarantee your freedom to share and change
free software--to make sure the software is free for all its users.
This license, the Library General Public License, applies to
some specially designated Free Software Foundation software, and
to any other libraries whose authors decide to use it. You can
use it for your libraries, too.
This license, the Library General Public License, applies to some
specially designated Free Software Foundation software, and to any
other libraries whose authors decide to use it. You can use it for
your libraries, too.
When we speak of free software, we are referring to freedom, not
price. Our General Public Licenses are designed to make sure
that you have the freedom to distribute copies of free software
(and charge for this service if you wish), that you receive
source code or can get it if you want it, that you can change
the software or use pieces of it in new free programs; and that
you know you can do these things.
When we speak of free software, we are referring to freedom, not
price. Our General Public Licenses are designed to make sure that you
have the freedom to distribute copies of free software (and charge for
this service if you wish), that you receive source code or can get it
if you want it, that you can change the software or use pieces of it
in new free programs; and that you know you can do these things.
To protect your rights, we need to make restrictions that forbid
anyone to deny you these rights or to ask you to surrender the
rights. These restrictions translate to certain responsibilities
for you if you distribute copies of the library, or if you
modify it.
To protect your rights, we need to make restrictions that forbid
anyone to deny you these rights or to ask you to surrender the rights.
These restrictions translate to certain responsibilities for you if
you distribute copies of the library, or if you modify it.
For example, if you distribute copies of the library, whether
gratis or for a fee, you must give the recipients all the rights
that we gave you. You must make sure that they, too, receive or
can get the source code. If you link a program with the
library, you must provide complete object files to the
recipients so that they can relink them with the library, after
making changes to the library and recompiling it. And you must
show them these terms so they know their rights.
For example, if you distribute copies of the library, whether gratis
or for a fee, you must give the recipients all the rights that we gave
you. You must make sure that they, too, receive or can get the source
code. If you link a program with the library, you must provide
complete object files to the recipients so that they can relink them
with the library, after making changes to the library and recompiling
it. And you must show them these terms so they know their rights.
Our method of protecting your rights has two steps: (1)
copyright the library, and (2) offer you this license which
gives you legal permission to copy, distribute and/or modify the
library.
Our method of protecting your rights has two steps: (1) copyright
the library, and (2) offer you this license which gives you legal
permission to copy, distribute and/or modify the library.
Also, for each distributor's protection, we want to make certain
that everyone understands that there is no warranty for this
free library. If the library is modified by someone else and
passed on, we want its recipients to know that what they have is
not the original version, so that any problems introduced by
others will not reflect on the original authors' reputations.
Finally, any free program is threatened constantly by software
patents. We wish to avoid the danger that companies
distributing free software will individually obtain patent
licenses, thus in effect transforming the program into
proprietary software. To prevent this, we have made it clear
that any patent must be licensed for everyone's free use or not
licensed at all.
Also, for each distributor's protection, we want to make certain
that everyone understands that there is no warranty for this free
library. If the library is modified by someone else and passed on, we
want its recipients to know that what they have is not the original
version, so that any problems introduced by others will not reflect on
the original authors' reputations.
Finally, any free program is threatened constantly by software
patents. We wish to avoid the danger that companies distributing free
software will individually obtain patent licenses, thus in effect
transforming the program into proprietary software. To prevent this,
we have made it clear that any patent must be licensed for everyone's
free use or not licensed at all.
Most GNU software, including some libraries, is covered by the
ordinary GNU General Public License, which was designed for
utility programs. This license, the GNU Library General Public
License, applies to certain designated libraries. This license
is quite different from the ordinary one; be sure to read it in
full, and don't assume that anything in it is the same as in the
ordinary license.
Most GNU software, including some libraries, is covered by the ordinary
GNU General Public License, which was designed for utility programs. This
license, the GNU Library General Public License, applies to certain
designated libraries. This license is quite different from the ordinary
one; be sure to read it in full, and don't assume that anything in it is
the same as in the ordinary license.
The reason we have a separate public license for some libraries
is that they blur the distinction we usually make between
modifying or adding to a program and simply using it. Linking a
program with a library, without changing the library, is in some
sense simply using the library, and is analogous to running a
utility program or application program. However, in a textual
and legal sense, the linked executable is a combined work, a
derivative of the original library, and the ordinary General
Public License treats it as such.
The reason we have a separate public license for some libraries is that
they blur the distinction we usually make between modifying or adding to a
program and simply using it. Linking a program with a library, without
changing the library, is in some sense simply using the library, and is
analogous to running a utility program or application program. However, in
a textual and legal sense, the linked executable is a combined work, a
derivative of the original library, and the ordinary General Public License
treats it as such.
Because of this blurred distinction, using the ordinary General
Public License for libraries did not effectively promote
software sharing, because most developers did not use the
libraries. We concluded that weaker conditions might promote
sharing better.
Because of this blurred distinction, using the ordinary General
Public License for libraries did not effectively promote software
sharing, because most developers did not use the libraries. We
concluded that weaker conditions might promote sharing better.
However, unrestricted linking of non-free programs would deprive
the users of those programs of all benefit from the free status
of the libraries themselves. This Library General Public
License is intended to permit developers of non-free programs to
use free libraries, while preserving your freedom as a user of
such programs to change the free libraries that are incorporated
in them. (We have not seen how to achieve this as regards
changes in header files, but we have achieved it as regards
changes in the actual functions of the Library.) The hope is
that this will lead to faster development of free libraries.
However, unrestricted linking of non-free programs would deprive the
users of those programs of all benefit from the free status of the
libraries themselves. This Library General Public License is intended to
permit developers of non-free programs to use free libraries, while
preserving your freedom as a user of such programs to change the free
libraries that are incorporated in them. (We have not seen how to achieve
this as regards changes in header files, but we have achieved it as regards
changes in the actual functions of the Library.) The hope is that this
will lead to faster development of free libraries.
The precise terms and conditions for copying, distribution and
modification follow. Pay close attention to the difference
between a "work based on the library" and a "work that uses the
library". The former contains code derived from the library,
while the latter only works together with the library.
The precise terms and conditions for copying, distribution and
modification follow. Pay close attention to the difference between a
"work based on the library" and a "work that uses the library". The
former contains code derived from the library, while the latter only
works together with the library.
Note that it is possible for a library to be covered by the
ordinary General Public License rather than by this special one.
Note that it is possible for a library to be covered by the ordinary
General Public License rather than by this special one.
GNU LIBRARY GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
GNU LIBRARY GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License Agreement applies to any software library which
contains a notice placed by the copyright holder or other authorized
party saying it may be distributed under the terms of this Library
General Public License (also called "this License"). Each licensee is
addressed as "you".
0. This License Agreement applies to any software library which
contains a notice placed by the copyright holder or other
authorized party saying it may be distributed under the terms of
this Library General Public License (also called "this
License"). Each licensee is addressed as "you".
A "library" means a collection of software functions and/or data
prepared so as to be conveniently linked with application programs
(which use some of those functions and data) to form executables.
A "library" means a collection of software functions and/or data
prepared so as to be conveniently linked with application
programs (which use some of those functions and data) to form
executables.
The "Library", below, refers to any such software library or work
which has been distributed under these terms. A "work based on the
Library" means either the Library or any derivative work under
copyright law: that is to say, a work containing the Library or a
portion of it, either verbatim or with modifications and/or translated
straightforwardly into another language. (Hereinafter, translation is
included without limitation in the term "modification".)
The "Library", below, refers to any such software library or
work which has been distributed under these terms. A "work
based on the Library" means either the Library or any derivative
work under copyright law: that is to say, a work containing the
Library or a portion of it, either verbatim or with
modifications and/or translated straightforwardly into another
language. (Hereinafter, translation is included without
limitation in the term "modification".)
"Source code" for a work means the preferred form of the work for
making modifications to it. For a library, complete source code means
all the source code for all modules it contains, plus any associated
interface definition files, plus the scripts used to control compilation
and installation of the library.
"Source code" for a work means the preferred form of the work
for making modifications to it. For a library, complete source
code means all the source code for all modules it contains, plus
any associated interface definition files, plus the scripts used
to control compilation and installation of the library.
Activities other than copying, distribution and modification are
not covered by this License; they are outside its scope. The
act of running a program using the Library is not restricted,
and output from such a program is covered only if its contents
constitute a work based on the Library (independent of the use
of the Library in a tool for writing it). Whether that is true
depends on what the Library does and what the program that uses
the Library does.
Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of
running a program using the Library is not restricted, and output from
such a program is covered only if its contents constitute a work based
on the Library (independent of the use of the Library in a tool for
writing it). Whether that is true depends on what the Library does
and what the program that uses the Library does.
1. You may copy and distribute verbatim copies of the Library's
complete source code as you receive it, in any medium, provided
that you conspicuously and appropriately publish on each copy an
appropriate copyright notice and disclaimer of warranty; keep
intact all the notices that refer to this License and to the
absence of any warranty; and distribute a copy of this License
along with the Library.
1. You may copy and distribute verbatim copies of the Library's
complete source code as you receive it, in any medium, provided that
you conspicuously and appropriately publish on each copy an
appropriate copyright notice and disclaimer of warranty; keep intact
all the notices that refer to this License and to the absence of any
warranty; and distribute a copy of this License along with the
Library.
You may charge a fee for the physical act of transferring a
copy, and you may at your option offer warranty protection in
exchange for a fee.
2. You may modify your copy or copies of the Library or any
portion of it, thus forming a work based on the Library, and
copy and distribute such modifications or work under the terms
of Section 1 above, provided that you also meet all of these
conditions:
You may charge a fee for the physical act of transferring a copy,
and you may at your option offer warranty protection in exchange for a
fee.
2. You may modify your copy or copies of the Library or any portion
of it, thus forming a work based on the Library, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:
a) The modified work must itself be a software library.
@@ -191,108 +175,100 @@ conditions:
root function must still compute square roots.)
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the
Library, and can be reasonably considered independent and
separate works in themselves, then this License, and its terms,
do not apply to those sections when you distribute them as
separate works. But when you distribute the same sections as
part of a whole which is a work based on the Library, the
distribution of the whole must be on the terms of this License,
whose permissions for other licensees extend to the entire
whole, and thus to each and every part regardless of who wrote
identifiable sections of that work are not derived from the Library,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But when you
distribute the same sections as part of a whole which is a work based
on the Library, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote
it.
Thus, it is not the intent of this section to claim rights or
contest your rights to work written entirely by you; rather, the
intent is to exercise the right to control the distribution of
derivative or collective works based on the Library.
Thus, it is not the intent of this section to claim rights or contest
your rights to work written entirely by you; rather, the intent is to
exercise the right to control the distribution of derivative or
collective works based on the Library.
In addition, mere aggregation of another work not based on the
Library with the Library (or with a work based on the Library)
on a volume of a storage or distribution medium does not bring
the other work under the scope of this License.
In addition, mere aggregation of another work not based on the Library
with the Library (or with a work based on the Library) on a volume of
a storage or distribution medium does not bring the other work under
the scope of this License.
3. You may opt to apply the terms of the ordinary GNU General
Public License instead of this License to a given copy of the
Library. To do this, you must alter all the notices that refer
to this License, so that they refer to the ordinary GNU General
Public License, version 2, instead of to this License. (If a
newer version than version 2 of the ordinary GNU General Public
License has appeared, then you can specify that version instead
if you wish.) Do not make any other change in these notices.
Once this change is made in a given copy, it is irreversible for
that copy, so the ordinary GNU General Public License applies to
all subsequent copies and derivative works made from that copy.
3. You may opt to apply the terms of the ordinary GNU General Public
License instead of this License to a given copy of the Library. To do
this, you must alter all the notices that refer to this License, so
that they refer to the ordinary GNU General Public License, version 2,
instead of to this License. (If a newer version than version 2 of the
ordinary GNU General Public License has appeared, then you can specify
that version instead if you wish.) Do not make any other change in
these notices.
Once this change is made in a given copy, it is irreversible for
that copy, so the ordinary GNU General Public License applies to all
subsequent copies and derivative works made from that copy.
This option is useful when you wish to copy part of the code of
This option is useful when you wish to copy part of the code of
the Library into a program that is not a library.
4. You may copy and distribute the Library (or a portion or
derivative of it, under Section 2) in object code or executable
form under the terms of Sections 1 and 2 above provided that you
accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of
Sections 1 and 2 above on a medium customarily used for software
interchange.
4. You may copy and distribute the Library (or a portion or
derivative of it, under Section 2) in object code or executable form
under the terms of Sections 1 and 2 above provided that you accompany
it with the complete corresponding machine-readable source code, which
must be distributed under the terms of Sections 1 and 2 above on a
medium customarily used for software interchange.
If distribution of object code is made by offering access to
copy from a designated place, then offering equivalent access to
copy the source code from the same place satisfies the
requirement to distribute the source code, even though third
parties are not compelled to copy the source along with the
object code.
If distribution of object code is made by offering access to copy
from a designated place, then offering equivalent access to copy the
source code from the same place satisfies the requirement to
distribute the source code, even though third parties are not
compelled to copy the source along with the object code.
5. A program that contains no derivative of any portion of the
Library, but is designed to work with the Library by being
compiled or linked with it, is called a "work that uses the
Library". Such a work, in isolation, is not a derivative work
of the Library, and therefore falls outside the scope of this
License.
5. A program that contains no derivative of any portion of the
Library, but is designed to work with the Library by being compiled or
linked with it, is called a "work that uses the Library". Such a
work, in isolation, is not a derivative work of the Library, and
therefore falls outside the scope of this License.
However, linking a "work that uses the Library" with the Library
creates an executable that is a derivative of the Library
(because it contains portions of the Library), rather than a
"work that uses the library". The executable is therefore
covered by this License. Section 6 states terms for distribution
of such executables.
However, linking a "work that uses the Library" with the Library
creates an executable that is a derivative of the Library (because it
contains portions of the Library), rather than a "work that uses the
library". The executable is therefore covered by this License.
Section 6 states terms for distribution of such executables.
When a "work that uses the Library" uses material from a header
file that is part of the Library, the object code for the work
may be a derivative work of the Library even though the source
code is not. Whether this is true is especially significant if
the work can be linked without the Library, or if the work is
itself a library. The threshold for this to be true is not
precisely defined by law.
When a "work that uses the Library" uses material from a header file
that is part of the Library, the object code for the work may be a
derivative work of the Library even though the source code is not.
Whether this is true is especially significant if the work can be
linked without the Library, or if the work is itself a library. The
threshold for this to be true is not precisely defined by law.
If such an object file uses only numerical parameters, data
structure layouts and accessors, and small macros and small
inline functions (ten lines or less in length), then the use of
the object file is unrestricted, regardless of whether it is
legally a derivative work. (Executables containing this object
code plus portions of the Library will still fall under Section
6.)
If such an object file uses only numerical parameters, data
structure layouts and accessors, and small macros and small inline
functions (ten lines or less in length), then the use of the object
file is unrestricted, regardless of whether it is legally a derivative
work. (Executables containing this object code plus portions of the
Library will still fall under Section 6.)
Otherwise, if the work is a derivative of the Library, you may
distribute the object code for the work under the terms of
Section 6. Any executables containing that work also fall under
Section 6, whether or not they are linked directly with the
Library itself.
6. As an exception to the Sections above, you may also compile
or link a "work that uses the Library" with the Library to
produce a work containing portions of the Library, and
distribute that work under terms of your choice, provided that
the terms permit modification of the work for the customer's own
use and reverse engineering for debugging such modifications.
Otherwise, if the work is a derivative of the Library, you may
distribute the object code for the work under the terms of Section 6.
Any executables containing that work also fall under Section 6,
whether or not they are linked directly with the Library itself.
6. As an exception to the Sections above, you may also compile or
link a "work that uses the Library" with the Library to produce a
work containing portions of the Library, and distribute that work
under terms of your choice, provided that the terms permit
modification of the work for the customer's own use and reverse
engineering for debugging such modifications.
You must give prominent notice with each copy of the work that
the Library is used in it and that the Library and its use are
covered by this License. You must supply a copy of this
License. If the work during execution displays copyright
notices, you must include the copyright notice for the Library
among them, as well as a reference directing the user to the
copy of this License. Also, you must do one of these things:
You must give prominent notice with each copy of the work that the
Library is used in it and that the Library and its use are covered by
this License. You must supply a copy of this License. If the work
during execution displays copyright notices, you must include the
copyright notice for the Library among them, as well as a reference
directing the user to the copy of this License. Also, you must do one
of these things:
a) Accompany the work with the complete corresponding
machine-readable source code for the Library including whatever
@@ -318,28 +294,27 @@ copy of this License. Also, you must do one of these things:
d) Verify that the user has already received a copy of these
materials or that you have already sent this user a copy.
For an executable, the required form of the "work that uses the
For an executable, the required form of the "work that uses the
Library" must include any data and utility programs needed for
reproducing the executable from it. However, as a special
exception, the source code distributed need not include anything
that is normally distributed (in either source or binary form)
with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs, unless that
component itself accompanies the executable.
reproducing the executable from it. However, as a special exception,
the source code distributed need not include anything that is normally
distributed (in either source or binary form) with the major
components (compiler, kernel, and so on) of the operating system on
which the executable runs, unless that component itself accompanies
the executable.
It may happen that this requirement contradicts the license
It may happen that this requirement contradicts the license
restrictions of other proprietary libraries that do not normally
accompany the operating system. Such a contradiction means you
cannot use both them and the Library together in an executable
that you distribute.
7. You may place library facilities that are a work based on the
Library side-by-side in a single library together with other
library facilities not covered by this License, and distribute
such a combined library, provided that the separate distribution
of the work based on the Library and of the other library
facilities is otherwise permitted, and provided that you do
these two things:
accompany the operating system. Such a contradiction means you cannot
use both them and the Library together in an executable that you
distribute.
7. You may place library facilities that are a work based on the
Library side-by-side in a single library together with other library
facilities not covered by this License, and distribute such a combined
library, provided that the separate distribution of the work based on
the Library and of the other library facilities is otherwise
permitted, and provided that you do these two things:
a) Accompany the combined library with a copy of the same work
based on the Library, uncombined with any other library
@@ -350,108 +325,99 @@ these two things:
that part of it is a work based on the Library, and explaining
where to find the accompanying uncombined form of the same work.
8. You may not copy, modify, sublicense, link with, or
distribute the Library except as expressly provided under this
License. Any attempt otherwise to copy, modify, sublicense,
link with, or distribute the Library is void, and will
automatically terminate your rights under this License.
However, parties who have received copies, or rights, from you
under this License will not have their licenses terminated so
long as such parties remain in full compliance.
8. You may not copy, modify, sublicense, link with, or distribute
the Library except as expressly provided under this License. Any
attempt otherwise to copy, modify, sublicense, link with, or
distribute the Library is void, and will automatically terminate your
rights under this License. However, parties who have received copies,
or rights, from you under this License will not have their licenses
terminated so long as such parties remain in full compliance.
9. You are not required to accept this License, since you have
not signed it. However, nothing else grants you permission to
modify or distribute the Library or its derivative works. These
actions are prohibited by law if you do not accept this
License. Therefore, by modifying or distributing the Library
(or any work based on the Library), you indicate your acceptance
of this License to do so, and all its terms and conditions for
copying, distributing or modifying the Library or works based on
it.
9. You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to modify or
distribute the Library or its derivative works. These actions are
prohibited by law if you do not accept this License. Therefore, by
modifying or distributing the Library (or any work based on the
Library), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying
the Library or works based on it.
10. Each time you redistribute the Library (or any work based on
the Library), the recipient automatically receives a license
from the original licensor to copy, distribute, link with or
modify the Library subject to these terms and conditions. You
may not impose any further restrictions on the recipients'
exercise of the rights granted herein. You are not responsible
for enforcing compliance by third parties to this License.
11. If, as a consequence of a court judgment or allegation of
patent infringement or for any other reason (not limited to
patent issues), conditions are imposed on you (whether by court
order, agreement or otherwise) that contradict the conditions of
this License, they do not excuse you from the conditions of this
License. If you cannot distribute so as to satisfy
simultaneously your obligations under this License and any other
pertinent obligations, then as a consequence you may not
distribute the Library at all. For example, if a patent license
would not permit royalty-free redistribution of the Library by
all those who receive copies directly or indirectly through you,
then the only way you could satisfy both it and this License
would be to refrain entirely from distribution of the Library.
10. Each time you redistribute the Library (or any work based on the
Library), the recipient automatically receives a license from the
original licensor to copy, distribute, link with or modify the Library
subject to these terms and conditions. You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties to
this License.
11. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot
distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you
may not distribute the Library at all. For example, if a patent
license would not permit royalty-free redistribution of the Library by
all those who receive copies directly or indirectly through you, then
the only way you could satisfy both it and this License would be to
refrain entirely from distribution of the Library.
If any portion of this section is held invalid or unenforceable
under any particular circumstance, the balance of the section is
intended to apply, and the section as a whole is intended to
apply in other circumstances.
If any portion of this section is held invalid or unenforceable under any
particular circumstance, the balance of the section is intended to apply,
and the section as a whole is intended to apply in other circumstances.
It is not the purpose of this section to induce you to infringe
any patents or other property right claims or to contest
validity of any such claims; this section has the sole purpose
of protecting the integrity of the free software distribution
system which is implemented by public license practices. Many
people have made generous contributions to the wide range of
software distributed through that system in reliance on
consistent application of that system; it is up to the
author/donor to decide if he or she is willing to distribute
software through any other system and a licensee cannot impose
that choice.
It is not the purpose of this section to induce you to infringe any
patents or other property right claims or to contest validity of any
such claims; this section has the sole purpose of protecting the
integrity of the free software distribution system which is
implemented by public license practices. Many people have made
generous contributions to the wide range of software distributed
through that system in reliance on consistent application of that
system; it is up to the author/donor to decide if he or she is willing
to distribute software through any other system and a licensee cannot
impose that choice.
This section is intended to make thoroughly clear what is
believed to be a consequence of the rest of this License.
This section is intended to make thoroughly clear what is believed to
be a consequence of the rest of this License.
12. If the distribution and/or use of the Library is restricted
in certain countries either by patents or by copyrighted
interfaces, the original copyright holder who places the Library
under this License may add an explicit geographical distribution
limitation excluding those countries, so that distribution is
permitted only in or among countries not thus excluded. In such
case, this License incorporates the limitation as if written in
the body of this License.
12. If the distribution and/or use of the Library is restricted in
certain countries either by patents or by copyrighted interfaces, the
original copyright holder who places the Library under this License may add
an explicit geographical distribution limitation excluding those countries,
so that distribution is permitted only in or among countries not thus
excluded. In such case, this License incorporates the limitation as if
written in the body of this License.
13. The Free Software Foundation may publish revised and/or new
versions of the Library General Public License from time to
time. Such new versions will be similar in spirit to the present
version, but may differ in detail to address new problems or
concerns.
13. The Free Software Foundation may publish revised and/or new
versions of the Library General Public License from time to time.
Such new versions will be similar in spirit to the present version,
but may differ in detail to address new problems or concerns.
Each version is given a distinguishing version number. If the
Library specifies a version number of this License which applies
to it and "any later version", you have the option of following
the terms and conditions either of that version or of any later
version published by the Free Software Foundation. If the
Library does not specify a license version number, you may
choose any version ever published by the Free Software
Foundation.
Each version is given a distinguishing version number. If the Library
specifies a version number of this License which applies to it and
"any later version", you have the option of following the terms and
conditions either of that version or of any later version published by
the Free Software Foundation. If the Library does not specify a
license version number, you may choose any version ever published by
the Free Software Foundation.
14. If you wish to incorporate parts of the Library into other free
programs whose distribution conditions are incompatible with these,
write to the author to ask for permission. For software which is
copyrighted by the Free Software Foundation, write to the Free
Software Foundation; we sometimes make exceptions for this. Our
decision will be guided by the two goals of preserving the free status
of all derivatives of our free software and of promoting the sharing
and reuse of software generally.
14. If you wish to incorporate parts of the Library into other
free programs whose distribution conditions are incompatible
with these, write to the author to ask for permission. For
software which is copyrighted by the Free Software Foundation,
write to the Free Software Foundation; we sometimes make
exceptions for this. Our decision will be guided by the two
goals of preserving the free status of all derivatives of our
free software and of promoting the sharing and reuse of software
generally.
NO WARRANTY
NO WARRANTY
15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO
WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW.
EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR
OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND,
EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE
OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY
KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE
LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME
@@ -460,29 +426,28 @@ THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY
AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU
FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL
DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE
FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR
CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE
LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING
RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A
FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF
SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
DAMAGES.
END OF TERMS AND CONDITIONS
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Libraries
Appendix: How to Apply These Terms to Your New Libraries
If you develop a new library, and you want it to be of the greatest
possible use to the public, we recommend making it free software that
everyone can redistribute and change. You can do so by permitting
redistribution under these terms (or, alternatively, under the terms of the
ordinary General Public License).
If you develop a new library, and you want it to be of the
greatest possible use to the public, we recommend making it free
software that everyone can redistribute and change. You can do
so by permitting redistribution under these terms (or,
alternatively, under the terms of the ordinary General Public
License).
To apply these terms, attach the following notices to the
library. It is safest to attach them to the start of each
source file to most effectively convey the exclusion of
warranty; and each file should have at least the "copyright"
line and a pointer to where the full notice is found.
To apply these terms, attach the following notices to the library. It is
safest to attach them to the start of each source file to most effectively
convey the exclusion of warranty; and each file should have at least the
"copyright" line and a pointer to where the full notice is found.
<one line to give the library's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
@@ -498,8 +463,8 @@ line and a pointer to where the full notice is found.
Library General Public License for more details.
You should have received a copy of the GNU Library General Public
License along with this library; if not, write to the Free
Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
License along with this library; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
Also add information on how to contact you by electronic and paper mail.
@@ -514,4 +479,3 @@ necessary. Here is a sample; alter the names:
Ty Coon, President of Vice
That's all there is to it!

6
docs/licence.txt
View File

@@ -8,12 +8,12 @@
WXWINDOWS LIBRARY LICENCE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
This library is free software; you can redistribute it and/or modify it
under the terms of the GNU Library General Public Licence as published by
the Free Software Foundation; either version 2 of the Licence, or (at
your option) any later version.
This library is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Library
@@ -46,7 +46,7 @@
accordingly.
4. If you write modifications of your own for this library, it is your
choice whether to permit this exception to apply to your modifications.
choice whether to permit this exception to apply to your modifications.
If you do not wish that, you must delete the exception notice from such
code and/or adjust the licensing conditions notice accordingly.

4
docs/licendoc.txt
View File

@@ -5,7 +5,7 @@
Everyone is permitted to copy and distribute verbatim copies
of this licence document, but changing it is not allowed.
WXWINDOWS FREE DOCUMENTATION LICENCE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
@@ -37,7 +37,7 @@
WARRANTY DISCLAIMER
5. BECAUSE THIS MANUAL OR PIECE OF DOCUMENTATION IS LICENSED FREE OF CHARGE,
THERE IS NO WARRANTY FOR IT, TO THE EXTENT PERMITTED BY APPLICABLE LAW.
THERE IS NO WARRANTY FOR IT, TO THE EXTENT PERMITTED BY APPLICABLE LAW.
EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER
PARTIES PROVIDE THIS MANUAL OR PIECE OF DOCUMENTATION "AS IS" WITHOUT
WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT

83
docs/msw/binaries.md
View File

@@ -7,42 +7,34 @@ Supported Compilers
-------------------
We provide pre-built binary files for the following compilers:
* Microsoft Visual C++ compiler versions 9.0, 10.0, 11.0, 12.0, 14.0 and 14.1
(corresponding to marketing product names of Microsoft Visual Studio 2008, 2010, 2012, 2013, 2015 and 2017 respectively).
* TDM-GCC version 5.1 and MinGW-w64 version 7.2 (with the default SJLJ
exceptions propagation method, using C++11). Please note that you need to use
the very latest MinGW-w64 7.2 compiler release with this version of the
compiler which can be downloaded from
[here for 32 bits](https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/7.2.0/threads-win32/sjlj/i686-7.2.0-release-win32-sjlj-rt_v5-rev1.7z/download)
and
[here for 64 bits](https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/7.2.0/threads-win32/seh/x86_64-7.2.0-release-win32-seh-rt_v5-rev1.7z/download),
the older "rev0" release has a known bug affecting building wxWidgets in
some scenarios.
* Microsoft Visual C++ compiler versions 9.0, 10.0, 11.0, 12.0, 14.0, 14.1 and 14.2
(corresponding to marketing product names of Microsoft Visual Studio 2008, 2010, 2012, 2013, 2015, 2017 and 2019 respectively). Please note that MSVC 14.x versions are ABI-compatible and the same set of binaries is used for all of them.
* MinGW-w64 versions 7.3 and 8.1 (32-bit binaries use SJLJ exceptions, 64-bit ones use SEH, and all binaries use Win32 threads).
* [TDM-GCC](https://jmeubank.github.io/tdm-gcc/) 9.2.0.
Getting the files
-----------------
First, you need to get the correct files. You will always need the
`wxWidgets-3.1.1-headers.7z` one but the rest depends on your compiler version
`wxWidgets-3.1.4-headers.7z` one but the rest depends on your compiler version
and architecture: as different versions of MSVC compiler are not binary
compatible, you should select the files with the correct
`vc80`, `vc90`, `vc100`, `vc110`, `vc120`, `vc140` or `vc141`
`vc80`, `vc90`, `vc100`, `vc110`, `vc120`, or `vc14x`
suffix depending on whether you use
Visual Studio 2005, 2008, 2010, 2012, 2013, 2015 or 2017 respectively.
Visual Studio 2005, 2008, 2010, 2012, 2013, or 2015/2017/2019 respectively (the Visual Studio 2015/2017/2019 compilers are binary compatible).
You also need to decide whether you use the `x64` files for 64-bit development
or the ones without this suffix for the still more common 32-bit builds. After
determining the combination of suffixes you need, you should download the
"Dev" and the "ReleaseDLL" files in addition to the "Headers" one above,
e.g. for 32-bit MSVS 2017 development you need
`wxMSW-3.1.1_vc141_Dev.7z` and `wxMSW-3.1.1_vc141_ReleaseDLL.7z`.
`wxMSW-3.1.4_vc14x_Dev.7z` and `wxMSW-3.1.4_vc14x_ReleaseDLL.7z`.
All binaries are available at:
https://github.com/wxWidgets/wxWidgets/releases/v3.1.1
https://www.wxwidgets.org/downloads#v3.1.4_msw
Once you have the files you need, unzip all of them into the same directory, for
example `c:\wx\3.1.1`. You should have only include and lib subdirectories under
example `c:\wx\3.1.4`. You should have only include and lib subdirectories under
it, nothing else. To avoid hard-coding this path into your projects, define
`wxwin` environment variable containing it: although it's a little known fact,
all versions of MSVC support environment variable expansion in the C++ projects
@@ -51,40 +43,25 @@ all versions of MSVC support environment variable expansion in the C++ projects
Using Binaries with Visual Studio
---------------------------------
Next step is to set up your project to use these files. You need to do the
following:
Next step is to set up your project to use these files: for this, simply add
the provided `wxwidgets.props` file as a property sheet to your project.
This can be done using `View|Property Manager` menu item in the IDE and
selecting "Add Existing Property Sheet..." from the project popup menu.
* In the compiler options, i.e. "C/C++" properties:
* Add `$(wxwin)/include/msvc;$(wxwin)/include` to the "Additional Include
Directories". Notice that the order is important here, putting the
MSVC-specific directory first ensures that you use `wx/setup.h`
automatically linking in wxWidgets libraries.
* Add `WXUSINGDLL` and `wxMSVC_VERSION_AUTO` to the list of defined
symbols in "Preprocessor Definitions". The first should be
self-explanatory (we only provide DLLs, not static libraries) while the
second one is necessary to use the libraries from e.g. `lib\vc100_dll`
directory and not the default `lib\vc_dll`.
* Also check that `_UNICODE` and `UNICODE` symbols are defined in the same
"Preprocessor Definitions" section. This should already be the case for
the newly created projects but it might be necessary to add them if
you're upgrading an existing one.
* Check that you use "Multi-threaded \[Debug\] DLL" in the "Run-time
library" option under "Code Generation" to ensure that your build uses
the same CRT version as our binaries.
* In the linker options you only need to add `$(wxwin)\lib\vc141_dll` (with
the compiler-version-dependent suffix, of course) to "Additional Library
Directories" under "Linker\\General" in the options. Thanks to the use of
MSVC-specific `setup.h` you don't need to list wxWidgets libraries manually,
i.e. you do **not** need to put anything in the list of "Additional
Dependencies".
Note: your project must use "Unicode Character Set" option.
Now you should be able to build your project successfully, both in "Debug" and
"Release" configurations. With MSVS 10 or newer it can also be done from the
command line using `msbuild.exe`. Of course, to run the generated executable
you will need to either add the directory containing wxWidgets DLLs to your PATH
or copy the DLL files to a directory already on it. Finally, if you want to
distribute the binaries created using these options, you will need to install
Microsoft Visual C++ run-time DLLs. Again, MSVC 10 or newer has an advantage
here as you can simply copy `msvcp100.dll` and `msvcr100.dll` as any other DLL,
while you need to install specially for the previous compiler versions that
use WinSxS ("side-by-side") for them.
Now you should be able to build and run your project successfully, both in
"Debug" and "Release" configurations. Please note that during run-time the
executables will require wxWidgets DLLs in addition to MSVC run-time DLLs, so
you should consider adding the directory containing these DLLs to your PATH and
either distributing them with your application or instructing your users to
download them.
Building samples with nmake
---------------------------
When using `makefile.vc` files for building wxWidgets samples using `nmake`
from command line, you need to use `SHARED=1` and also define `COMPILER_PREFIX`
appropriately, e.g. the full command line could be
> nmake /f makefile.vc BUILD=release SHARED=1 COMPILER_PREFIX=vc14x

249
docs/msw/install.md
View File

@@ -34,16 +34,21 @@ variable containing the full path to this directory. While this is not
actually required, this makes using the library more convenient and
this environment variable is used in the examples below.
NB: If you checked your sources from version control repository and
didn't obtain them from a release file, you also need to copy
`include/wx/msw/setup0.h` to `include/wx/msw/setup.h` and to remember
to update the latter whenever the former changes, otherwise you
will get compilation errors if any new symbols are added to
setup0.h file in the repository.
Upgrading Existing Git Checkout {#msw_update_setup_h}
-------------------------------
If you have no intention of modifying setup.h, you may avoid this
problem by creating a symbolic link to setup0.h instead of making
a copy of it using mklink, from an admin command prompt:
If you checked your sources from version control repository and didn't
obtain them from a release file, you may need to update your
`include/wx/msw/setup.h` file to add any new options from
`include/wx/msw/setup0.h` to it. If you hadn't edited `setup.h` file
manually, you can just delete it to force recreating it by copying
`setup0.h` to `setup.h` during the next build. If you forget to do it,
you may get errors during the build due to new options being
undefined.
If you have no intention of ever modifying `setup.h`, you may avoid this
problem entirely by creating a symbolic link to `setup0.h` before
building, e.g. using mklink, from an admin command prompt:
cd %WXWIN%\include\wx\msw\
mklink setup.h setup0.h
@@ -79,11 +84,13 @@ Microsoft Visual C++ Compilation {#msw_build_msvs}
to build a release version or
> nmake /f makefile.vc BUILD=release SHARED=1
> nmake /f makefile.vc BUILD=release SHARED=1 TARGET_CPU=X86
to build a release DLL version. Finally, you can also add
"TARGET_CPU=X64" to nmake command line to build Win64 versions
(this only works if you are using a 64 bit compiler, of course).
to build a 32 bit release DLL version from an x86 command prompt, or
> nmake /f makefile.vc BUILD=release SHARED=1 TARGET_CPU=X64
to build a 64 bit release DLL version from an x64 command prompt.
See "Configuring the Build" for more information about the
additional parameters that can be specified on the command line.
@@ -98,10 +105,10 @@ Microsoft Visual C++ Compilation {#msw_build_msvs}
* From the IDE using the provided project files:
Ready to use project files are provided for VC++ versions 7, 8, 9,
10, 11, 12, 14 and 15 (also known as MSVS 2003, 2005, 2008, 2010, 2012, 2013,
2015 and 2017 respectively).
10, 11, 12, 14, 15 and 16 (also known as MSVS 2003, 2005, 2008, 2010, 2012,
2013, 2015, 2017 and 2019 respectively).
Simply open wx_vcN.sln (for N=7, 8, 9, 10, 11, 12, 14, or 15) file,
Simply open `wx_vcN.sln` (for N=7, 8, 9, 10, 11, 12, 14, 15 or 16) file,
select the appropriate configuration (Debug or Release, static or DLL)
and build the solution. Notice that when building a DLL configuration,
you may need to perform the build several times because the projects
@@ -112,11 +119,11 @@ errors. Simply do the build again, up to 3 times, to fix this.
### Special notes for Visual Studio 2010+
For Visual Studio 2010+ solutions it is possible to customize the build by
creating a wx_local.props file in the build\msw directory which is used, if it
creating a `wx_local.props` file in the build\msw directory which is used, if it
exists, by the projects. The settings in that file override the default values
for the properties such as wxCfg (corresponding to the CFG makefile variable
described below) or wxVendor (corresponding to VENDOR). The typical way to
make the file is to copy wx_setup.props to wx_local.props and then edit local.
make the file is to copy `wx_setup.props` to `wx_local.props` and then edit local.
For example, if you are building wxWidgets libraries using multiple versions
of Visual Studio you could change wxCompilerPrefix to include the toolset:
@@ -125,15 +132,15 @@ of Visual Studio you could change wxCompilerPrefix to include the toolset:
+ <wxCompilerPrefix>vc$(PlatformToolsetVersion)</wxCompilerPrefix>
Following that example if you are using Visual Studio 2013 and open
wx_vc12.sln it will build using the "vc120" prefix for the build directories
`wx_vc12.sln` it will build using the "vc120" prefix for the build directories
so to allow its build files to coexist with the files produced by the other
MSVC versions.
Keep in mind that by using a separate local props file you ensure that your
changes won't be lost when updating to a future wxWidgets version. But if
wx_setup.props is updated in some later commit your wx_local.props is not
updated with it. For example the version information in wx_setup.props could
change and the information in your wx_local.props would be outdated. It is
`wx_setup.props` is updated in some later commit your `wx_local.props` is not
updated with it. For example the version information in `wx_setup.props` could
change and the information in your `wx_local.props` would be outdated. It is
your responsibility to monitor for such situations.
### Improve debugging for Visual Studio 2012+
@@ -190,7 +197,7 @@ either MSYS or Cygwin.
0. Open MSYS or Cygwin shell prompt.
1. Create a build directory: it is is strongly recommended to not
build the library in the directory containing the sources ($WXWIN)
build the library in the directory containing the sources (`$WXWIN`)
but to create a separate build directory instead. The build
directory can be placed anywhere (using the fastest available disk
may be a good idea), but in this example we create it as a
@@ -242,8 +249,8 @@ NOTE: The makefile.gcc makefiles are for compilation under MinGW using
default static one.
NOTE: For parallel builds, i.e. using -jN make option, please run
"mingw32-make -jN ... setup_h" first and then rerun the full
make command without "setup_h" at the end to work around a bug
`mingw32-make -jN ... setup_h` first and then rerun the full
make command without `setup_h` at the end to work around a bug
in the current makefiles.
2. To verify your build, change the directory to samples\minimal and
@@ -255,73 +262,22 @@ NOTE: The makefile.gcc makefiles are for compilation under MinGW using
Borland C++ Compilation {#msw_build_borland}
----------------------------------------------------------------
WARNING: Borland instructions are out of date, please send us your
corrections if you are using it with wxWidgets 3.0.
Installing and building wxWidgets using vcpkg {#msw_install_and_build}
=============================================
The minimum version required is 5.5 (last version supported by BC++ 5.0 was
2.4.2), which can be downloaded for free from:
http://www.borland.com/products/downloads/download_cbuilder.html
You can download and install wxWidgets using the [vcpkg](https://github.com/Microsoft/vcpkg)
dependency manager:
We have found that the free Turbo Explorer and commercial BDS work fine; the
debugger is very good. To avoid linker errors you will need to add
-DSHARED=1 to the makefile line for the library
> git clone https://github.com/Microsoft/vcpkg.git
> cd vcpkg
> bootstrap-vcpkg.bat
> vcpkg integrate install
> vcpkg install wxwidgets
The version 5.6 included in Borland C++ Builder 2006 works as well after the
following small change: please remove the test for `__WINDOWS__` from line 88
of the file `BCCDIR\include\stl\_threads.h`.
Compiling using the makefiles:
1. Change directory to build\msw. Type 'make -f makefile.bcc' to
make the wxWidgets core library. Ignore the compiler warnings.
This produces a couple of libraries in the lib\bcc_lib directory.
2. Change directory to a sample or demo such as samples\minimal, and type
'make -f makefile.bcc'. This produces a windows exe file - by default
in the bcc_mswd subdirectory.
Note (1): the wxWidgets makefiles assume dword structure alignment. Please
make sure that your own project or makefile settings use the
same alignment, or you could experience mysterious crashes. To
change the alignment, change CPPFLAGS in build\msw\config.bcc.
Note (2): If you wish debug messages to be sent to the console in
debug mode, edit makefile.bcc and change /aa to /Tpe in link commands.
Using the Debugger and IDE in BDS or Turbo Explorer
---------------------------------------------------
Doubleclick / open \%WXWIN\%\samples\minimal\borland.bdsproj. The current version
is to be used with a dynamic build of wxWidgets-made by running
make -f Makefile.bcc -DBUILD=debug -DSHARED=1
in wxWidgets\build\msw. You also need the wxWidgets\lib\bcc_dll
directory in your PATH. The debugger tracks your source and also
traces into the wxWidgets sources.
To use this to debug other samples, copy the borland_ide.cpp
and borland.bdsproj files, then replace all occurrences of
"minimal" with the name of the new project files
Compilation succeeds with CBuilderX personal edition and CBuilder6, but
you may have to copy make.exe from the 5.5 download to the new bin directory.
Compiling using the IDE files for Borland C++ 5.0 and using CBuilder IDE
(v1-v6): not supported
** REMEMBER **
In all of your wxWidgets applications, your source code should include
the following preprocessor directive:
#ifdef __BORLANDC__
#pragma hdrstop
#endif
(check the samples -- e.g., \wx2\samples\minimal\minimal.cpp -- for
more details)
The wxWidgets port in vcpkg is kept up to date by Microsoft team members and community
contributors. If the version is out of date, please [create an issue or pull request]
(https://github.com/Microsoft/vcpkg) on the vcpkg repository.
@@ -353,17 +309,17 @@ When building using makefiles, you can specify many build settings
(unlike when using the project files where you are limited to choosing
just the configuration and platform). This can be done either by
passing the values as arguments when invoking make or by editing
build\msw\config.$(compiler) file where $(compiler) is same extension
`build\msw\config.$compiler` file where `$compiler` is the same extension
as the makefile you use has (see below). The latter is good for
setting options that never change in your development process (e.g.
GCC_VERSION or VENDOR). If you want to build several versions of
`GCC_VERSION` or `VENDOR`). If you want to build several versions of
wxWidgets and use them side by side, the former method is better.
Settings in config.* files are shared by all makefiles (including the
samples), but if you pass the options as arguments, you must use same
Settings in `config.*` files are shared by all makefiles (including the
samples), but if you pass the options as arguments, you must use the same
arguments you used for the library when building samples!
For example, to build the library in release mode you can either
change the "BUILD" variable definition in build\msw\config.$(compiler)
change the "BUILD" variable definition in `build\msw\config.$compiler`
or use
> nmake -f makefile.vc BUILD=debug
@@ -373,19 +329,19 @@ depending on the compiler used.
The full list of the build settings follows:
* BUILD=release
* `BUILD=release`
Builds release version of the library. It differs from default 'debug' in
lack of appended 'd' in name of library and uses the release CRT libraries
instead of debug ones. Notice that even release builds do include debug
information by default, see DEBUG_FLAG for more information about it.
information by default, see `DEBUG_FLAG` for more information about it.
* SHARED=1
* `SHARED=1`
Build shared libraries (DLLs). By default, DLLs are not built
(SHARED=0).
* UNICODE=0
* `UNICODE=0`
To completely disable Unicode support (default is UNICODE=1). It should not
be necessary to do this.
@@ -394,11 +350,11 @@ The full list of the build settings follows:
Unicode build) and the directory where the library and setup.h are stored
(ditto).
* WXUNIV=1
* `WXUNIV=1`
Build wxUniversal instead of native wxMSW
* MONOLITHIC=1
* `MONOLITHIC=1`
Starting with version 2.5.1, wxWidgets has the ability to be built as
several smaller libraries instead of single big one as used to be the case
@@ -406,32 +362,32 @@ The full list of the build settings follows:
default behaviour of makefiles. You can still build single library
("monolithic build") by setting MONOLITHIC variable to 1.
* USE_GUI=0
* `USE_GUI=0`
Disable building GUI parts of the library, build only wxBase components used
by console applications. Note that if you leave USE_GUI=1 then both wxBase
by console applications. Note that if you leave `USE_GUI=1` then both wxBase
and GUI libraries are built.
* USE_$(LIBRARY)=0
* `USE_$LIBRARY=0`
Do not build the corresponding library (all libraries are built by
default). Library which can be disabled in this way are: AUI, HTML,
MEDIA, GL (the option name is USE_OPENGL for this one), PROPGRID,
MEDIA, GL (the option name is `USE_OPENGL` for this one), PROPGRID,
QA, RIBBON, RICHTEXT, STC, WEBVIEW, XRC.
* RUNTIME_LIBS=static
* `RUNTIME_LIBS=static`
Links static version of C and C++ runtime libraries into the executable, so
that the program does not depend on DLLs provided with the compiler (e.g.
Visual C++'s msvcrt.dll or Borland's cc3250mt.dll).
Visual C++'s msvcrt.dll).
Caution: Do not use static runtime libraries when building DLL (SHARED=1)!
* DEBUG_FLAG=0
* DEBUG_FLAG=1
* DEBUG_FLAG=2
* `DEBUG_FLAG=0`
* `DEBUG_FLAG=1`
* `DEBUG_FLAG=2`
Specifies the level of debug support in wxWidgets. Notice that
this is independent from both BUILD and DEBUG_INFO options. By default
this is independent from both BUILD and `DEBUG_INFO` options. By default
always set to 1 meaning that debug support is enabled: asserts are compiled
into the code (they are inactive by default in release builds of the
application but can be enabled), wxLogDebug() and wxLogTrace() are available
@@ -440,15 +396,15 @@ The full list of the build settings follows:
consuming assertions and checks which are deemed to be unsuitable for
production environment.
* DEBUG_INFO=0
* DEBUG_INFO=1
* `DEBUG_INFO=0`
* `DEBUG_INFO=1`
This option affects whether debugging information is generated. If
omitted or set to 'default' its value is determined the value of
the BUILD option.
* DEBUG_RUNTIME_LIBS=0
* DEBUG_RUNTIME_LIBS=1
* `DEBUG_RUNTIME_LIBS=0`
* `DEBUG_RUNTIME_LIBS=1`
(VC++ only.) If set to 1, msvcrtd.dll is used, if to 0, msvcrt.dll
is used. By default msvcrtd.dll is used only if the executable
@@ -458,36 +414,36 @@ The full list of the build settings follows:
usable .pdb files with debug information) and this setting makes it
possible.
* TARGET_CPU=X64|ARM64|IA64
* `TARGET_CPU=X64|ARM64|IA64`
(VC++ only.) Set this variable to build for x86_64 systems. If unset, x86
build is performed.
* VENDOR=\<your company name\>
* `VENDOR=<your company name>`
Set this to a short string identifying your company if you are planning to
distribute wxWidgets DLLs with your application. Default value is 'custom'.
This string is included as part of DLL name. wxWidgets DLLs contain compiler
name, version information and vendor name in them. For example
wxmsw311u_core_vc_custom.dll is one of DLLs build using Visual C++ with
`wxmsw311u_core_vc_custom.dll` is one of DLLs build using Visual C++ with
default settings. If you set VENDOR=mycorp, the name will change to
wxmsw311u_core_vc_mycorp.dll.
`wxmsw311u_core_vc_mycorp.dll.`
* CFG=\<configuration name\>
* `CFG=<configuration name>`
Sets configuration name so that you can have multiple wxWidgets builds with
different setup.h settings coexisting in same tree. The value of
this option is appended to the build directories names. This is
useful for building the library in some non-default configuration,
e.g. you could change wxUSE_STL to 1 in \%WXWIN\%\include\wx\msw\setup.h and
then build with "CFG=-stl". Alternatively, you could build with e.g.
"RUNTIME_LIBS=static CFG=-mt" when using MSVC.
e.g. you could change `wxUSE_STL` to 1 in `\%WXWIN\%\include\wx\msw\setup.h` and
then build with `CFG=-stl`. Alternatively, you could build with e.g.
`RUNTIME_LIBS=static CFG=-mt` when using MSVC.
* COMPILER_PREFIX=\<string\>
* `COMPILER_PREFIX=<string>`
If you build with multiple versions of the same compiler, you can put
their outputs into directories like "vc6_lib", "vc8_lib" etc. instead of
"vc_lib" by setting this variable to e.g. "vc6". This is merely a
their outputs into directories like `vc6_lib`, `vc8_lib` etc. instead of
`vc_lib` by setting this variable to e.g. `vc6`. This is merely a
convenience variable, you can achieve the same effect (but different
directory names) with the CFG option.
@@ -506,36 +462,43 @@ Building Applications Using wxWidgets {#msw_build_apps}
=====================================
If you use MSVS 2010 or later IDE for building your project, simply add
`wxwidgets.props` property sheet to (all) your project(s) using wxWidgets.
You don't need to do anything else.
`wxwidgets.props` property sheet to (all) your project(s) using wxWidgets
by using "View|Property Manager" menu item to open the property manager
window and then selecting "Add Existing Property Sheet..." from the context
menu in this window.
If you've created a new empty project (i.e. chose "Empty Project" in the
"Create a new project" window shown by MSVS rather than "Windows Desktop"),
you need to change "Linker|System|SubSystem" in the project properties to
"Windows", from the default "Console". You don't need to do anything else.
If you want to use CMake for building your project, please see
@ref overview_cmake.
Otherwise follow the instructions below for "manual" setup of your project.
We suppose that wxWidgets sources are under the directory $WXWIN (notice that
We suppose that wxWidgets sources are under the directory `$WXWIN` (notice that
different tool chains refer to environment variables such as WXWIN in
different ways, e.g. MSVC users should use $(WXWIN) instead of just
$WXWIN). And we will use \<wx-lib-dir\> as a shortcut for the subdirectory of
$WXWIN\lib which is composed from several parts separated by underscore:
different ways, e.g. MSVC users should use `$``(WXWIN)` instead of just
`$WXWIN`). And we will use `<wx-lib-dir>` as a shortcut for the subdirectory of
`$WXWIN\lib` which is composed from several parts separated by underscore:
first, a compiler-specific prefix (e.g. "vc" for MSVC, "gcc" for g++ or the
value of COMPILER_PREFIX if you set it explicitly), then optional "x64" if
value of `COMPILER_PREFIX` if you set it explicitly), then optional "x64" if
building in 64 bits and finally either "lib" or "dll" depending on whether
static or dynamic wx libraries are being used.
For example, WXWIN could be "c:\wxWidgets\3.4.5" and \<wx-lib-dir\> could be
"c:\wxWidgets\3.4.5\lib\vc_x64_lib" for 64-bit static libraries built with
For example, WXWIN could be "c:\wxWidgets\3.4.5" and `<wx-lib-dir>` could be
`c:\wxWidgets\3.4.5\lib\vc_x64_lib` for 64-bit static libraries built with
MSVC.
Here is what you need to do:
* Add $WXWIN\\include to the
* Add `$WXWIN\include` to the
- compiler
- resource compiler
include paths.
* If using MSVC, prepend $WXWIN\include\msvc to the include paths too.
Otherwise, append \<wx-lib-dir\>\mswu[d] to the include paths, where "d" should
* If using MSVC, prepend `$WXWIN\include\msvc` to the include paths too.
Otherwise, append `<wx-lib-dir>\mswu[d]` to the include paths, where "d" should
be used for debug builds only.
* Define the following symbols for the preprocessor:
- `__WXMSW__` to ensure you use the correct wxWidgets port.
@@ -544,7 +507,7 @@ Here is what you need to do:
- `WXUSINGDLL` if you are using DLL build of wxWidgets.
* If using MSVC 7 only (i.e. not for later versions), also define
`wxUSE_RC_MANIFEST=1` and `WX_CPU_X86`.
* Add \<wx-lib-dir\> directory described above to the libraries path.
* Add `<wx-lib-dir>` directory described above to the libraries path.
When using MSVC, the libraries are linked automatically using "#pragma
comment(lib)" feature of this compiler. With all the other compilers you also
@@ -553,9 +516,9 @@ need to:
* Add the list of libraries to link with to the linker input. The exact list
depends on which libraries you use and whether you built wxWidgets in
monolithic or default multlib mode and basically should include all the
relevant libraries from the directory above, e.g. "wxmsw31ud_core.lib
relevant libraries from the directory above, e.g. `wxmsw31ud_core.lib
wxbase31ud.lib wxtiffd.lib wxjpegd.lib wxpngd.lib wxzlibd.lib wxregexud.lib
wxexpatd.lib" for a debug build of an application using the core library only
wxexpatd.lib` for a debug build of an application using the core library only
(all wxWidgets applications use the base library).
@@ -563,7 +526,7 @@ Finally, please notice that the makefiles and project files provided with
wxWidgets samples show which flags should be used when building applications
using wxWidgets and always work, so in case of a problem, e.g. if the
instructions here are out of date, you can always simply copy a makefile or
project file from $WXWIN\samples\minimal or some other sample and adapt it to
project file from `$WXWIN\samples\minimal` or some other sample and adapt it to
your application.
If you are not using Visual Studio 2010 or newer please see
@@ -572,11 +535,13 @@ application.
Advanced Library Configurations {#msw_advanced}
===============================
Build instructions to less common library configuartions using different UI
backends are avaiable here.
Build instructions to less common library configurations using different UI
backends are available here.
@subpage plat_msw_msys2 "Building with Win32 MSys2 backend"
@subpage plat_msw_msys2_gtk "Building with Win32 MSys2 GDK backend"
@subpage plat_msw_gtk "Building wxGTK port with Win32 GDK backend"
@subpage plat_msw_msys2_qt "Building with Win32 MSys2 Qt backend"

84
docs/msw/msys2-gtk.md
View File

@@ -18,43 +18,37 @@ For the MSys2 way please see
Building steps:
**Warning**: At the time these directions were written the GTK version 3
was NOT able to create wxGTK/Win32 libraries that were usable.
1. Install the mingw32 packages needed to build wxGTK/Win32 using the
A. Install the MSys2 mingw packages needed to build wxGTK/Win32 using the
configure/make build method.
From the MSys2 prompt or MSys2 MinGW prompt:
The 32 bit Mingw packages are prefixed with "mingw-w64-i686-";
Change the prefix to "mingw-w64-x86_64-" if you wish to do 64 bit.
From the MSys2 MinGW prompt:
pacman -S --needed --noconfirm make
pacman -S --needed --noconfirm mingw-w64-i686-libjpeg-turbo
pacman -S --needed --noconfirm mingw-w64-i686-libpng
pacman -S --needed --noconfirm mingw-w64-i686-libtiff
pacman -S --needed --noconfirm mingw-w64-i686-gcc
pacman -S --needed --noconfirm mingw-w64-i686-pkg-config
## gtk2 can take a long time to update/find fonts
pacman -S --needed --noconfirm mingw-w64-i686-gtk2
pacman -S --needed --noconfirm ${MINGW_PACKAGE_PREFIX}-libjpeg-turbo
pacman -S --needed --noconfirm ${MINGW_PACKAGE_PREFIX}-libpng
pacman -S --needed --noconfirm ${MINGW_PACKAGE_PREFIX}-libtiff
pacman -S --needed --noconfirm ${MINGW_PACKAGE_PREFIX}-gcc
pacman -S --needed --noconfirm ${MINGW_PACKAGE_PREFIX}-pkg-config
## gtk3 can take a long time to update/find fonts
pacman -S --needed --noconfirm ${MINGW_PACKAGE_PREFIX}-gtk3
Packages that are needed but are normally installed already.
pacman -S --needed --noconfirm mingw-w64-i686-gcc-libs
pacman -S --needed --noconfirm mingw-w64-i686-expat
pacman -S --needed --noconfirm mingw-w64-i686-xz
pacman -S --needed --noconfirm mingw-w64-i686-zlib
pacman -S --needed --noconfirm mingw-w64-i686-gdk-pixbuf2
pacman -S --needed --noconfirm ${MINGW_PACKAGE_PREFIX}-gcc-libs
pacman -S --needed --noconfirm ${MINGW_PACKAGE_PREFIX}-expat
pacman -S --needed --noconfirm ${MINGW_PACKAGE_PREFIX}-xz
pacman -S --needed --noconfirm ${MINGW_PACKAGE_PREFIX}-zlib
pacman -S --needed --noconfirm ${MINGW_PACKAGE_PREFIX}-gdk-pixbuf2
2. Build the wxGTK/Win32 static library
B. Build the wxGTK/Win32 static library
1. Open MSys2 MinGW Prompt
(These steps were tested on MinGW32; but, should work under MinGW64)
(These steps were tested on MinGW64; but, should work under MinGW32)
2. Use the cd command to change directory to the wxWidgets top folder.
3. Create the "build-gtk2-static" folder to build the static libraries
3. Create the "build-${MSYSTEM_CARCH}-gtk3-static" folder to build the static libraries
mkdir -p build-gtk2-static
mkdir -p build-${MSYSTEM_CARCH}-gtk3-static
4. Configure wxWidgets
Option "--disable-precomp-headers" is NOT needed.
@@ -63,8 +57,8 @@ Building steps:
Remove configure option "--disable-wxdib" to set wxUSE_WXDIB to 1.
The directions docs/msw/gtk.txt results in wxUSE_WXDIB set to 1.
cd build-gtk2-static && \
../configure --with-gtk=2 \
cd build-${MSYSTEM_CARCH}-gtk3-static && \
../configure --with-gtk=3 \
--disable-wxdib \
--disable-shared \
--disable-precomp-headers \
@@ -72,53 +66,53 @@ Building steps:
5. clean the wxGTK static libraries
cd build-gtk2-static && make clean && cd ..
cd build-${MSYSTEM_CARCH}-gtk3-static && make clean && cd ..
6. make the wxGTK static libraries
cd build-gtk2-static && make && cd ..
cd build-${MSYSTEM_CARCH}-gtk3-static && make && cd ..
3. Build and run the minimal static sample
C. Build and run the minimal static sample
1. Clean the minimal sample
cd build-gtk2-static/samples/minimal && make clean && cd ../../..
cd build-${MSYSTEM_CARCH}-gtk3-static/samples/minimal && make clean && cd ../../..
2. Build the minimal sample
cd build-gtk2-static/samples/minimal && make && cd ../../..
cd build-${MSYSTEM_CARCH}-gtk3-static/samples/minimal && make && cd ../../..
3. Run the minimal sample
./build-gtk2-static/samples/minimal/minimal.exe
./build-${MSYSTEM_CARCH}-gtk3-static/samples/minimal/minimal.exe
4. Build most of the static samples
D. Build most of the static samples
1. Clean most of the static samples
cd build-gtk2-static/samples && make clean && cd ../..
cd build-${MSYSTEM_CARCH}-gtk3-static/samples && make clean && cd ../..
2. Build most of the static samples
cd build-gtk2-static/samples && make && cd ../..
cd build-${MSYSTEM_CARCH}-gtk3-static/samples && make && cd ../..
5. Run the drawing static sample
E. Run the drawing static sample
cd samples/drawing && ../../build-gtk2-static/samples/drawing/drawing.exe && cd ../..
cd samples/drawing && ../../build-${MSYSTEM_CARCH}-gtk3-static/samples/drawing/drawing.exe && cd ../..
6. Run the splash static sample
F. Run the splash static sample
cd samples/splash && ../../build-gtk2-static/samples/splash/splash.exe && cd ../..
cd samples/splash && ../../build-${MSYSTEM_CARCH}-gtk3-static/samples/splash/splash.exe && cd ../..
7. Run the widgets static sample
G. Run the widgets static sample
cd samples/widgets && ../../build-gtk2-static/samples/widgets/widgets.exe && cd ../..
cd samples/widgets && ../../build-${MSYSTEM_CARCH}-gtk3-static/samples/widgets/widgets.exe && cd ../..
8. Run the toolbar static sample
H. Run the toolbar static sample
cd samples/toolbar && ../../build-gtk2-static/samples/toolbar/toolbar.exe && cd ../..
cd samples/toolbar && ../../build-${MSYSTEM_CARCH}-gtk3-static/samples/toolbar/toolbar.exe && cd ../..
9. Run the image static sample
I. Run the image static sample
cd samples/image && ../../build-gtk2-static/samples/image/image.exe && cd ../..
cd samples/image && ../../build-${MSYSTEM_CARCH}-gtk3-static/samples/image/image.exe && cd ../..

75
docs/msw/msys2-msw.md
View File

@@ -11,35 +11,32 @@ For the MSys2 way please see https://github.com/Alexpux/MINGW-packages
Building steps:
1. Install the mingw32 packages needed to build wxMSW using the
A. Install the mingw32 packages needed to build wxMSW using the
configure/make build method.
From the MSys2 prompt or MSys2 MinGW prompt:
The 32 bit Mingw packages are prefixed with "mingw-w64-i686-";
Change the prefix to "mingw-w64-x86_64-" if you wish to do 64 bit.
From the MSys2 MinGW prompt:
pacman -S --needed --noconfirm make
pacman -S --needed --noconfirm mingw-w64-i686-libjpeg-turbo
pacman -S --needed --noconfirm mingw-w64-i686-libpng
pacman -S --needed --noconfirm mingw-w64-i686-libtiff
pacman -S --needed --noconfirm mingw-w64-i686-gcc
pacman -S --needed --noconfirm ${MINGW_PACKAGE_PREFIX}-libjpeg-turbo
pacman -S --needed --noconfirm ${MINGW_PACKAGE_PREFIX}-libpng
pacman -S --needed --noconfirm ${MINGW_PACKAGE_PREFIX}-libtiff
pacman -S --needed --noconfirm ${MINGW_PACKAGE_PREFIX}-gcc
Packages that are needed but are normally installed already.
pacman -S --needed --noconfirm mingw-w64-i686-gcc-libs
pacman -S --needed --noconfirm mingw-w64-i686-expat
pacman -S --needed --noconfirm mingw-w64-i686-xz
pacman -S --needed --noconfirm mingw-w64-i686-zlib
pacman -S --needed --noconfirm ${MINGW_PACKAGE_PREFIX}-gcc-libs
pacman -S --needed --noconfirm ${MINGW_PACKAGE_PREFIX}-expat
pacman -S --needed --noconfirm ${MINGW_PACKAGE_PREFIX}-xz
pacman -S --needed --noconfirm ${MINGW_PACKAGE_PREFIX}-zlib
2. Build the wxMSW static library
B. Build the wxMSW static library
1. Open MSys2 MinGW Prompt
(These steps were tested on MinGW32; but, should work under MinGW64)
(These steps were tested on MinGW64; but, should work under MinGW32)
2. Use the cd command to change directory to the wxWidgets top folder.
3. Create the "build-msw-static" folder to build the static libraries
3. Create the "build-${MSYSTEM_CARCH}-msw-static" folder to build the static libraries
mkdir -p build-msw-static
mkdir -p build-${MSYSTEM_CARCH}-msw-static
4. Configure wxWidgets
@@ -48,7 +45,7 @@ Building steps:
And, I think my old 32 bit Windows machine
works best with it disabled.
cd build-msw-static && \
cd build-${MSYSTEM_CARCH}-msw-static && \
../configure --with-msw \
--disable-shared \
--disable-precomp-headers \
@@ -56,46 +53,46 @@ Building steps:
5. make the wxMSW static libraries
cd build-msw-static && make && cd ..
cd build-${MSYSTEM_CARCH}-msw-static && make && cd ..
3. Build and run the minimal static sample
C. Build and run the minimal static sample
1. Clean the minimal sample
cd build-msw-static/samples/minimal && make clean && cd ../../..
cd build-${MSYSTEM_CARCH}-msw-static/samples/minimal && make clean && cd ../../..
2. Build the minimal sample
cd build-msw-static/samples/minimal && make && cd ../../..
cd build-${MSYSTEM_CARCH}-msw-static/samples/minimal && make && cd ../../..
3. Run the minimal sample
./build-msw-static/samples/minimal/minimal.exe
./build-${MSYSTEM_CARCH}-msw-static/samples/minimal/minimal.exe
4. Clean the static samples
D. Clean the static samples
cd build-msw-static/samples && make clean && cd ../..
cd build-${MSYSTEM_CARCH}-msw-static/samples && make clean && cd ../..
5. Build and run the typetest static sample to verify MIME database works
E. Build and run the typetest static sample to verify MIME database works
cd build-msw-static/samples/typetest && make && cd ../../..
./build-msw-static/samples/typetest/typetest.exe
cd build-${MSYSTEM_CARCH}-msw-static/samples/typetest && make && cd ../../..
./build-${MSYSTEM_CARCH}-msw-static/samples/typetest/typetest.exe
6. Build and run the drawing static sample
F. Build and run the drawing static sample
cd build-msw-static/samples/drawing && make && cd ../../..
cd samples/drawing && ../../build-msw-static/samples/drawing/drawing.exe && cd ../..
cd build-${MSYSTEM_CARCH}-msw-static/samples/drawing && make && cd ../../..
cd samples/drawing && ../../build-${MSYSTEM_CARCH}-msw-static/samples/drawing/drawing.exe && cd ../..
7. Build and run the splash static sample
G. Build and run the splash static sample
cd build-msw-static/samples/splash && make && cd ../../..
cd samples/splash && ../../build-msw-static/samples/splash/splash.exe && cd ../..
cd build-${MSYSTEM_CARCH}-msw-static/samples/splash && make && cd ../../..
cd samples/splash && ../../build-${MSYSTEM_CARCH}-msw-static/samples/splash/splash.exe && cd ../..
8. Build and run the widgets static sample
H. Build and run the widgets static sample
cd build-msw-static/samples/widgets && make && cd ../../..
cd samples/widgets && ../../build-msw-static/samples/widgets/widgets.exe && cd ../..
cd build-${MSYSTEM_CARCH}-msw-static/samples/widgets && make && cd ../../..
cd samples/widgets && ../../build-${MSYSTEM_CARCH}-msw-static/samples/widgets/widgets.exe && cd ../..
9. Build all the rest of the static samples
I. Build all the rest of the static samples
cd build-msw-static/samples && make && cd ../..
cd build-${MSYSTEM_CARCH}-msw-static/samples && make && cd ../..

118
docs/msw/msys2-qt.md Normal file
View File

@@ -0,0 +1,118 @@
Building wxQT port with Win32 MSys2 Qt5 backend {#plat_msw_msys2_qt}
------------------------------------------------
The MSys2 website is http://www.msys2.org/
These building steps are NOT the normal way to build MSys2 MinGW packages.
But, they are a way the wxWidgets developers can test that wxWidgets
can build the wxQT/Win32 libraries under MSys2 MinGW.
For the MSys2 way please see
https://github.com/Alexpux/MINGW-packages and
https://github.com/msys2/msys2/wiki/Creating-packages
Building steps:
A. Install the MSys2 mingw packages needed to build wxQT/Win32 using the
configure/make build method.
From the MSys2 MinGW prompt:
pacman -S --needed --noconfirm make
pacman -S --needed --noconfirm ${MINGW_PACKAGE_PREFIX}-libjpeg-turbo
pacman -S --needed --noconfirm ${MINGW_PACKAGE_PREFIX}-libpng
pacman -S --needed --noconfirm ${MINGW_PACKAGE_PREFIX}-libtiff
pacman -S --needed --noconfirm ${MINGW_PACKAGE_PREFIX}-gcc
pacman -S --needed --noconfirm ${MINGW_PACKAGE_PREFIX}-pkg-config
pacman -S --needed --noconfirm ${MINGW_PACKAGE_PREFIX}-qt5
Packages that are needed but are normally installed already.
pacman -S --needed --noconfirm ${MINGW_PACKAGE_PREFIX}-gcc-libs
pacman -S --needed --noconfirm ${MINGW_PACKAGE_PREFIX}-expat
pacman -S --needed --noconfirm ${MINGW_PACKAGE_PREFIX}-xz
pacman -S --needed --noconfirm ${MINGW_PACKAGE_PREFIX}-zlib
pacman -S --needed --noconfirm ${MINGW_PACKAGE_PREFIX}-gdk-pixbuf2
B. Build the wxQT/Win32 static library
1. Open MSys2 MinGW Prompt
(These steps were tested on MinGW64; but, should work under MinGW32)
2. Use the cd command to change directory to the wxWidgets top folder.
3. Create the "build-${MSYSTEM_CARCH}-qt-static" folder to build the static libraries
mkdir -p build-${MSYSTEM_CARCH}-qt-static
4. Configure wxWidgets
Option "--disable-precomp-headers" is NOT needed.
It is being used to test for compile issues.
Remove configure option "--disable-wxdib" to set wxUSE_WXDIB to 1.
At the time these directions where written wxUSE_WXDIB set to 1
resulted in build error in dnd sample and run-time errors in
other samples.
cd build-${MSYSTEM_CARCH}-qt-static && \
../configure --with-qt \
--disable-wxdib \
--disable-shared \
--disable-precomp-headers \
&& cd ..
5. clean the wxQT static libraries
cd build-${MSYSTEM_CARCH}-qt-static && make clean && cd ..
6. make the wxQT static libraries
cd build-${MSYSTEM_CARCH}-qt-static && make && cd ..
C. Build and run the minimal static sample
1. Clean the minimal sample
cd build-${MSYSTEM_CARCH}-qt-static/samples/minimal && make clean && cd ../../..
2. Build the minimal sample
cd build-${MSYSTEM_CARCH}-qt-static/samples/minimal && make && cd ../../..
3. Run the minimal sample
./build-${MSYSTEM_CARCH}-qt-static/samples/minimal/minimal.exe
D. Build most of the static samples
1. Clean most of the static samples
cd build-${MSYSTEM_CARCH}-qt-static/samples && make clean && cd ../..
2. Build most of the static samples
cd build-${MSYSTEM_CARCH}-qt-static/samples && make && cd ../..
E. Run the drawing static sample
cd samples/drawing && ../../build-${MSYSTEM_CARCH}-qt-static/samples/drawing/drawing.exe && cd ../..
F. Run the splash static sample
cd samples/splash && ../../build-${MSYSTEM_CARCH}-qt-static/samples/splash/splash.exe && cd ../..
G. Run the widgets static sample
cd samples/widgets && ../../build-${MSYSTEM_CARCH}-qt-static/samples/widgets/widgets.exe && cd ../..
H. Run the toolbar static sample
cd samples/toolbar && ../../build-${MSYSTEM_CARCH}-qt-static/samples/toolbar/toolbar.exe && cd ../..
I. Run the image static sample
cd samples/image && ../../build-${MSYSTEM_CARCH}-qt-static/samples/image/image.exe && cd ../..
J. Run the dnd static sample
cd samples/dnd && ../../build-${MSYSTEM_CARCH}-qt-static/samples/dnd/dnd.exe && cd ../..

72
docs/osx/install.md
View File

@@ -1,9 +1,9 @@
wxWidgets for OS X installation {#plat_osx_install}
wxWidgets for macOS installation {#plat_osx_install}
-----------------------------------
[TOC]
wxWidgets can be compiled using Apple's Cocoa library.
wxWidgets can be compiled using Apple's Cocoa toolkit.
Most OS X developers should start by downloading and installing Xcode
from the App Store. It is a free IDE from Apple that provides
@@ -33,7 +33,7 @@ After the compilation completes, use Finder to run the samples and demos
* The source code for the samples is in wxWidgets/samples
* The source code for the demos is in wxWidgets/demos
More information about building on OS X is available in the wxWiki.
More information about building on macOS is available in the wxWiki.
Here are two useful links
* https://wiki.wxwidgets.org/Guides_%26_Tutorials
* https://wiki.wxwidgets.org/Development:_wxMac
@@ -45,6 +45,11 @@ Advanced topics {#osx_advanced}
Installing library {#osx_install}
------------------
It is rarely desirable to install non-Apple software into system directories,
so the recommended way of using wxWidgets under macOS is to skip the `make
install` step and simply use the full path to `wx-config` under the build
directory when building application using the library.
If you want to install the library into the system directories you'll need
to do this as root. The accepted way of running commands as root is to
use the built-in sudo mechanism. First of all, you must be using an
@@ -53,18 +58,15 @@ account marked as a "Computer Administrator". Then
sudo make install
type \<YOUR OWN PASSWORD\>
Note that while using this method is okay for development, it is not
recommended that you require endusers to install wxWidgets into their
system directories in order to use your program. One way to avoid this
is to configure wxWidgets with --disable-shared. Another way to avoid
it is to make a framework for wxWidgets. Making frameworks is beyond
the scope of this document.
**Note:**
It is rarely desirable to install non-Apple software into system directories.
By configuring the library with --disable-shared and using the full path
to wx-config with the --in-place option you can avoid installing the library.
Distributing applications using wxWidgets
-----------------------------------------
If you build wxWidgets as static libraries, i.e. pass `--disable-shared` option
to configure, you don't need to do anything special to distribute them, as all
the required code is linked into your application itself. When using shared
libraries (which is the default), you need to copy the libraries into your
application bundle and change their paths using `install_name_tool` so that
they are loaded from their new locations.
Apple Developer Tools: Xcode {#osx_xcode}
----------------------------
@@ -80,45 +82,3 @@ the libraries using commands like this:
$ cd utils/wxrc
$ g++ -o wxrc wxrc.cpp `wx-config --cxxflags --libs base,xml`
Creating universal binaries {#osx_universal_bin}
---------------------------
The Xcode projects for the wxWidgets library and minimal project are set up
to create universal binaries.
If using the Apple command line tools, pass --enable-universal_binary when
configuring wxWidgets. This will create the libraries for all the supported
architectures, currently ppc, i386 and x86_64 . You may explicitly specify
the architectures to use as a comma-separated list,
e.g. --enable-universal_binary=i386,x86_64.
Notice that if you use wx-config --libs to link your application, the -arch
flags are not added automatically as it is possible to link e.g. x86_64-only
program to a "fat" library containing other architectures. If you want to
build a universal application, you need to add the necessary "-arch xxx" flags
to your project or makefile separately.
As an alternative to using --enable-universal_binary, you can build for
each architecture separately and then use the lipo tool to glue the
binaries together. Assuming building on a PPC system:
1. First build in the usual way to get the PPC library.
2. Then, build for Intel, in a different folder. This time use:
export CFLAGS="-g -isysroot /Developer/SDKs/MacOSX10.7.sdk -arch i386"
export LDFLAGS="-syslibroot,/Developer/SDKs/MacOSX10.7.sdk"
./configure --disable-dependency-tracking --enable-static=yes --enable-shared=no \
--target=i386-apple-darwin8 --host=powerpc-apple-darwin8 --build=i386-apple-darwin8
You will need to reverse the powerpc and i386 parameters everywhere to build PPC on an Intel
machine.
3. Use lipo to glue the binaries together.
See also:
http://developer.apple.com/technotes/tn2005/tn2137.html

14
docs/publicity/WoWoW30.html
View File

@@ -75,7 +75,7 @@ documentation had to be corrected by hand making this effort one of
the biggest in the development cycle leading up wxWidgets 3.0.
Additionally, tools were written to automatically compare the
signature of the many class methods to the documentation. The result
is more correct documentation with better formating and built-in
is more correct documentation with better formatting and built-in
searching and screenshots of many controls. Since Doxygen is a
wide-spread format and easy to learn, the new documentation is much
easier to edit, correct and read. See the <A HREF="https://docs.wxwidgets.org/trunk/index.html">wxWidgets
@@ -147,10 +147,10 @@ see <A HREF="https://docs.wxwidgets.org/trunk/classwx_d_c.html">wxDC</A>,
<A HREF="https://docs.wxwidgets.org/trunk/classwx_brush.html">wxBrush</A>),
it has not changed much since its initial inception and so the code
was completely reorganized using a single set of frontend classes and
different backends which will make maintainance much easier without
different backends which will make maintenance much easier without
having to care for binary backwards compatibility and it also helped
isolate a number of subtle platform differences. The old drawing API
is good enough for many tasks and reflects the drawing capabilites of
is good enough for many tasks and reflects the drawing capabilities of
the 1990's but it didn't make use of advanced features such as
transparency, anti-aliasing and free matrix transforms of modern 2D
graphics systems such as GDI+ on Windows, Cairo on Linux (and
@@ -165,12 +165,12 @@ wxBRUSHSTYLE_SOLID etc. and the reference counting system was
streamlined and made identical on all platforms.</P>
<H3 CLASS="western">Changes to wxBase</H3>
<P ALIGN=JUSTIFY>wxBase is the name of the non-GUI part of wxWidgets
libary which provides basic class such as the aforementioned wxString
library which provides basic class such as the aforementioned wxString
class, container classes, as well as classes for threading,
networking, XML parsing, path and configuration management, logging,
debugging etc. These functions and classes have been separated into
their own library both for being able to write non-GUI apps as well
as to make maintainance easier through reduced interdependence.
as to make maintenance easier through reduced interdependence.
</P>
<P ALIGN=JUSTIFY>Many of the changes to wxString and the container
classes are located in wxBase, but on top of that support to wxBase
@@ -186,7 +186,7 @@ change. Rather, this paragraph summarizes the most relevant changes
to the GUI classes of wxWidgets. Given wxWidgets' nature as a GUI
library, these changes are also most likely to be visible to the user
and may thus be the most important changes from a user's perspective
(although not necessarily from a developer's perspective):
(although not necessarily from a developer's perspective):
</P>
<UL>
<LI><P ALIGN=JUSTIFY>wxDataViewCtrl and wxDataViewTreeCtrl: this
@@ -310,7 +310,7 @@ cases, supporting an old version of GTK+ hinders development so we
decided to declare GTK+ 2.6 the minimum toolkit version that is
supported. As an example, this made it possible to always use the
GTK+ file dialog instead of the old generic file dialog which had to
be used when GTK+ didn't have a usable file dialog.
be used when GTK+ didn't have a usable file dialog.
</P>
<P ALIGN=JUSTIFY STYLE="margin-bottom: 0cm">Other parts of wxGTK that
were rewritten or which underwent a major update include, but are not

48
docs/publicity/announce.txt
View File

@@ -1,44 +1,46 @@
December 10, 2018 -- The wxWidgets team is pleased to announce a new
July 22, 2020 -- The wxWidgets team is pleased to announce a new
release of our open source framework for the development of native
cross-platform applications in C++.
wxWidgets 3.1.2 is the latest release in the 3.1 development
wxWidgets 3.1.4 is the latest release in the 3.1 development
branch and is now available at
https://github.com/wxWidgets/wxWidgets/releases/tag/v3.1.2
https://www.wxwidgets.org/downloads/
Compared to the stable 3.0.x series, this version brings many
improvements and even more bug fixes, please see the change log
https://raw.githubusercontent.com/wxWidgets/wxWidgets/v3.1.2/docs/changes.txt
https://raw.githubusercontent.com/wxWidgets/wxWidgets/v3.1.4/docs/changes.txt
for the incomplete list of the most important ones. Here is the
maximally condensed summary of the changes compared to 3.0:
- Build system improvements: support for new compilers (MSVS 2017, g++ 8) and
OS versions (macOS 10.14 and its dark mode) as well as an entirely new CMake
build system.
- New features: support for mouse gesture events (GSoC 2017 project);
non-integer font sizes and arbitrary font weights in wxFont; fractional pen
widths in wxGraphicsContext; arbitrary label windows in wxStaticBox; markup
in wxDataViewCtrl items text; better support for high DPI monitors; support
for ZIP 64 files; LZMA compression; much improved accessibility support under
MSW.
- Build system improvements: support for new compilers (up to MSVS 2019, g++ 10)
with an even simpler way of using wxWidgets from MSVS, with wxwidgets.props
file, and OS versions as well as an entirely new CMake build system.
- Support for native dark mode under macOS 10.14 Mojave and later and support
for macOS 11 on ARM hardware.
- New features: implement freezing rows/columns in wxGrid; support for mouse
gesture events (GSoC 2017 project); non-integer font sizes and arbitrary font
weights in wxFont; fractional pen widths in wxGraphicsContext; arbitrary
label windows in wxStaticBox; markup in wxDataViewCtrl items text; better
support for high DPI monitors and per-monitor DPI and dynamic DPI changes
support under MSW; support for ZIP 64 files; LZMA compression; much improved
accessibility support under MSW; new Edge-based wxWebView implementation.
- New classes: wxActivityIndicator, wxAddRemoveCtrl,
wxAppProgressIndicator, wxNativeWindow, wxPowerResourceBlocker,
wxSecretStore.
- And methods: wxDataViewToggleRenderer::ShowAsRadio(), wxDateTime::
GetWeekBasedYear(), wxDisplay::GetPPI(), wxGrid::SetCornerLabelValue(),
wxHtmlEasyPrinting::SetPromptMode(), wxJoystickEvent::GetButtonOrdinal(),
wxListBox::GetTopItem(), wxProcess::Activate(), wxTextEntry::ForceUpper(),
several ones in wxRendererNative, wxStandardPaths::GetUserDir(),
wxToolbook::EnablePage(), wxUIActionSimulator::Select() and many others.
- Significant improvements to: wxBusyInfo, wxDataViewCtrl,
wxNotificationMessage, wxStaticBox, wxStyledTextCtrl.
wxSecretStore, wxTempFFile and many new features in the existing classes.
- New XRC handlers for all the new and some of the existing classes.
- Significant improvements to: wxBusyInfo, wxDataViewCtrl, wxDirDialog, wxGrid,
wxNotificationMessage, wxSpinCtrl, wxStaticBox, wxStyledTextCtrl,
wxUIActionSimulator.
- Improvements to compile-time safety with the possibility to disable dangerous
implicit conversions between wxString and "char*" strings.
- Latest versions of all bundled 3rd party libraries, including all the
security fixed and support for WebKit 2 and GStreamer 1.7 under Unix.
- Revamped OpenGL support better suited to modern OpenGL (3.2+).
- Further C++11 support improvements.
- Further C++11 and later support improvements, wxWidgets can be built using
C++20 compilers.
- A lot of bug fixes, especially in wxGTK3 and wxOSX/Cocoa ports.
- New experimental wxQt port.

16
docs/publicity/slogans.txt
View File

@@ -73,7 +73,7 @@ maybe stripped down to
"Specialization is for insects."
============================
The Open-Source, Cross-Platform GUI Framework
The Open-Source, Cross-Platform GUI Framework
with Ten Years of Evolution Behind It
I saw this changed to 'native UI' on the website, which is slightly more
@@ -81,17 +81,17 @@ accurate but sounds less 'catchy' imho.
.. and templates.
Hmm. I might buy a mug that had, say, a wxLogo and "wxWidgets" (and
maybe the website URL underneath in smaller type) on one side and
Hmm. I might buy a mug that had, say, a wxLogo and "wxWidgets" (and
maybe the website URL underneath in smaller type) on one side and
"Specialization is for insects ... and templates" on the other.
.. only if it held at leat a full half (imperial) pint, mind. Not
.. only if it held at least a full half (imperial) pint, mind. Not
one of those wussy 8.5 fl.oz. jobbies.
That'd be a nice ice-breaker when working at a new client's site -
That'd be a nice ice-breaker when working at a new client's site -
people would be bound to stop and ask what it was all about!
.. and how about a nice silk tie (US: necktie) with the logo on ...
.. and how about a nice silk tie (US: necktie) with the logo on ...
Oh, I forgot, we programmers don't wear ties.
============================
@@ -149,7 +149,7 @@ One API to bridge them all and in the compiler bind them.
wxWidgets
How about "and in the linker bind them"? That's where the local libraries
How about "and in the linker bind them"? That's where the local libraries
get bound to the wxWidgets code anyway.
============================
@@ -162,7 +162,7 @@ Hugh Gibson wrote:
> window control in different operating systems to emphasise the
> native look and feel.
Nice idea. But I wonder where you'll find some volunteer willing to
Nice idea. But I wonder where you'll find some volunteer willing to
have his face tattooed with win32 common controls ;-)
============================

8
docs/qt/architecture.md
View File

@@ -2,11 +2,11 @@
## Internals
wxQT uses the same techniques like other ports to wrap the Qt toolkit classes inside the wxWidget hierachy (especially similar to wxGTK).
wxQT uses the same techniques like other ports to wrap the Qt toolkit classes inside the wxWidget hierarchy (especially similar to wxGTK).
### Current (original) Approach
An '''internal pointer m_qtWindow''' in wxWindow holds the reference to the QWidget (or derived) counterpart, and is accesible through the virtual method '''GetHandle'''.
An '''internal pointer m_qtWindow''' in wxWindow holds the reference to the QWidget (or derived) counterpart, and is accessible through the virtual method '''GetHandle'''.
This pointer and other window styles are set up in the '''PostCreation''' method that must be called by the derived classes (mostly controls) to initialize the widget correctly.
Not doing so will cause painting and deletion issues, as the base class will not know how to handle the Qt widget.
wxControl even provides a protected method '''QtCreateControl''' that will do the common initialization (including post creation step, moving, sizing, etc., and calling the base to add the child to the parent).
@@ -19,7 +19,7 @@ Many controls have also other pointers to allow to map different sub-widgets and
### New (tentative) Approach
In the other end, Top Level Windows (frames and dialogs) '''uses directly the internal window pointer''', doing a static cast to return the correct type for GetHandle, avoiding multilevel pointer hierarchies.
This would be the ideal solution, but not all classes could be mapped 1:1 and that could introduce potential issues (i.e. invalid static casts) and more boilerplate due to additional specific accesor methods.
This would be the ideal solution, but not all classes could be mapped 1:1 and that could introduce potential issues (i.e. invalid static casts) and more boilerplate due to additional specific accessor methods.
For a longer discussion of pro and cons, see [PR#43 comments](https://github.com/reingart/wxWidgets/pull/43)
@@ -59,7 +59,7 @@ The approach chosen was to use templates to help inherit QObject's (QWidget), pr
### Delete later
Both templates also have some safety checks to avoid invalid spurious access to deleted wx objects (using a special pointer to the wx instance stored in the Qt object, that is reseted to NULL when the wx counterpart is marked to deletion).
Both templates also have some safety checks to avoid invalid spurious access to deleted wx objects (using a special pointer to the wx instance stored in the Qt object, that is reset to NULL when the wx counterpart is marked to deletion).
This is due that in some situations, Qt object could still be referenced in the Qt event queue, so it cannot be removed immediately.

2
docs/qt/install.md
View File

@@ -140,7 +140,7 @@ the android_armv5/ android_armv7/ android_x86/ pre-compiled folders to
cross-compile for that architectures)
Then, create a build directory (under the wxWidgets folder), configure for
Andrid (disable currently unsupported/uneeded features) and run make:
Android (disable currently unsupported/unneeded features) and run make:
cd ~/src/wxWidgets
mkdir bldqt5droid

58
docs/readme.txt
View File

@@ -1,4 +1,4 @@
wxWidgets 3.1.3 Release Notes
wxWidgets 3.1.5 Release Notes
=============================
Welcome to the latest development release of wxWidgets, a free and open source
@@ -16,22 +16,45 @@ more about wxWidgets at:
Documentation is available online at:
* https://docs.wxwidgets.org/3.1.3/
* https://docs.wxwidgets.org/3.1.5/
wxWidgets sources and binaries for the selected platforms are available for
download from:
* https://github.com/wxWidgets/wxWidgets/releases/tag/v3.1.3/
* https://www.wxwidgets.org/downloads/
or, for a more more permanent but less convenient to use link, from
* https://github.com/wxWidgets/wxWidgets/releases/tag/v3.1.5/
Changes since 3.1.2
Changes since 3.1.3
-------------------
TODO: Fill in
In the nine months since the previous release, there have been almost 1700
commits from 74 unique contributors (37 with multiple contributions), so it is
impossible to summarize all the changes in this document without making it too
long, please see the fuller changelog at
Notice that this release is almost completely compatible with 3.1.2 at the API
level, so upgrading to it if you're already using wxWidgets 3 should be
straightforward.
https://raw.githubusercontent.com/wxWidgets/wxWidgets/v3.1.5/docs/changes.txt
for more (but still not all) details, but some of the most important changes are:
- wxOSX port now supports the latest macOS 11 on ARM hardware.
- wxMSW comes with a new Edge-based wxWebView implementation.
- Better, although still not perfect, per-monitor DPI support in wxMSW.
- wxGrid was has been significantly improved and is now much user friendlier.
- AUI appearance enhancements for non-default GTK themes and macOS dark mode.
- wxWidgets may now be built with C++20 compiler.
- Improvements to CMake build system.
- Allow optionally forbidding dangerous implicit wxString conversions.
And, of course, there were many, many bug fixes in all ports, notably including
fixing several long-standing problems in wxOSX.
Notice that in spite of all the changes, this release remains almost completely
compatible with 3.1.3 at the API level, so upgrading to it if you're already
using wxWidgets 3 should be straightforward.
Changes since 3.0
@@ -41,13 +64,16 @@ Compared to the stable 3.0.x series, this version brings too many
improvements and even more bug fixes to list them all, but here is the
maximally condensed summary:
- Build system improvements: support for new compilers (MSVS 2017, g++ 8) and
OS versions as well as an entirely new CMake build system.
- Build system improvements: support for new compilers (up to MSVS 2019, g++ 10)
with an even simpler way of using wxWidgets from MSVS, with wxwidgets.props
file, and OS versions as well as an entirely new CMake build system.
- Support for native dark mode under macOS 10.14 Mojave and later.
- New features: support for mouse gesture events (GSoC 2017 project);
fractional pen widths in wxGraphicsContext; arbitrary label windows in
wxStaticBox; markup in wxDataViewCtrl items text; better support for high DPI
monitors; support for ZIP 64 files; much improved accessibility support under
MSW.
MSW; Support for non-integer font sizes and arbitrary font weights; LZMA
compression support (using liblzma).
- New classes: wxActivityIndicator, wxAddRemoveCtrl,
wxAppProgressIndicator, wxNativeWindow, wxPowerResourceBlocker,
wxSecretStore.
@@ -73,7 +99,7 @@ This version of wxWidgets supports the following primary platforms:
* Windows XP, Vista, 7, 8 and 10 (32/64 bits).
* Most Unix variants using the GTK+ toolkit (version 2.6 or newer)
* OS X (10.7 or newer) using Cocoa (32/64 bits)
* macOS (10.10 or newer) using Cocoa (32/64 bits)
There is some support for the following platforms:
@@ -82,8 +108,8 @@ There is some support for the following platforms:
* Most Unix variants with GTK+ 1.2
* Most Unix variants with Qt 5 or newer (experimental)
Most popular C++ compilers are supported; see the install.txt file for each
platform (following the links from docs/index.htm).
All C++ compilers in common use are supported; see the install.txt file for
each platform (following the links from docs/index.htm).
Files
@@ -92,7 +118,7 @@ Files
wxWidgets is distributed in source form in several archive formats. ZIP and 7z
archives are for Microsoft Windows users and contain the files with DOS/Windows
line endings while the compressed tar archives are for Unix systems (including
OS X) and contain the files with Unix line endings. Please notice that some
macOS) and contain the files with Unix line endings. Please notice that some
Windows tools still don't accept files with Unix line endings and that compiling
sources with DOS line endings under Unix will fail, so please choose the correct
file for your system.
@@ -190,4 +216,4 @@ developed by its users and your contributions to it are always welcome!
Have fun!
The wxWidgets Team, December 2018
The wxWidgets Team, July 2020

134
docs/release.md
View File

@@ -1,105 +1,107 @@
Welcome to wxWidgets, a free and open source cross-platform C++ framework for writing advanced GUI applications using native controls.
wxWidgets 3.1.2 is the latest release in the 3.1 development branch. This release is a "development" one as it makes (very few) incompatible API changes compared to 3.0 and does not guarantee the ABI stability, unlike the 3.0.x series. It is not inherently more buggy or less stable than the "stable" releases and you're encouraged to use it, including in production. If you're already using 3.0, upgrading shouldn't require any special effort, so please try it out.
wxWidgets 3.1.4 is the latest release in the 3.1 development branch. This release is a "development" one as it makes (very few) incompatible API changes compared to 3.0 and does not guarantee the ABI stability, unlike the 3.0.x series. It is not inherently more buggy or less stable than the "stable" releases and you're encouraged to use it, including in production. If you're already using 3.0, upgrading shouldn't require any special effort, so please try it out.
Please see [**README**](https://raw.githubusercontent.com/wxWidgets/wxWidgets/v3.1.2/docs/readme.txt) for more information about this release and the [change log](https://raw.githubusercontent.com/wxWidgets/wxWidgets/v3.1.2/docs/changes.txt) for the details of the changes in it.
Please see [**README**](https://raw.githubusercontent.com/wxWidgets/wxWidgets/v3.1.4/docs/readme.txt) for more information about this release and the [change log](https://raw.githubusercontent.com/wxWidgets/wxWidgets/v3.1.4/docs/changes.txt) for more details of the changes in it.
## Source Files and Documentation
If you intend to build wxWidgets from sources (which is recommended), please do **NOT** download the files using the "Source code" links just above, which are automatically generated by GitHub and don't contain the submodules sources which are necessary for building wxWidgets.
Instead, download one of [wxWidgets-3.1.2.zip](https://github.com/wxWidgets/wxWidgets/releases/download/v3.1.2/wxWidgets-3.1.2.zip) or [wxWidgets-3.1.2.7z](https://github.com/wxWidgets/wxWidgets/releases/download/v3.1.2/wxWidgets-3.1.2.7z), for much smaller size, for Microsoft Windows systems or [wxWidgets-3.1.2.tar.bz2](https://github.com/wxWidgets/wxWidgets/releases/download/v3.1.2/wxWidgets-3.1.2.tar.bz2) for Unix ones, including macOS. These archives have exactly the same contents, but use the line endings appropriate for the corresponding platform.
Instead, download one of [wxWidgets-3.1.4.zip](https://github.com/wxWidgets/wxWidgets/releases/download/v3.1.4/wxWidgets-3.1.4.zip) or [wxWidgets-3.1.4.7z](https://github.com/wxWidgets/wxWidgets/releases/download/v3.1.4/wxWidgets-3.1.4.7z), for much smaller size, for Microsoft Windows systems or [wxWidgets-3.1.4.tar.bz2](https://github.com/wxWidgets/wxWidgets/releases/download/v3.1.4/wxWidgets-3.1.4.tar.bz2) for Unix ones, including macOS. These archives have exactly the same contents, but use the line endings appropriate for the corresponding platform.
In addition, we provide archives containing the documentation in either HTML or Microsoft CHM formats. Notice that the documentation is also [available online](https://docs.wxwidgets.org/3.1.2).
In addition, we provide archives containing the documentation in either HTML or Microsoft CHM formats. Notice that the documentation is also [available online](https://docs.wxwidgets.org/3.1.4).
Finally, Microsoft Windows users may download [Setup.exe file](https://github.com/wxWidgets/wxWidgets/releases/download/v3.1.2/wxMSW-3.1.2-Setup.exe) containing both sources and documentation, however please note that this file does _not_ contain any binaries, please see below for those.
Finally, Microsoft Windows users may download [Setup.exe file](https://github.com/wxWidgets/wxWidgets/releases/download/v3.1.4/wxMSW-3.1.4-Setup.exe) containing both sources and documentation, however please note that this file does _not_ contain any binaries, please see below for those.
To verify your download please use the following SHA-1 checksums:
85ac5b18de191d9d5504b7106466b21b64e7249d wxMSW-3.1.2-Setup.exe
40a1469a13023f12a56bcbcfec2c1172fe1b86d6 wxWidgets-3.1.2-docs-chm.zip
393f6bca6c5c4fc178a9312fae5bddc04233b7bb wxWidgets-3.1.2-docs-html.tar.bz2
e51475ec38628b7080af01963bbf43f2151121c8 wxWidgets-3.1.2-docs-html.zip
e6335af2fc8c9058d442bbb7ef456c3c5594e7fe wxWidgets-3.1.2-headers.7z
0737ccc29f8d625496e425cb7d0ff8207343609b wxWidgets-3.1.2.7z
29cbbba946d2a7b4d28ca1db12315810cc8de74d wxWidgets-3.1.2.tar.bz2
ec7114242f2df2706bb90bd76fa3b79f83f1b05d wxWidgets-3.1.2.zip
7e19253507156efc61dd8657af798177717775fe wxMSW-3.1.4-Setup.exe
d5c642b4adfc413270172deeb807474a129c52fd wxWidgets-3.1.4-docs-chm.zip
6d769104a4d8cad7f3e028c6b022f3a850ba99e0 wxWidgets-3.1.4-docs-html.tar.bz2
445063cbd8e11085b78d8c33e21ba65b54b68fdd wxWidgets-3.1.4-docs-html.zip
fe15946b9aacd469586edfe89afac51b3d750209 wxWidgets-3.1.4-headers.7z
f5eed3129a7cfa9e462e5d3029673b6d87267efd wxWidgets-3.1.4.7z
f8c77e6336b5f6414b07e27baa489fb8abc620c4 wxWidgets-3.1.4.tar.bz2
be1ec2cc03a97682f96e2fb8a50ac7ebf52d6a8d wxWidgets-3.1.4.zip
## Binaries
We provide pre-built binary files for the following compilers:
* Microsoft Visual C++ compiler versions 9.0, 10.0, 11.0, 12.0, 14.0 and 14.1 (corresponding to marketing product names of Microsoft Visual Studio 2008, 2010, 2012, 2013, 2015 and 2017 respectively).
* TDM-GCC version 5.1 and MinGW-w64 versions 7.3 and 8.1 (with the default SJLJ exceptions propagation method, using C++11).
* Microsoft Visual C++ compiler versions 9.0, 10.0, 11.0, 12.0, 14.0, 14.1 and 14.2 (corresponding to marketing product names of Microsoft Visual Studio 2008, 2010, 2012, 2013, 2015, 2017 and 2019 respectively). Please note that MSVC 14.x versions are ABI-compatible and the same set of binaries is used for all of them.
* MinGW-w64 versions 7.3 and 8.1 (32-bit binaries use SJLJ exceptions, 64-bit ones use SEH, and all binaries use Win32 threads).
* [TDM-GCC](https://jmeubank.github.io/tdm-gcc/) 9.2.0.
### For Developers
For developing applications with wxWidgets you need to download the compiler-independent `wxWidgets-3.1.2_Headers.7z` file and one of `wxMSW-3.1.2-vcXXX_Dev.7z` or `wxMSW-3.1.2_gccXXX_Dev.7z` files depending on your compiler, its version and the target architecture (x86 if not specified or x64).
For developing applications with wxWidgets you need to download the compiler-independent `wxWidgets-3.1.4_Headers.7z` file and one of `wxMSW-3.1.4-vcXXX_Dev.7z` or `wxMSW-3.1.4_gccXXX_Dev.7z` files depending on your compiler, its version and the target architecture (x86 if not specified or x64).
Unpack both files into the same directory so that `include` and `lib` directories are at the same level after unpacking. You should be able to compile and link applications using wxWidgets in both debug and release modes but the debug symbols are provided only for debug libraries in this archive, see below for the release build debug symbols.
Note that if you're setting up a new project using these binaries, the simplest
way to do it is to use the provided `wxwidgets.props` file: for this, open the
`View|Property Manager` menu item in the IDE, select "Add Existing Property
Sheet..." from the project context menu and browse to this file in the file
open dialog.
### For End Users
End users may download one of `wxMSW-3.1.2_vcXXX_ReleaseDLL.7z` or `wxMSW-3.1.2_gccXXX_ReleaseDLL.7z` files to get just the DLLs required for running the applications using wxWidgets.
End users may download one of `wxMSW-3.1.4_vcXXX_ReleaseDLL.7z` or `wxMSW-3.1.4_gccXXX_ReleaseDLL.7z` files to get just the DLLs required for running the applications using wxWidgets.
### For Debugging
* Microsoft Visual C++ users: Files `wxMSW-3.1.2_vcXXX_ReleasePDB.7z` contain the debug symbols for the release build of the DLLs. Download them if you want to debug your own applications in release build or if you want to get meaningful information from mini-dumps retrieved from your users machines.
* Microsoft Visual C++ users: Files `wxMSW-3.1.4_vcXXX_ReleasePDB.7z` contain the debug symbols for the release build of the DLLs. Download them if you want to debug your own applications in release build or if you want to get meaningful information from mini-dumps retrieved from your users machines.
* MinGW-TDM users: Currently the debug symbols are not available for the release build of the DLLs (only the debug versions of the DLLs contains the debug symbols).
### Binary File Download Verification
To verify your download please use the following SHA-1 checksums:
0000000000000000000000000000000000000000 wxMSW-3.1.2_gcc510TDM_Dev.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_gcc510TDM_ReleaseDLL.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_gcc510TDM_x64_Dev.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_gcc510TDM_x64_ReleaseDLL.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_gcc730_Dev.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_gcc730_ReleaseDLL.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_gcc730_x64_Dev.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_gcc730_x64_ReleaseDLL.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_gcc810_Dev.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_gcc810_ReleaseDLL.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_gcc810_x64_Dev.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_gcc810_x64_ReleaseDLL.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_vc90_Dev.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_vc90_ReleaseDLL.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_vc90_ReleasePDB.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_vc90_x64_Dev.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_vc90_x64_ReleaseDLL.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_vc90_x64_ReleasePDB.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_vc100_Dev.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_vc100_ReleaseDLL.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_vc100_ReleasePDB.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_vc100_x64_Dev.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_vc100_x64_ReleaseDLL.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_vc100_x64_ReleasePDB.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_vc110_Dev.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_vc110_ReleaseDLL.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_vc110_ReleasePDB.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_vc110_x64_Dev.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_vc110_x64_ReleaseDLL.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_vc110_x64_ReleasePDB.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_vc120_Dev.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_vc120_ReleaseDLL.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_vc120_ReleasePDB.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_vc120_x64_Dev.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_vc120_x64_ReleaseDLL.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_vc120_x64_ReleasePDB.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_vc140_Dev.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_vc140_ReleaseDLL.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_vc140_ReleasePDB.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_vc140_x64_Dev.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_vc140_x64_ReleaseDLL.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_vc140_x64_ReleasePDB.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_vc141_Dev.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_vc141_ReleaseDLL.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_vc141_ReleasePDB.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_vc141_x64_Dev.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_vc141_x64_ReleaseDLL.7z
0000000000000000000000000000000000000000 wxMSW-3.1.2_vc141_x64_ReleasePDB.7z
6a79e7c4356dd8c5b5d687de2f87f583d71f2c2a wxMSW-3.1.4_gcc730_Dev.7z
8dcb3c582c09d680581f913661784c785c90fa6c wxMSW-3.1.4_gcc730_ReleaseDLL.7z
2d9c0268c856157c90da95d11ef499cb8bba0ac3 wxMSW-3.1.4_gcc730_x64_Dev.7z
5f218e7897210c5422e2b9e088b67ba0842dd272 wxMSW-3.1.4_gcc730_x64_ReleaseDLL.7z
965c3c7429ab21ded9f0fc89d38459423b890107 wxMSW-3.1.4_gcc810_Dev.7z
a9ce630504da31761bcce2b23108c8190b25005a wxMSW-3.1.4_gcc810_ReleaseDLL.7z
9c560cb05d6f3ee05a2879192eee82d062cb52e0 wxMSW-3.1.4_gcc810_x64_Dev.7z
946a5cee45a24d4a50c0cd2c2515524406049e08 wxMSW-3.1.4_gcc810_x64_ReleaseDLL.7z
da39a3ee5e6b4b0d3255bfef95601890afd80709 wxMSW-3.1.4_gcc920TDM_Dev.7z
d6af63b5691609f64e8a1281336c908be8385460 wxMSW-3.1.4_gcc920TDM_Dev.7z.part
1c9ae729f3e4785c1e11a2e6bb44882c22612217 wxMSW-3.1.4_gcc920TDM_ReleaseDLL.7z
9254447e7ec8b5d73296db901c3745ce42651842 wxMSW-3.1.4_gcc920TDM_x64_Dev.7z
5b2d57889e55b4f61457b2ac501f61e3756b67ec wxMSW-3.1.4_gcc920TDM_x64_ReleaseDLL.7z
55ec77bc8b66302b44103b766cf00068659da913 wxMSW-3.1.4_vc90_Dev.7z
1933b9b471ae2916e00af615ff18ee341b69646b wxMSW-3.1.4_vc90_ReleaseDLL.7z
f51347d78dbdb68cef0f063f50a2f0782d50c275 wxMSW-3.1.4_vc90_ReleasePDB.7z
4e8d0ea573d50db624d611add06beaa9b4b6a1d1 wxMSW-3.1.4_vc90_x64_Dev.7z
fde90dae3f86303dcc7ff80aa7f6287851f5e179 wxMSW-3.1.4_vc90_x64_ReleaseDLL.7z
7d8cd56de140e86457307d801c561dfaa72f0ede wxMSW-3.1.4_vc90_x64_ReleasePDB.7z
9668414a32464940df0dcb6d5022b77efe45807a wxMSW-3.1.4_vc100_Dev.7z
561570696849d513e0b950f9922e1b487f5b37ce wxMSW-3.1.4_vc100_ReleaseDLL.7z
917c359d7e659162c739664b4b0cc9099f3fc612 wxMSW-3.1.4_vc100_ReleasePDB.7z
dc895929385d4ef57288703afc801ca4d5925fc4 wxMSW-3.1.4_vc100_x64_Dev.7z
596300c3122e1888646ac890d5a21b9be64cd2fc wxMSW-3.1.4_vc100_x64_ReleaseDLL.7z
f1f7e5850d29b1f24fbe26e606723b3e4fa0082b wxMSW-3.1.4_vc100_x64_ReleasePDB.7z
99f3651d1857f4580347cf941de0bc440586e3b9 wxMSW-3.1.4_vc110_Dev.7z
63279dfbbf614274e8dd7101ab210c2a5caa9ab1 wxMSW-3.1.4_vc110_ReleaseDLL.7z
9bbcab032f3c5fc90bd841f4585a4e7d292285eb wxMSW-3.1.4_vc110_ReleasePDB.7z
3c00a218c2044efc54ea25102858ca67563cbbcd wxMSW-3.1.4_vc110_x64_Dev.7z
f69c86dc4840d1ecc0d35db0ef0e9137894dae6f wxMSW-3.1.4_vc110_x64_ReleaseDLL.7z
4462b101aa5371fae26e5c0a776ccb5028c9e954 wxMSW-3.1.4_vc110_x64_ReleasePDB.7z
a631c1e4ebb6cc12d76584ac27364f0905678fb9 wxMSW-3.1.4_vc120_Dev.7z
d29b3a699357516de2f1af06fc718f0d58139fe6 wxMSW-3.1.4_vc120_ReleaseDLL.7z
84093a3b358a47efeab9a5788834eeeb1dc1d1d7 wxMSW-3.1.4_vc120_ReleasePDB.7z
0a9e1a8818176646f618372ca2a55093c346745b wxMSW-3.1.4_vc120_x64_Dev.7z
28f5f4dc8768e111f8485b4cf11435b78038f027 wxMSW-3.1.4_vc120_x64_ReleaseDLL.7z
a7e9f285f15bf4091364f1e81511f8a51c13f0bf wxMSW-3.1.4_vc120_x64_ReleasePDB.7z
53ca996900a1174b1ef3fb1449cac16de69ad32e wxMSW-3.1.4_vc14x_Dev.7z
e5276f1d1eb92e40c107097e3ac6835ca434ba98 wxMSW-3.1.4_vc14x_ReleaseDLL.7z
55d5503078d8fcf0338d757b5493125f9a4f5567 wxMSW-3.1.4_vc14x_ReleasePDB.7z
33da2620195dc261147f4f7dfb7fe01bb46884e2 wxMSW-3.1.4_vc14x_x64_Dev.7z
442c7ae5121c29f6718e703e1673268d2737c16b wxMSW-3.1.4_vc14x_x64_ReleaseDLL.7z
dc7cd62c853f1253b7f0ecacf7d69887af593951 wxMSW-3.1.4_vc14x_x64_ReleasePDB.7z
## Reporting Problems

8
docs/univ/readme.txt
View File

@@ -59,14 +59,6 @@ b) Cygwin
** the instructions may be out of date as for wxWidgets 2.5.2+ **
c) Other compilers
Borland:
in the wxwindows\src\msw directory run
'make -f makefile.b32 WXUSINGUNIV=1' to build the library and then run
'make -f makefile.b32 WXUSINGUNIV=1' in the sample directory which you wish
to build using the wxUniversal widgets. Use 'SET WXTHEME=GTK' [or WIN32 or METAL]
to test the existing themes
Unfortunately we don't have makefiles for any other compilers yet.
Please contact us if you would like to help us with creating one for the
compiler you use.

10
docs/vms/readme.txt
View File

@@ -7,7 +7,7 @@ The compilation was tested with
-Compaq C++ 6.2
-DECWindows 1.2-5
-GTK1.2.8 (for wxGTK)
To get everything compiled you'll need to have installed prior to compiling
wxWidgets:
-Bison
@@ -19,7 +19,7 @@ wxWidgets:
#define alloca malloc
before
#endif /* __hpux */
-Flex
get it from http://www.openvms.digital.com/freeware/
@@ -119,7 +119,7 @@ $ ass $disk2:[joukj.public.gtk.gtk.glib],-
-I think in general wxGTK is better maintained, so that version is my
first choice.
-Note that only a few people have used wxWidgets on VMS so many problems are
to be expected.
@@ -147,7 +147,7 @@ $ ass $disk2:[joukj.public.gtk.gtk.glib],-
again.
-image sample: after clicking "about" the colourmap is permanently
changed resulting in strange images
Finally :
I like the idea of Robert Roebling that CD's with classical music should be
send to the authors.
@@ -156,7 +156,7 @@ send to the authors.
>-----------------------------------------------------------------------------<
Jouk Jansen
joukj@hrem.stm.tudelft.nl

2
docs/wine/COPYING.LIB
View File

@@ -133,7 +133,7 @@ such a program is covered only if its contents constitute a work based
on the Library (independent of the use of the Library in a tool for
writing it). Whether that is true depends on what the Library does
and what the program that uses the Library does.
1. You may copy and distribute verbatim copies of the Library's
complete source code as you receive it, in any medium, provided that
you conspicuously and appropriately publish on each copy an

2
docs/wine/changes.txt
View File

@@ -9,4 +9,4 @@ for wxWINE is in place and that all that has to be done to get
wxWINE running is to make WINE work as Win32. No joke intended.
Robert Roebling

136
docs/wine/install.txt
View File

@@ -2,7 +2,7 @@
* The most simple case
-----------------------
If you compile wxWidgets on Linux for the first time and don't like to read
If you compile wxWidgets on Linux for the first time and don't like to read
install instructions just do (in the base dir):
> ./configure --with-wine
@@ -12,8 +12,8 @@ install instructions just do (in the base dir):
> ldconfig
> exit
On all variants of Unix except Linux (and maybe except *BSD), shared libraries
are not supported out of the box due to the utter stupidity of libtool, so you'll
On all variants of Unix except Linux (and maybe except *BSD), shared libraries
are not supported out of the box due to the utter stupidity of libtool, so you'll
have to do this to get shared library support:
> ./configure --with-wine --disable-unicode --disable-static --enable-shared
@@ -23,12 +23,12 @@ important entries with respect to shared library creation, which are
archive_cmds="\$LD -shared ....
archive_expsym_cmds="\$LD -shared ....
which should be something like
archive_cmds="\$CC -shared ....
archive_expsym_cmds="\$CC -shared ....
Afterwards you can continue with
> make
@@ -47,14 +47,14 @@ If you want to remove wxWidgets on Unix you can do this:
* The expert case
-----------------
If you want to do some more serious cross-platform programming with wxWidgets,
such as for GTK and Motif, you can now build two complete libraries and use
them concurrently. For this end, you have to create a directory for each build
If you want to do some more serious cross-platform programming with wxWidgets,
such as for GTK and Motif, you can now build two complete libraries and use
them concurrently. For this end, you have to create a directory for each build
of wxWidgets - you may also want to create different versions of wxWidgets
and test them concurrently. Most typically, this would be a version configured
with --enable-debug_flag and one without. Note, that only one build can currently
and test them concurrently. Most typically, this would be a version configured
with --enable-debug_flag and one without. Note, that only one build can currently
be installed, so you'd have to use local version of the library for that purpose.
For building three versions (one GTK, one WINE and a debug version of the WINE
For building three versions (one GTK, one WINE and a debug version of the WINE
source) you'd do this:
md buildmotif
@@ -78,18 +78,18 @@ cd ..
* The most simple errors
------------------------
wxWINE doesn't work yet as WINE isn't really up to the task yet.
wxWINE doesn't work yet as WINE isn't really up to the task yet.
You get errors during compilation: The reason is that you probably have a broken
compiler, which includes almost everything that is called gcc. If you use gcc 2.8
you have to disable optimisation as the compiler will give up with an internal
You get errors during compilation: The reason is that you probably have a broken
compiler, which includes almost everything that is called gcc. If you use gcc 2.8
you have to disable optimisation as the compiler will give up with an internal
compiler error.
If there is just any way for you to use egcs, use egcs. We cannot fix gcc.
You get immediate segfault when starting any sample or application: This is either
due to having compiled the library with different flags or options than your program -
typically you might have the __WXDEBUG__ option set for the library but not for your
You get immediate segfault when starting any sample or application: This is either
due to having compiled the library with different flags or options than your program -
typically you might have the __WXDEBUG__ option set for the library but not for your
program - or due to using a broken compiler (and its optimisation) such as GCC 2.8.
* The most simple program
@@ -102,27 +102,27 @@ g++ myfoo.cpp `wx-config --libs --cflags` -o myfoo
* General
-----------------------
The Unix variants of wxWidgets use GNU configure. If you have problems with your
The Unix variants of wxWidgets use GNU configure. If you have problems with your
make use GNU make instead.
If you have general problems with installation, read my homepage at
If you have general problems with installation, read my homepage at
http://wesley.informatik.uni-freiburg.de/~wxxt
for newest information. If you still don't have any success, please send a bug
report to one of our mailing lists (see my homepage) INCLUDING A DESCRIPTION OF
YOUR SYSTEM AND YOUR PROBLEM, SUCH AS YOUR VERSION OF WINE, WXWINE, WHAT DISTRIBUTION
for newest information. If you still don't have any success, please send a bug
report to one of our mailing lists (see my homepage) INCLUDING A DESCRIPTION OF
YOUR SYSTEM AND YOUR PROBLEM, SUCH AS YOUR VERSION OF WINE, WXWINE, WHAT DISTRIBUTION
YOU USE AND WHAT ERROR WAS REPORTED. I know this has no effect, but I tried...
* GUI libraries
-----------------------
wxWidgets/WINE requires the WINE library to be installed on your system.
wxWidgets/WINE requires the WINE library to be installed on your system.
You can get the newest version of the WINE from the WINE homepage at:
http://www.winehq.com
* Create your configuration
-----------------------------
@@ -141,16 +141,16 @@ to see all the options please use:
./configure --help
The basic philosophy is that if you want to use different
configurations, like a debug and a release version,
configurations, like a debug and a release version,
or use the same source tree on different systems,
you have only to change the environment variable OSTYPE.
(Sadly this variable is not set by default on some systems
in some shells - on SGI's for example). So you will have to
set it there. This variable HAS to be set before starting
configure, so that it knows which system it tries to
in some shells - on SGI's for example). So you will have to
set it there. This variable HAS to be set before starting
configure, so that it knows which system it tries to
configure for.
Configure will complain if the system variable OSTYPE has
Configure will complain if the system variable OSTYPE has
not been defined. And Make in some circumstances as well...
@@ -167,7 +167,7 @@ in wxWidgets snapshot 6, but not yet all (ODBC not).
You must do this by running configure with either of:
--with-wine Use the WINE library
The following options handle the kind of library you want to build.
--enable-threads Compile with thread support. Threads
@@ -182,25 +182,25 @@ The following options handle the kind of library you want to build.
such as Sun with gcc 2.8.X which
would otherwise produce segvs.
--enable-profile Add profiling info to the object
--enable-profile Add profiling info to the object
files. Currently broken, I think.
--enable-no_rtti Enable compilation without creation of
C++ RTTI information in object files.
This will speed-up compilation and reduce
C++ RTTI information in object files.
This will speed-up compilation and reduce
binary size.
--enable-no_exceptions Enable compilation without creation of
C++ exception information in object files.
This will speed-up compilation and reduce
C++ exception information in object files.
This will speed-up compilation and reduce
binary size. Also fewer crashes during the
actual compilation...
--enable-mem_tracing Add built-in memory tracing.
--enable-mem_tracing Add built-in memory tracing.
--enable-dmalloc Use the dmalloc memory debugger.
Read more at www.letters.com/dmalloc/
--enable-debug_info Add debug info to object files and
executables for use with debuggers
such as gdb (or its many frontends).
@@ -210,7 +210,7 @@ The following options handle the kind of library you want to build.
useful internal debugging tricks (such
as automatically reporting illegal calls)
to work. Note that program and library
must be compiled with the same debug
must be compiled with the same debug
options.
* Feature Options
@@ -221,42 +221,42 @@ in wxWidgets snapshot 6, but not yet all (ODBC not).
When producing an executable that is linked statically with wxGTK
you'll be surprised at its immense size. This can sometimes be
drastically reduced by removing features from wxWidgets that
drastically reduced by removing features from wxWidgets that
are not used in your program. The most relevant such features
are
--without-libpng Disables PNG image format code.
--without-libjpeg Disables JPEG image format code.
{ --without-odbc Disables ODBC code. Not yet. }
--disable-resources Disables the use of *.wxr type
resources.
--disable-threads Disables threads. Will also
disable sockets.
--disable-sockets Disables sockets.
--disable-dnd Disables Drag'n'Drop.
--disable-clipboard Disables Clipboard.
--disable-serial Disables object instance serialisation.
--disable-streams Disables the wxStream classes.
--disable-file Disables the wxFile class.
--disable-textfile Disables the wxTextFile class.
--disable-intl Disables the internationalisation.
--disable-validators Disables validators.
--disable-accel Disables accel.
Apart from disabling certain features you can very often "strip"
the program of its debugging information resulting in a significant
reduction in size.
@@ -267,13 +267,13 @@ reduction in size.
The following must be done in the base directory (e.g. ~/wxGTK
or ~/wxWin or whatever)
Now the makefiles are created (by configure) and you can compile
Now the makefiles are created (by configure) and you can compile
the library by typing:
make
make yourself some coffee, as it will take some time. On an old
386SX possibly two weeks. During compilation, you'll get a few
386SX possibly two weeks. During compilation, you'll get a few
warning messages depending in your compiler.
If you want to be more selective, you can change into a specific
@@ -284,12 +284,12 @@ Then you may install the library and its header files under
have to log in as root (i.e. run "su" and enter the root
password) and type
make install
make install
You can remove any traces of wxWidgets by typing
make uninstall
If you want to save disk space by removing unnecessary
object-files:
@@ -316,13 +316,13 @@ minimal: minimal.o
minimal.o: minimal.cpp
$(CXX) `wx-config --cflags` -c minimal.cpp -o minimal.o
clean:
clean:
rm -f *.o minimal
This is certain to become the standard way unless we decide
to stick to tmake.
2) The other way creates a project within the source code
2) The other way creates a project within the source code
directories of wxWidgets. For this endeavour, you'll need
the usual number of GNU tools, at least
@@ -331,7 +331,7 @@ GNU autoheader version 2.14
GNU autoconf version 2.14
GNU libtool version 1.3
and quite possibly
and quite possibly
GNU make
GNU C++
@@ -344,10 +344,10 @@ go ahead yourself :-)
In the hope that it will be useful,
Robert Roebling <roebling@sun2.ruf.uni-freiburg.de>
Addition notes by Julian Smart, August 2002
===========================================
===========================================
I've fixed some compile errors, and got as far as
compiling wxWINE, but actually linking a sample will take
@@ -367,7 +367,7 @@ configure --disable-static --enable-shared --enable-gui \
--with-libjpeg --enable-debug_cntxt
Compiling a sample won't work yet because 'winebuild' needs
to be called, and the resuling C file compiled and linked.
to be called, and the resulting C file compiled and linked.
Plus, Windows DLLs need to be imported.
Note that the documentation on the WINE web site on using

8
docs/wine/readme.txt
View File

@@ -9,15 +9,15 @@ install.txt.
When you run into problems, please read the install.txt and
follow those instructions. If you still don't have any success,
please send a bug report to one of our mailing lists (see
my homepage) INCLUDING A DESCRIPTION OF YOUR SYSTEM AND
my homepage) INCLUDING A DESCRIPTION OF YOUR SYSTEM AND
YOUR PROBLEM, SUCH AS YOUR VERSION OF THE WINE SOURCES, WHAT
DISTRIBUTION YOU USE AND WHAT ERROR WAS REPORTED.
Please send problems concerning installation, feature requests,
bug reports or comments to the wxWidgets users list. Information
Please send problems concerning installation, feature requests,
bug reports or comments to the wxWidgets users list. Information
on how to subscribe is available from my homepage.
wxWidgets/Wine doesn't come with any guarantee whatsoever. It might
wxWidgets/Wine doesn't come with any guarantee whatsoever. It might
crash your harddisk or destroy your monitor. It doesn't claim to be
suitable for any special or general purpose.

8
docs/xserver.txt
View File

@@ -26,13 +26,13 @@ Copyright 1987 by Digital Equipment Corporation, Maynard, Massachusetts.
All Rights Reserved
Permission to use, copy, modify, and distribute this software and its
documentation for any purpose and without fee is hereby granted,
Permission to use, copy, modify, and distribute this software and its
documentation for any purpose and without fee is hereby granted,
provided that the above copyright notice appear in all copies and that
both that copyright notice and this permission notice appear in
both that copyright notice and this permission notice appear in
supporting documentation, and that the name of Digital not be
used in advertising or publicity pertaining to distribution of the
software without specific, written prior permission.
software without specific, written prior permission.
DIGITAL DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING
ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL