wxPython 4.2.0

Skip to first unread message

Robin Dunn

Aug 8, 2022, 6:14:38 PM8/8/22
to wxpytho...@googlegroups.com, wxpyth...@googlegroups.com, wx-u...@googlegroups.com, wx-an...@googlegroups.com, Python-Ann...@python.org

Announcing wxPython 4.2.0

PyPI: https://pypi.python.org/pypi/wxPython/4.2.0
Extras: https://extras.wxPython.org/wxPython4/extras/
Pip: ``pip install wxPython==4.2.0``

* Yes, it's been a VERY long time since the last release. I'm not
dead, just on an extended break. It took me a while to get up to
speed on a new day job, and then there was a seemingly perpetual
crunch-mode to get the product through a couple release cycles. I
can't say that things are fully back to normal yet, but at least I
now know what I'm doing. Mostly. <wink>

* This release is built using the wxWidgets' 3.2.0 release tag.

* Tweaked the build scripts a bit to ensure that on non-Windows
platforms that the compiler and flags used by default match those
used by wxWidgets, (with the flags needed by Python added on.) The
compiler commands can be overridden by setting CC and CXX in the
environment if needed. (#1247)

* On Windows the build code that locates and sets up the environment
for the MSVC compiler no longer relies on distutils code, but is now
using more modern code in setuptools instead. This enables much more
compiler flexibility and wxPython should now be buildable with
Visual Studio versions from 2015 through 2022+.

* Switched to SIP 6 for generating the wrapper code. Rather than a
standalone executable, SIP is now a Python package that needs to be
installed in the Python environment used for the build. A dependency
has been added to requirements/devel.txt to help ensure that the
correct version is installed. The wx.siplib module code is no
longer kept in the repository, but is generated during the build.

* Changed wx.App.InitLocale to just do
`locale.setlocale(locale.LC_ALL, "C")` to undo what Python (3.8+ on
Windows) does. This lets wxWidgets start with an uninitialized
locale as it expects. (#1637)

* Fixed issues related to `time_t` always being treated as a 32-bit
value on Windows. (#1910)

* Added wx.FullScreenEvent and wx.EVT_FULLSCREEN.

* The legacy, OSX-Only wx.webkit module has been removed.

* Fix building wxPython with Python 3.10 on Windows (#2016)

* Fix PyProgress on Windows by avoiding invalid sizer flags (#1985)

* Fix 'More Grid Features' in demo

* Many of the widgets which deal with bitmaps have been changed to use
a wx.BitmapBundle object instead of wx.Bitmap. This is the mechanism
which wxWidgets has implemented for adapting to things like Hi-DPI
displays. Essentially you can load a list of bitmaps of different
sizes (but similar or scaled content) into a wx.BitmapBundle, and
the widget can choose one based on the display density. Existing
code should be able to continue to pass a wx.Bitmap to the widget
constructor or to methods like SetBitmap, as wxPython will
automatically convert from a wx.Bitmap to a wx.BitmapBundle
containing the single image provided.

* Add support for new wx.grid event, EVT_GRID_ROW_MOVE

* Fix path issues in wx.lib.agw.multidirdialog (#2120)

* Fix eventwatcher checkAll(check=False) (#2139)

* Fix exception on grid labels click in 4.1.1a (#1841)

* Fix a large number of Python 3.10 issues. In Python 3.10, a change
was implemented where extension functions that take integer
arguments will no longer silently accept non-integer arguments
(e.g., floats) that can only be converted to integers with a loss of
precision. Fixed most of these issues in the pure-Python classes
and demos by explicitly converting the parameters to int before
passing them to wxWidgets. There is loss of precision, but this was
happening before (automatically) anyway as most wxWidgets
DeviceContext functions operate using integers.

* Fix PlotCanvas point label drawing on Linux

* Fix GetPopupMenu override for wx.adv.TaskbarIcon (#2067)

* Fix invisible text in lib.plot with dark theme

* Add new button type: ShowHideToggleButton. Like a ToggleButton, but
with an associated "menu", a Window or Sizer which is shown/hidden
when button is toggled. Includes methods for setting active and
inactive fore/background colours.

* Fix unbinding of events in FIFO order (#2027)

* Enable customization of layout of pdfviewer button panel

* Support newer PyMuPDF versions (#2205)

* IntCtrl: Change default colour to wx.NullColour so the default
color will be used. (#2215)

* Change PopupControl to respect all the parameters passed to its
init method (#2218)

* Fixes in flatmenu.py Remove and DestroyItem (#2219)

* Using the MinGW toolchain to build wxPython has been simplified
a bit. (#2211)

What is wxPython?

wxPython is a cross-platform GUI toolkit for the Python programming
language. It allows Python programmers to create programs with a
robust, highly functional graphical user interface, simply and
easily. It is implemented as a set of Python extension modules that
wrap the GUI components of the popular wxWidgets cross platform
library, which is written in C++. Supported platforms are Microsoft
Windows, Mac OS X and macOS, and Linux or other unix-like systems with
GTK2 or GTK3 libraries. In most cases the native widgets are used on
each platform to provide a 100% native look and feel for the

What is wxPython Phoenix?

wxPython's Project Phoenix is a new from-the-ground-up implementation
of wxPython, created with the intent of making wxPython “better,
stronger, faster than he was before.” In other words, this new
implementation is focused on improving speed, maintainability and
extensibility of wxPython, as well as removing most of the cruft that
had accumulated over the long life of Classic wxPython.

The project has been in development off and on, mostly behind the
scenes, for many years. For the past few years automated snapshot
builds have been available for those adventurous enough to try it, and
many people eventually started using the snapshots in their projects,
even for production releases. While there are still some things on
the periphery that need to be completed, the core of the new wxPython
extension modules which wrap the wxWidgets code has been stable for a
long time now.

Due to some things being cleaned up, reorganized, simplified and
dehackified wxPython Phoenix is not completely backwards compatible
with wxPython Classic. This is intended. In general, however, the API
differences tend to be minor and some applications can use Phoenix
with slight, or even with no modifications. In some other cases the
correct way to do things was also available in Classic and it's only
the wrong way that has been removed from Phoenix. For more
information there is a Migration Guide document available at:

The new wxPython API reference documentation, including all
Python-specific additions and customizations, and docs for the wx.lib
package, is located at: https://docs.wxpython.org/

Reply all
Reply to author
0 new messages