GNOME Bugzilla – Bug 746288
status/keyboard: Add a system settings concept to be used under GDM
Last modified: 2015-03-17 17:18:53 UTC
g-s-d has been taking care of this for us but in a very hackish way that causes dconf writes on every startup and also doesn't handle dynamic updates to locale1's properties which has become a problem now that GDM keeps its greeter session running in parallel with users'. To take care of this properly, this commit introduces a settings abstraction with both system and session implementations. The session implementation just wraps access to the existing gsettings while the system one gets its values from org.freedesktop.locale1's properties.
Created attachment 299511 [details] [review] status/keyboard: Add a system settings concept to be used under GDM
*** Bug 746185 has been marked as a duplicate of this bug. ***
Review of attachment 299511 [details] [review]: ::: js/ui/status/keyboard.js @@ +314,3 @@ Lang.bind(this, this._switchInputSource)); + if (Main.sessionMode.isGreeter) + this._settings = new InputSourceSystemSettings(); I wonder if it would make more sense to have a single InputSourceSettings class that falls back to the locale1 properties when the GSettings values are empty ...
(In reply to Florian Müllner from comment #3) > I wonder if it would make more sense to have a single InputSourceSettings > class that falls back to the locale1 properties when the GSettings values > are empty ... This would mean that when logging in to a freshly created user account, gnome-shell wouldn't be using the session settings and thus, changes done by the user in g-i-s and/or g-c-c wouldn't be reflected in the shell until the next log in.
But if the user/g-i-s sets something up, the gsetting isn't empty anymore, is it? Note that I'm suggesting a single class that combines system- and session settings, not to pick one or the other based on whether the session has been configured. (sth like: get inputSource() { let sources = this._settings.get_value('input-sources'); let nSources = sources.get_n_children(); if (nSources == 0) return this._systemSources; .... }
(In reply to Florian Müllner from comment #5) > But if the user/g-i-s sets something up, the gsetting isn't empty anymore, > is it? Note that I'm suggesting a single class that combines system- and > session settings, not to pick one or the other based on whether the session > has been configured. I see your point and this would work except in already existing deployments where gdm user's gsettings are already populated due to the previous hack that I was using in g-s-d :-(
Pushing after agreement on IRC Attachment 299511 [details] pushed as 4da2862 - status/keyboard: Add a system settings concept to be used under GDM