summaryrefslogtreecommitdiff
path: root/plugins
AgeCommit message (Collapse)AuthorFilesLines
2022-08-08Add setting for adjustment of audio volume above 100 per cent: Part 3Gordon Norman Squash1-1/+14
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.
2022-03-14Fix implicit conversion changes signedness: 'gboolean' to 'guint'rbuj2-2/+2
2022-03-10datetime: declaration shadows a variable in the global scoperbuj1-5/+1
2022-03-10Fix build warnings about missing field initializerrbuj1-1/+2
2022-03-10Cppcheck: function parameter can be declared with constrbuj5-10/+10
2022-03-10Use GLib's new g_clear_signal_handler() function to simplify coderbuj1-0/+6
2022-03-10housekeeping: disconnect manager's changed settings signal on finalizerbuj1-13/+24
2022-01-23xrdb: wrong type field in printf format stringrbuj1-3/+3
2021-11-28datetime: fix memory leakrbuj1-2/+4
2021-11-24Use a blank line at mostrbuj30-50/+0
2021-09-18xrandr: fix typo reported by translatorsraveit651-1/+1
2021-06-23update copyright to 2021raveit65129-0/+129
2021-04-26xsettings: Improve Qt HiDPI environment settingsOleksandr Chekhovskyi1-4/+7
These settings seem to produce better results in various scenarios. Link to discussion: https://github.com/mate-desktop/mate-settings-daemon/pull/368
2021-04-26xsettings: Set Xft.dpi in X resources to scaled_dpiOleksandr Chekhovskyi1-2/+2
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
2021-04-02rfkill: g_memdup is dreprecated from glib 2.68rbuj1-0/+8
2021-02-23media-keys: memory leakrbuj1-1/+1
2021-02-23keyboard: Remove warning -Wcast-function-typerbuj1-5/+6
2021-02-23xsettings: Remove warning -Wcast-function-typerbuj1-5/+8
2021-02-23background: Remove conversion warningsrbuj1-2/+2
2021-02-23media-keys: Remove conversion warningsrbuj3-24/+26
2021-02-17housekeeping: Remove warning -Wcast-function-typerbuj1-2/+1
2021-02-13housekeeping: override finalize method in MsdHousekeepingManagerrbuj1-0/+10
2021-02-13housekeeping: promote MsdHousekeepingManager class to final typerbuj2-55/+33
2021-02-12typing-break: promote MsdTypingBreakManager class to final typerbuj2-81/+52
2021-02-12sound: promote MsdSoundManager class to final typerbuj2-56/+33
2021-02-02cppcheck warning: struct member is never usedrbuj1-0/+2
2021-02-02background: promote MsdBackgroundManager class to final typerbuj2-141/+92
2021-02-01cppcheck warning: Variable is assigned a value that is never usedrbuj3-11/+5
2021-02-01cppcheck warning: known condition is always truerbuj3-8/+6
2021-01-31cppcheck warning: null pointer redundant checkrbuj1-2/+1
2021-01-28housekeeping: Do not use deprecated gtk_image_new_from_stockrbuj1-1/+1
2021-01-07Remove warning -Wshadowrbuj4-6/+8
2020-12-04Use g_slist_free_fullrbuj3-10/+5
2020-12-04msd-background-manager: use g_list_free_fullrbuj1-2/+1
2020-10-11msd-media-keys-manager: 'GTimeVal' is deprecatedrbuj1-4/+1
2020-09-05a11y-keyboard: Add support for togglekeys-backend settingColomban Wendling1-5/+23
2020-09-05a11y-keyboard: Delay registration of the pluginColomban Wendling1-1/+5
Delay registration of the a11y keyboard plugin to run after the non-a11y keyboard one to avoid numlock state change conflicts.
2020-09-05a11y-keyboard: Add sanity checks on beep sequence preferencesColomban Wendling1-6/+9
2020-09-05a11y-keyboard: Manually beep for togglekeysColomban Wendling1-0/+63
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.
2020-08-15add G_GNUC_UNUSED in some unused parametersPablo Barciela20-84/+99
2020-08-08a11y-keyboard: Don't show UI for unavailable feature in the pref dialogColomban Wendling1-0/+15
2020-08-08a11y-keyboard: Don't create a dummy object if AT-SPI is not availableColomban Wendling3-39/+25
Instead guard the caller to only use it if available.
2020-08-08a11y-keyboard-atspi: Switch to a final type and reduce boilerplateColomban Wendling2-42/+28
2020-08-08a11y-keyboard: capslock-beep: Try and detect non-buggy libatspi2Colomban Wendling1-10/+7
Try and avoid the workaround for buggy libatspi2 if we can know the version we're using has it fixed.
2020-08-08a11y-keyboard: capslock-beep: Don't ring on CapsLock itselfColomban Wendling1-26/+8
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.
2020-08-08a11y-keyboard: Refactor in the hope the AT-SPI bug gets fixedColomban Wendling1-32/+31
2020-08-08a11y-keyboard: Add support for ringing the bell when CapsLock is activeColomban Wendling6-1/+357
2020-07-17msd-media-keys-manager: comparison of unsigned expression in '< 0' is always ↵rbuj1-1/+1
false
2020-07-16msd-a11y-keyboard-manager: implicit declaration of function 'd'rbuj1-4/+4
2020-07-13build: Use MATE_DEBUG_CHECK macrorbuj1-13/+6