GNOME Bugzilla – Bug 646764
Reimplement "delayed-apply" scales
Last modified: 2021-06-09 16:08:15 UTC
If you move the keyboard speed and delay sliders in the keyboard panel, you will notice a lot of hard disk activity. I think that's because we're sending a ton of g_settings_set() calls directly from the slider changed signal, which cause dconf to update its on-disk database repeatedly for each call. The code should accumulate the GTK+ events in an idle or a timeout and batch a change to g_settings_set (or GtkRange itself should have itself a way of receiving batched changes, or maybe even dconf should do batching itself?); I wonder if this is a more general problem in other control center panels.
Quite a few of the scale widgets in the control-center used to use the "delayed-apply" from the scale, which meant that the actual "value" property wasn't changed until the mouse was released. We could do with such a sub-class of the original GtkScale now that the functionality was removed from GTK+.
*** Bug 675672 has been marked as a duplicate of this bug. ***
Generalising the problem, we have the same problem in the mouse panel. Reimplementing a "delayed-apply" property would be the easiest to fix the problem.
*** Bug 690061 has been marked as a duplicate of this bug. ***
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new bug report at https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/ Thank you for your understanding and your help.