mirror of
https://github.com/edu4rdshl/gnome-shell.git
synced 2026-07-18 07:34:54 +00:00
We currently special-case the DISABLED error when initializing
filtering, but not on app filter changes.
While it seems reasonable that Malcontent.Manager wouldn't emit
the signal while disabled, that's not actually true: It is emitted
when any user account information tracked by AccountsServices
changes.
Even if the signal were limited to changes of the ParentalControls
extension, it would still get emitted when app filtering *becomes*
disabled.
So regardless of potential improvements in libmalcontent itself,
we should filter out the DISABLED consistently, both when creating
the initial filter and when updating it.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6749
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2796>
(cherry picked from commit
|
||
|---|---|---|
| .. | ||
| config.js.in | ||
| dbusUtils.js | ||
| extensionUtils.js | ||
| fileUtils.js | ||
| gnomeSession.js | ||
| history.js | ||
| ibusManager.js | ||
| inputMethod.js | ||
| introspect.js | ||
| jsParse.js | ||
| keyboardManager.js | ||
| loginManager.js | ||
| meson.build | ||
| modemManager.js | ||
| objectManager.js | ||
| params.js | ||
| parentalControlsManager.js | ||
| permissionStore.js | ||
| signals.js | ||
| signalTracker.js | ||
| smartcardManager.js | ||
| systemActions.js | ||
| util.js | ||
| weather.js | ||