
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 application. 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: https://docs.wxpython.org/MigrationGuide.html 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/
participants (1)
-
Robin Dunn