GNOME Bugzilla – Bug 695466
Improve input chooser filtering responsiveness
Last modified: 2021-06-09 16:08:36 UTC
You might have noticed that the input chooser filtering can feel quite slow. This patch set tries to address that. No UI changes in here.
Created attachment 238416 [details] [review] region: Add all widgets at input chooser start Switching from showing the locale widgets to the filter results or vice versa turned out to take a noticeable time. This was mainly caused by removing and adding widgets from EggListBox. To avoid that we can add all the widgets initially and then filter according to the mode we are in.
Created attachment 238417 [details] [review] region: Rate limit the input chooser filtering Acting on every keystroke makes the UI sluggish given the number of widgets we have so let's rate limit this to a reasonable frequency that still feels responsive.
Created attachment 238418 [details] [review] region: Stop focusing the input chooser entry if already focused Since doing so selects the entry's text and thus is prone to cause accidental deletion.
(In reply to comment #3) > region: Stop focusing the input chooser entry if already focused This is included here because it only became a problem after the rate limiting patch.
Review of attachment 238416 [details] [review]: I think that this should probably 2 separate pages in a GdStack instead because the code is getting unwieldly. Furthermore, that would allow us to get transitions from one set of results to the other.
Review of attachment 238417 [details] [review]: Looks fine. ::: panels/region/cc-input-chooser.c @@ +44,2 @@ #define MAIN_WINDOW_WIDTH_RATIO 0.60 +#define FILTER_TIMEOUT 150 /* ms */ Maybe using gtk-timeout-initial from GtkSettings is nicer?
Review of attachment 238418 [details] [review]: Looks good.
(In reply to comment #6) > Review of attachment 238417 [details] [review]: > > Looks fine. > > ::: panels/region/cc-input-chooser.c > @@ +44,2 @@ > #define MAIN_WINDOW_WIDTH_RATIO 0.60 > +#define FILTER_TIMEOUT 150 /* ms */ > > Maybe using gtk-timeout-initial from GtkSettings is nicer? Not sure if it makes much sense. That setting is used by gtk+ itself for a timeout to start faking repeats when you press the mouse button in e.g. a GtkSpinButton. FWIW, gnome-shell also uses an hardcoded 150 ms timeout to trigger searches in the overview.
Filed bug 700229 to add rate limiting support to GtkSearchEntry itself.
Leaving open for the other patch. I'll look into it for 3.10. Attachment 238417 [details] pushed as 11fdfbf - region: Rate limit the input chooser filtering Attachment 238418 [details] pushed as 139b810 - region: Stop focusing the input chooser entry if already focused
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.