Apple clang now enables the warning suppressed by this macro by default,
so it becomes important to suppress it for this compiler as well and not
just gcc.
Rename the macro to remove "GCC" prefix which doesn't make sense any
more now that this macro is not only for gcc.
This avoids warnings in the test suite when building in macOS 15 GitHub
Actions image using newer Apple clang.
These functions must take "activity" parameter as "unsigned long" and
not "int" to make their type compatible with CFRunLoopObserverCallBack
which uses CFRunLoopActivity that is defined as "unsigned long".
This fixes warnings with Apple clang 17, used in GitHub Actions macOS 15
images, which apparently enables -Wcast-function-type-mismatch by
default. And it's the right thing to do, anyhow.
Implement native pre-edit handling for wxGTK and Cocoa using Scintilla's
tentative input support.
Use a private text input client bridge to complete Cocoa
NSTextInputClient and support GTK pre-edit callbacks without changing
the public API or existing class ABI.
Inline composition is now the default on GTK and Cocoa, existing code
may call SetIMEInteraction(wxSTC_IME_WINDOWED) to retain the previous
behaviour.
While composition is active under wxGTK, the IM context is given first
access to key events, as keys such as Enter and Backspace confirm or
edit the pre-edit text and must not be handled as normal key events.
Rolling the pre-edit text back relies on tentative undo actions being
recorded, so windowed interaction is used while undo collection is
disabled.
Document platform defaults and add regression tests for composition,
UTF-16 ranges, replacement ranges, virtual space, undo, and mode
switching.
Closes#26228.
Closes#26757.
In dark mode we redrew all the items when setting the column width to
"automatic" size which made it very slow compared to light mode.
Just don't do it in this case, as it's completely unnecessary.
This brings the time for autosizing 10 columns with 500 items down from
~9s to ~250ms which is almost the same as in light mode.
Closes#24011.
When wxDEPRECATED_MSG() uses __declspec(deprecated) internally, and not
the standard [[deprecated]] attribute as it does for newer MSVC
versions, the compiler warns about any mention of the deprecated class
even if it's not being really used, so suppress the unwanted warnings
about it.
They do what they say for all supported compilers, i.e. currently MSVC,
gcc and clang, and using these macros is simpler and shorter than using
compiler-specific macros for each compiler.
Define similar macros for MSVC as we already had for gcc and clang for
consistency and because they are arguably less ugly than directly using
pragmas in the code.
Use them instead of manually disabling warnings.
No real changes.
The recent 07590bec33 (Use preceding label as accessibility title of
controls under macOS, 2026-09-21) started calling GetLabel() from
MacPostControlCreate() which is called before the object was fully
constructed and could (and did) result in crashes due to the use of the
not yet initialized members.
Avoid this by adding a new HasAccessibilityTitle() virtual function of
wxWidgetImpl which is fully constructed by the time this function is
used and also addresses the question of whether the preceding label
should be used as this window accessibility title more precisely.
See #27060, #27140.
Closes#27142.
Only wxMSW uses a native control, recognized by screen readers, but
wxGenericListCtrl was not recognized by them at all.
Extend the private accessibility API added in the previous commit to
support table-like controls too and use in wxGenericListCtrl to let
screen readers know about its contents.
Assisted-by: Claude Opus 5.5
Co-authored-by: Quin Gillespie <trypsynth@gmail.com>
Only wxMSW uses the native wxStatusBar which is recognized by screen
readers, while wxGTK and wxOSX use the generic version which is just a
window and so was not recognized by them as being what it is at all.
Add generic (but private for now) SetAccessibleElements() function
implemented for both of them and use it from wxStatusBarGeneric to let
Orca/VoiceOver know about the status bar fields and, in wxGTK, about its
role.
Assisted-by: Claude Opus 5.5
Co-authored-by: Quin Gillespie <trypsynth@gmail.com>
wxAuiFloatingFrame could receive wxEVT_SIZE during its destruction, even
if it was already hidden, and handling these events crashed due to
dereferencing dangling wxSizerItem pointers.
Fix this by overriding wxAuiFloatingFrame::Destroy() to perform the
necessary cleanup when the frame is about to be destroyed.
Add wxAuiManager::DestroyFloatingFrame() helper which makes the code say
more clearly what it does -- this is not required to fix the bug but
affects the same code, so do it in the same commit.
Also add a unit test confirming that destroying the floating frame in
various ways doesn't crash any longer.
Closes#26264.
Originally-by: alilie <alexandru.ilie@hexagon.com>
wxAuiNotebook's wxAuiManager is only an implementation detail used for
its tab frames, plus the hidden dummy pane created during initialization.
Reject attempts to add arbitrary windows to it instead of making notebook
code tolerate such panes.
Update the AUI test to cover the narrower contract by checking that an
external non-tab pane is rejected and not registered with the manager.
Fixes#4771.
Closes#26902.
Refactor pasteboard code for reuse in dnd.
Improve setting flags for file objects.
See #27047.
Closes#27117.
Co-authored-by: Stefan Csomor <csomor@advancedconcepts.ch>
Extract code duplicated in wxWidgetCocoaImpl::SetAccessibilityLabel()
and SetAccessibilityTitleElement() into a new function.
No real changes.
See #27056, #27060.
Under MSW, screen readers use the label preceding a control without its
own label, such as wxChoice or wxTextCtrl, as its name, so dialogs are
accessible without doing anything special. Under macOS this didn't
happen, and VoiceOver only read the labels as separate texts, so users
tabbing through a dialog didn't hear what the controls were for.
Now, when a native control without its own label is created right after
a wxStaticText, the label is set as its accessibility title element,
which VoiceOver reads as the name of the control. Notice that for most
controls the accessibility element is the cell and not the view itself,
so this uses NSAccessibilityUnignoredDescendant() to link the elements
actually used by VoiceOver, and uses the document view for the controls
inside a scroll view.
Closes#27060.
The new function allows to set the name used by screen readers for any
window, e.g. for buttons showing only a bitmap or text controls without
a label before them.
Implement it for wxMSW and wxOSX and add documentation and a MSW-only
unit test.
Closes#27056.
Handle double-clicks on wxAuiFloatingFrame by docking the pane back to
its saved dock position when the pane is still dockable. On MSW, handle
the native caption double-click message so the outer title bar redocks
instead of falling through to frame default handling.
Add coverage for the MSW non-client title-bar path and the resulting
manager state transition.
Fixes#10004.
Closes#27083.
Using wxBitmapBundle means SVG files can now be used, multi-resolution
bitmap bundles can be used, scaling for high DPI now uses scaling code
for bitmap bundles which generally provides better scaling results.
Also add support for loading SVG images from wxInputStream and use to
implement support for compressed .svgz files.
Closes#26474.
Gallery items have just a bitmap, an ID and the application's client
data, so there is nothing a screen reader can announce for them and they
are read as "list item 3 of 39", which is useless.
Add Append(bitmap, id, label) and Set/GetItemLabel() and use the label
as the accessible name of the item. The label is not drawn, as the items
of a gallery are bitmaps by design, it only exists to be announced. It
could also be used for tooltips later, which the items don't have
either.
The ribbon sample already knows the names of the colours it puts in its
galleries, so it passes them as the labels now, which also makes them a
useful test case.
Closes#27100.
The search menu could only be opened by clicking the button showing it,
which doesn't accept focus from the keyboard on purpose, so keyboard and
screen reader users couldn't use it at all.
Handle Alt-Down in the text part of the control and show the menu from
there, as suggested in the comments of the original ticket.
Fixes#18457.
Closes#27093.
Use the new API, i.e. call ClaimsKeyBeforeAccelerator() and send
wxEVT_ACCELERATOR_KEY, in wxQt too.
Update wxComboBox to override ClaimsKeyBeforeAccelerator() too.
Note that wxTextCtrl and wxSpinCtrl don't need to be modified because
they already do this in the base class.
This actually simplifies the existing code as we don't need
wxWindow::m_processingShortcut any more.
Use the new API, i.e. call ClaimsKeyBeforeAccelerator() and send
wxEVT_ACCELERATOR_KEY, in wxOSX too, whenever possible, i.e. not for
Cmd-Letter used by the menu items as we never get key events for them at
all.
This probably could be worked around by overriding performKeyEquivalent:
but for now leave it like this because hopefully there should be no
conflict between menu accelerators and standard text editing keys as
Cmd+C etc act on the focused window anyhow by default, so the behaviour
should be already correct anyhow.
When deciding whether a key press should trigger an accelerator or be
handled by the currently focused window different ports behaved
differently, with wxGTK always prioritizing the focused window and the
other ports giving priority to the accelerator, and neither of them
allowed customizing this.
Change this now by introducing 2 ways to do it: first, a window can
override new ClaimsKeyBeforeAccelerator() virtual function to specify
which keys it wants to handle itself, even if they correspond to an
accelerator. And second, send wxEVT_ACCELERATOR_KEY event which can be
handled by the application, typically centrally in its wxFrame-derived
class, to decide if it wants some accelerator that it defines to not
steal the key from the window or, on the contrary, to always do it, even
if the window overrides ClaimsKeyBeforeAccelerator() as wxTextCtrl does.
Note that while ClaimsKeyBeforeAccelerator() replaces some uses of
wxMSW-specific MSWShouldPreProcessMessage(), but it's still needed to
prevent the key getting eaten by IsDialogMessage().
This is not a backwards-compatible change as it changes the default
wxGTK behaviour, but it is now compatible with the other ports and can
be easily customized if necessary.
This commit only implements this for wxMSW and wxGTK, other ports will
be updated too soon.
The list of the keys which are used for editing the text and which
shouldn't be taken by the accelerators using the same keys existed only
in wxMSW and only as a function taking a MSG, move it to the common code
as wxTextEntryBase::IsUsedForEditing() taking wxKeyEvent, as it is going
to be needed by the other ports too in the upcoming commits.
Note that this also slightly changes wxMSW behaviour because the keys
producing printable characters, as well as Backspace, are now considered
as being used for editing too and so are not passed to the accelerators
any longer, which seems more correct as typing text in a control
shouldn't trigger the accelerators using the same keys.
It was previously available only in the generic version which was used
by wxGTK and wxUniv, add it to the other ports too as it's going to be
needed in the upcoming commit.
In wxMSW this required storing the accelerators, as it is simpler than
converting them back from the native HACCEL and more consistent with the
other ports that already did this.
Add the new function checking if a (key) event and wxAcceleratorEntry
correspond to the same key combination.
This was already used in the generic wxAccelerator implementation and
wxOSX and will be used in the other ports too soon, so move this code
into common function.
It can also be useful for the applications, so document it as well.
In wxMSW, single line read-only wxTextCtrl doesn't accept focus from
keyboard, so keyboard and screen reader users can't Tab to it and read
its contents.
Add wxWindow::EnableFocusFromKeyboard(), the counterpart of the existing
DisableFocusFromKeyboard(), to let the application allow this.
Update the documentation and add a wxMSW-only unit test.
Fixes#10760.
Closes#27054.
MSW cross-builds / wxMSW 64 bits not compatible (push) Canceled after 0s
MSW cross-builds / wxMSW/Univ (push) Canceled after 0s
MSW cross-builds / wxMSW 32 bits (push) Canceled after 0s
Code Checks / Check Spelling (push) Canceled after 0s
Code Checks / Check Whitespace (push) Canceled after 0s
Code Checks / Check Mixed EOL (push) Canceled after 0s
Code Checks / Check C++ Style (push) Canceled after 0s
Code Checks / Check All Headers In allheaders.h (push) Canceled after 0s
The generic collapsible header, used by wxCollapsiblePane and so by the
generic about dialog, had two problems for keyboard and screen reader
users under MSW:
- Pressing Enter on the header activated the default button of the
dialog. In wxAboutBox this closed the dialog. Enter now toggles the
header, the same as Space.
- Screen readers could not tell what the header was or if it was open.
It now reports itself as a button with an expanded or collapsed state,
sends a state change event when it toggles, and has a default action.
This also stops screen readers from reading the label twice.
Closes#27048.
When the generic wxInfoBar showed a message, screen readers said
nothing, so their users did not know it had appeared.
The info bar now has the alert accessible role with the message as its
name, and sends an alert event every time ShowMessage() is called. NVDA
reads the message when it is shown, and also when a new message is shown
while the bar is already visible.
Closes#27053.
The generic wxInfoBar was a plain wxControl, not a container, so Tab
gave focus to the info bar window itself and never moved to the close
button or other buttons inside it.
wxInfoBarGeneric now derives from wxNavigationEnabled, the same as
wxGenericCollapsiblePane, so Tab moves to the buttons inside it.
Closes#27052.
Buttons that show only a bitmap have no label, so screen readers only
announce them as "button". This affects, for example, the buttons of
wxEditableListBox and the close button of the generic wxInfoBar.
When a button has no label but has a tooltip, its tooltip is now used as
its accessible name. Buttons with a label are not changed.
Closes#27051.
Vadim Zeitlin
Ryan Lucia
Richard
Maarten Bent
Alexey ShelaevandStefan Csomor
Randalphwa
Blake-Madden
Avery King
Steve Cornett