Branch: refs/heads/master
Home:
https://github.com/wxWidgets/wxWidgets
Commit: 58f81715694a6d1e31b3a657d7368b4097b06785
https://github.com/wxWidgets/wxWidgets/commit/58f81715694a6d1e31b3a657d7368b4097b06785
Author: Robert Roebling <
robert....@gmail.com>
Date: 2026-01-02 (Fri, 02 Jan 2026)
Changed paths:
M src/osx/cocoa/
renderer.mm
Log Message:
-----------
Improve colour for selection background in dark mode in wxOSX
Use the appropriate constants when available and provide fall back for
older versions.
Closes #26035.
Commit: c8880e21b166efc0971bf2d6d770c2c17840807e
https://github.com/wxWidgets/wxWidgets/commit/c8880e21b166efc0971bf2d6d770c2c17840807e
Author: Daniel Collins <
solemn...@solemnwarning.net>
Date: 2026-01-02 (Fri, 02 Jan 2026)
Changed paths:
M include/wx/osx/toolbar.h
M src/osx/cocoa/
toolbar.mm
Log Message:
-----------
Avoid duplicate toolbar item IDs on macOS
We use the wxToolBarTool address as the native toolbar item ID, which
must be unique within the application (at least), not just within the
toolbar, and triggers an assertion failure if a wxToolbar is destroyed
and re-created with item(s) happening to land at the same memory
addresses before the underlying NSToolbar is destroyed.
This commit changes the ID to include the NSToolbar address so that an
ID won't be reused unless an NSToolbar has been fully destroyed and a
new one created at the same address.
This may also hint at an (existing) bug since the NSToolbar object
clearly exists for longer than the wxToolBarTool, and Cocoa _MIGHT_
ask us for the item after it has been deleted, but I'm not familiar
enough with macOS to know whether or not this can happen.
Closes #26057.
Commit: aaa151f5c72fc27a84b17c0763af84fdbaef634c
https://github.com/wxWidgets/wxWidgets/commit/aaa151f5c72fc27a84b17c0763af84fdbaef634c
Author: Glen Gordon <
18452241+g...@users.noreply.github.com>
Date: 2026-01-02 (Fri, 02 Jan 2026)
Changed paths:
M src/common/wincmn.cpp
Log Message:
-----------
Return wxACC_NOT_IMPLEMENTED from wxWindowAccessible::GetParent()
If a widget has a custom accessibility implementation derived from
wxWindowAccessible, there's no guarantee that the parent overrides the
nullptr-returning base CreateAccessible.
Returning wxACC_NOT_IMPLEMENTED follows the pattern of other
accessibility methods to defer to the platform's default implementation,
and fixes wx wxWindowAccessible::GetParent() when called on custom
accessibility implementations like wxCheckListBoxAccessible.
Closes #26063.
Commit: 2ab82b5a2082d9c83ba5ff80e669c3f1cc3cb607
https://github.com/wxWidgets/wxWidgets/commit/2ab82b5a2082d9c83ba5ff80e669c3f1cc3cb607
Author: Vadim Zeitlin <
va...@wxwidgets.org>
Date: 2026-01-02 (Fri, 02 Jan 2026)
Changed paths:
M src/msw/listctrl.cpp
Log Message:
-----------
Don't use first image for wxListCtrl items without any image
Native wxListCtrl in wxMSW behaved inconsistently with the generic one
and used the first image for the new items inserted into it even if no
image was explicitly specified.
Work around this unhelpful native behaviour by using I_IMAGENONE for the
items without images.
Closes #26062.
Compare:
https://github.com/wxWidgets/wxWidgets/compare/0a6523c4d9e5...2ab82b5a2082
To unsubscribe from these emails, change your notification settings at
https://github.com/wxWidgets/wxWidgets/settings/notifications