| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Add XSettings override gsettings to allow changing arbitrary XSettings
on GSettings without requiring code changes. This enables third-party
tools (like unity-gtk-module extensions) to integrate with MATE by
setting custom XSettings values at runtime.
The implementation adds an 'overrides' key to the xsettings plugin
schema which accepts a dictionary mapping XSetting names to values.
The complete list of XSettings is over at
https://www.freedesktop.org/wiki/Specifications/XSettingsRegistry/
Backported mostly from:
- https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/commit/c6e9079d
- https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/commit/35764838
Fixes: https://github.com/mate-desktop/mate-settings-daemon/issues/158
|
|
|
|
alt+super+s
|
|
Many of the plugins depend on mate_settings_plugin_get_type(), but this
symbol is only available at runtime in the mate-settings-daemon program.
With GNU libtool the -no-undefined flag gets silently ignored and the
build succeeds, but with slibtool it correctly sets -Wl,--no-undefined
in the LDFLAGS causing the build to fail.
To solve this simply removing -no-undefined is enough.
Gentoo issue: https://bugs.gentoo.org/922326
|
|
Many of the plugins depend on the libX11 and libXi linker flags, but
they are missing.
With GNU libtool the -no-undefined flag is silently ignored so the build
succeeds, but with slibtool is correctly sets -Wl,--no-undefined in the
linker flags.
Gentoo issue: https://bugs.gentoo.org/922326
|
|
|
|
The policykit-1 transitional package seems to no longer exist in Debian testing
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
