Age | Commit message (Collapse) | Author | Files | Lines |
|
Fix fairly large memory leak when beeping on keys while caps lock is
enabled. The libatspi2 docs and API were quite misleading, so I
overlooked the fact the event parameter should be freed in the
callback.
This changes the constness of the callback argument, which is new in
libatspi2 2.40 -- yet the actual behavior didn't change, only the
qualifier was removed, see [1].
This might however bring up a compiler warning when building against
libatspi2 < 2.40; but on the other hand it fixed build with
clang >= 16, see #399. As it is unlikely to build with clang >= 16
and libatspi2 < 2.40, I think it's a good compromise.
[1] https://gitlab.gnome.org/GNOME/at-spi2-core/-/commit/7dfb0b7fc2d1710ef7fad54f910fa4c6a5e3af17
|
|
|
|
|
|
|
|
There is often a need for the user to increase the audio playback volume above
the volume level known as "100% volume". While increasing the audio volume
above 100% can result in degraded audio quality, sometimes the audio was, for
example, originally recorded at an extremely low volume, and the user has no
other option to clearly hear the audio. Unfortunately, most MATE applications
with volume controls do not allow the user to set the volume level above 100%.
For example, the main MATE Sound Preferences dialog lets you set the audio
volume beyond 100% (when possible), whereas the Volume Control Applet, Volume
Control status icon, and special "multimedia" volume control keys do not. In
fact, if the user even tries to change the volume using any of the latter
methods, and the current volume level is above 100%, these latter methods will
all reduce the volume to 100%, even if the user tried to increase the volume!
This is part 3 of a patch to change this situation. This patch adds this
capability to the handlers for the "multimedia" volume control keys -- if the
appropriate setting is enabled in the MATE Volume Control Dialog (see
patch 2), then the user can increase the audio volume beyond 100% by pressing
the "Volume Up" key on their keyboard (if they have such a key). While this
patch is smaller than patch 2, it is equally important since the original
feature request was for the multimedia keys and not for anything else in
particular.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
These settings seem to produce better results in various scenarios.
Link to discussion:
https://github.com/mate-desktop/mate-settings-daemon/pull/368
|
|
This makes it match Xft/DPI in XSETTINGS. Applications relying on Xft.dpi
on HiDPI screens will now work correctly.
Behavior is now consistent with GNOME, relevant commits from gsd:
https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/commit/047f030235972fdab5e15aff484006caf914216a
https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/commit/25c7cc703118c69b224acf9c4f7af09a31f50a34
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Delay registration of the a11y keyboard plugin to run after the
non-a11y keyboard one to avoid numlock state change conflicts.
|
|
|
|
This allows a customizable and possibly different beep sequence when a
togglekey is enabled or disabled. This is very useful for the user to
know for sure whether the feature got enabled or disabled.
Back in the days of buzzers, XKB was supposed to use different sounds
for each of those, but this is no longer the case now in the vast
majority of setups the beeps are intercepted and use a single recorded
sound.
XKB beeps are also unfortunately not configurable, although they
possibly should be on paper: in theory, one could alter the bell used
by listening to `XkbBellNotify` events, which provides a way to
discriminate bells through a name. Unfortunately XKB's togglekeys
seems to suffer from a bug (?) for a long time, in that it will always
ring the `AX_IndicatorOn` bell if there is *at least one* indicator on
at the moment the bell is rung, and `AX_IndicatorOff` if and only if
*all* indicators are off. This makes it virtually useless as it is not
possible to discriminate between an indicator getting turned on or off
in most cases, especially with NumLock which often stays always on.
Given this behavior dates at the very least as far back as X.org 1.16
which is from 2014, it probably is not very realistic to rely on a fix.
So instead implement togglekeys on our end by listening to the
`XkbIndicatorStateNotify` events.
|
|
|
|
|
|
Instead guard the caller to only use it if available.
|
|
|
|
Try and avoid the workaround for buggy libatspi2 if we can know the
version we're using has it fixed.
|
|
Ringing when a locking modifier gets enabled/disabled is already taken
care of by the `togglekeys` settings, so don't provide redundant
functionality and allow better settings granularity.
|
|
|