For Upstream wxWidgets
For notes on issues that we may pass back upstream to wxWidgets.
add Trac tracking link for any that have been reported upstream
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 8c9c17ca704f6c2b1469c861497ac7676dd67347)
- This fixes a bug described here: http://bugzilla.audacityteam.org/show_bug.cgi?id=1338
- 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 606403fd33686523cfd9808905b92b9f2eb7b95d "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 9cb30c46bd1c2535ddcf0f45b9a7e1c405c8de08)
- This is a cherry-pick of commit ea47af08cb3715d89e50ab48ec3ccb167b28c43b 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 31449d21d5196327926672b698a6923a8f981f03)
- 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 e2c636d0a88f538d9e1f1ccae9c9f9f883d59360)
- 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 343528d045e805b84e2c4df2bacdf4d319906084)
- 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 85106af5ce61eef45d2f416908a4ff7b64728124)
- 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.
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
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.