The 'wrapper' accessibility handler is now ignored if a menu item has a
custom component, and has no submenu, and cannot be triggered
automatically. This avoids the case where a custom menu item may end up
with a wrapper accessibility handler that has no useful actions.
This patch also adds a 'label' argument to the addCustomItem functions,
which allows text for the screen reader to be supplied in the case where
a custom component is in use, but the menu item has accessibility
actions.
Effects of this change for windows with native titlebars:
- Resizable windows without maximise buttons will now only allow the
'zoom' behaviour from the rightmost titlebar button (i.e. this button
will not allow entering full-screen mode)
- Non-resizable windows will grey-out the rightmost titlebar button,
whether or not the maximise button is enabled
The Apple threading documentation [^1] says the following:
> The second argument to pthread_setschedparam is the desired policy,
which can currently be one of SCHED_FIFO (first in, first out),
SCHED_RR (round-robin), or SCHED_OTHER. The SCHED_OTHER policy is
generally used for extra policies that are specific to a given
operating system, and should thus be avoided when writing portable
code.
This appears to differ from the policy semantics on Linux and BSD, where
FIFO and RR are both explicitly real-time policies.
Therefore, on Linux/BSD we only enable the RR policy if the requested
priority is 8 or higher. Meanwhile, on macOS, we map all thread
priorities (0 - 10) onto the RR policy with an appropriate priority.
[^1]: https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/KernelProgramming/scheduler/scheduler.html
The Apple threading documentation [^1] says the following:
> The second argument to pthread_setschedparam is the desired policy,
which can currently be one of SCHED_FIFO (first in, first out),
SCHED_RR (round-robin), or SCHED_OTHER. The SCHED_OTHER policy is
generally used for extra policies that are specific to a given
operating system, and should thus be avoided when writing portable
code.
This appears to differ from the policy semantics on Linux and BSD, where
FIFO and RR are both explicitly real-time policies.
Therefore, on Linux/BSD we only enable the RR policy if the requested
priority is 8 or higher. Meanwhile, on macOS, we map all thread
priorities (0 - 10) onto the RR policy with an appropriate priority.
[^1]: https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/KernelProgramming/scheduler/scheduler.html
