For Upstream wxWidgets
For notes on issues that we may pass back upstream to wxWidgets.
- 1 Overview
- 2 Confirmed Issues
- 3 From wx3.0.2 to wx3.1.1
- 4 Mac: Patches to wxWidgets 3.0.2 source
- 5 Windows: Patches to wxWidgets 3.0.2 source
- 6 Linux: Patches to wxWidgets 3.0.2 source
- 7 Workarounded
- 8 Notes and Scribbles
- 9 Older
We apply patches to our copy of wxWidgets, in addition to building with ACCESSIBILITY on. We apply the same patches whether building on Mac, Windows or Linux.
- Linux currently needs none of these patches, so it is OK if Debian for example builds with stock wxWidgets (of the version we use, and with accessibility enabled).
- Windows currently requires a patch for file renaming, because of virus checkers that can prevent it and so mandate retries.
- Mac needs patches for accessibility features.
add Trac tracking link for any that have been reported upstream
From wx3.0.2 to wx3.1.1
Status of patches for 3.1.1
|???||change a bool return to void|
|Win||Retry file renaming on Windows only.||this is just a detail of [Windows: Retry failed rename patch applied.]|
|Mac||Make EVT_MAGNIFY Mac only||Was a backport.|
|Mac||Make NeedsFocusRing() Mac only|
|All||Windows: Create setup.h from setup0.h||ACCESSIBILITY is 1 by default in windows in 3.1.1|
|Mac||Fix compilation of event loop on Windows.||i.e. make the change Mac specific.|
|Win||Windows: Accessibility/Setup patch applied.||ACCESSIBILITY is 1 by default in windows in 3.1.1|
|Win||Windows: Retry failed rename patch applied.||Believe we can do this in our own code using std::rename which does produce an informative error code, not just true/false.|
|Win||Windows: Processed=true accessibility patch applied.||Already present in 3.1.1|
|Win||Windows: Prevent wxWidgets from setting HighDPI awareness mode patch||Believe the patch is not needed, as per Trac 16116 we can set no HiDPI in the manifest.|
|Mac||Correctly track the full-screen state on OSX 10.7 and later|
|Mac||Implement parts of NSObject(NSAccessibility) informal protocol|
|Mac||Quitting app via Mac tooldock uses events, so behavior is overridable|
|Mac||Focus rings are back for buttons, choice, listbox, dateTimePicker con|
|Mac||Add wxEVT_MAGNIFY mouse event.||was a backport.|
|Mac||Mac modal loops won't hang when other code uses old Mutiprocessing...|
Mac: Patches to wxWidgets 3.0.2 source
wxWidgets 3.0.2 in Audacity 2.1.3 for Macintosh is built from a source tree containing modifications, available here: https://github.com/audacity/wxWidgets/tree/audacity-fixes
Each of the commits unique to that branch corresponds to a .patch file in the Audacity source tree, in the folder mac/wxMac_additions. The file mac/Build.txt instructs the developer how to apply these patches before building wxWidgets 3.0.2 from source.
There is also one older patch file mentioned in mac/Build.txt. It is named mac/wxMac_additions/wxMac-3.0.2-fixes.patch and it dates from Audacity 2.1.2 development. It is not included in the audacity-fixes branch.
See /mac/wxMac_additions/eventloops.patch (commit 8c9c17ca)
- This fixes a bug described here: Bug1338
- Some audio plug-ins, such as Voxengo SPAN mentioned in the bug report, use the old MultiProcessing API in macOS (functions named with MP prefix). When these displayed a non-modal window, and then Audacity displays a modal dialog, then the application became unresponsive to clicks.
- This could be fixed by reverting the commit 606403fd"backport merging in Václav's fix for getting CPU usage down in ShowModal". But that would have the undesirable effect of making all modal dialogs busy-wait.
- A new function is added to change a global variable, so that the application can opt for the older busy-waiting behavior only as needed. Audacity 2.1.3 will do so only while any plug-in effect is displaying its own graphical interface.
See /mac/wxMac_additions/pinch-spread.patch (commit 9cb30c46)
- This is a cherry-pick of commit ea47af08 from version 3.1.0, with some conflict resolution, backporting support for the pinch and spread gestures on the Mac touchpad.
See /mac/wxMac_additions/focusrings.patch (commit 31449d21)
- In Audacity 2.1.2, certain classes of controls (buttons, choices, listboxes, date-time pickers) do not display focus rings when TAB key navigation reaches them, as they do in version 2.1.1. This is a consequence of migration from wxWidgets 2.8.12 to 3.0.2.
- This patch restores focus rings.
See /mac/wxMac_additions/wxMac-3.0.2-wxaccessible.patch (commit e2c636d0)
- wxWidgets defines its own wxAccessible protocol for applications, but implements it only on Windows.
- This patch partially implements a bridge from the wxAccessibility class to the NSObject(NSAccessibility) protocol in Cocoa. This makes Audacity 2.1.3 interoperate with VoiceOver, the talking desktop on Macintosh, which is enabled or disabled with Command+F5, and then uses key combinations involving control+alt to navigate controls mouse-free.
- This implementation is not complete in all respects but is sufficient to navigate among Audacity's pushbuttons and click them with control+alt+spacebar.
- The NSObject(NSAccessibility) protocol is now considered deprecated and is superseded by another application programming interface in the most recent versions of macOS. Audacity 2.1.3 still targets macOS version 10.6 as its minimum requirement, and is likely to move only to 10.7 in near future versions. There is not yet any intention to retarget this wxAccessible implementation to the newer interface.
See /mac/wxMac_additions/tooldock-quit.patch (commit 343528d0)
- wxWidgets defines wxEVT_END_SESSION and wxEVT_QUERY_END_SESSION events, and binds them to wxApp::OnEndSession() and wxApp::OnQueryEndSession(). These are not overridable virtual functions, but the application can get the effect of overriding them in its subclass of wxApp by defining its own event handling table. Audacity does so, and its handlers are visited when quitting the application using the main toolbar menu.
- However wxWidgets bypassed the event handling mechanism, calling the wxApp member functions directly, in case of quitting the application from the context menu of the application icon in the tool dock. This had undesirable effects in Audacity.
- This patch causes the tool dock menu item to use event dispatching, just as the toolbar does, so that Audacity's own functions can intercept the message.
See /mac/wxMac_additions/fullscreen.patch (commit 85106af)
- wxTopLevelWindow::ShowFullScreen is implemented with toggleFullScreen:, if available (macOS 10.7 or later). The method is documented here: https://developer.apple.com/reference/appkit/nswindow
- Also when toggleFullScreen: is available, then wxTopLevelWindow::IsFullScreen is implemented by receiving the windowDidEnterFullScreen: and windowDidExitFullScreen: notifications to record the correct fullscreen state.
- This change makes IsFullScreen() give correct answers, not only after calls to ShowFullScreen (which cause the notifications), but also after clicks on the green circle in the window title bar, and ShowFullScreen will also now work correctly after clicks on that circle.
Windows: Patches to wxWidgets 3.0.2 source
windows disable HiDPI
TRAC 16116 - We need to disable HiDPI because of how we use images currently. [ ] - Accessibility patches.
Linux: Patches to wxWidgets 3.0.2 source
these need better write up, if we are to pass them upstream!
- wxGridCellChoiceEditor's virtual function StartingKey() either isn't called or doesn't do anything (multiple inheritance and virtual function issue?), leading to loss of first character, whence Bug 1389 workaround
- wxSplashScreen (used during initialisation) appears to prevent use of any modal dialog, whence Bug 1377 workaround
- Blt from a ScreenDC into a wxBitmap now uses transparency, although ScreenDC does not provide transparency, leading to incorrect images. Has wxWidgets changed to wxBitmap having transparency by default? Creating the Bitmap explicitly 24 bit solves that, which is Bug 1378 workaround. (transparency may be intended behaviour, but it is breaking behaviour too!). Problem with transparency from wxScreenDC might be video card dependent, based on this discussion.
- On Mac, the mouse button state reported by a Leaving mouse event is unreliable. It always reports no buttons down. Workaround: rely on ::wxGetMouseState() to poll button states instead. See discussion here
- On Mac colouring of a wxStaticText is lost after a Disable and Enable pair. This we worked around for bug 1701
- On Windows, when menus are long enough to cause scrollers, the scrollers generate a spurious help string update in the status bar using an ID of 0. This we worked around for bug 143. The bug is in wxFrameBase::ShowMenuHelp(int menuId). It shouldn't do anything for an ID of 0 (or the 0 should never be sent to it in this case).
Notes and Scribbles
- wxFileConfig very slow (on non SSD volume)? Or is it some other problem?
- We should probably review all wx3 bugs in Bugzilla and add notes in the workaround section. Bug 1147 has some important patches from Debian to address changes with wx3.
- The ASSERTs on by default are catching behaviour that 'worked' previously.
WxWishlist has some old requests for improved functionality.