After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 709213 - Move input configuration to accountsservice
Move input configuration to accountsservice
Product: gnome-settings-daemon
Classification: Core
Component: keyboard
Other All
: Normal normal
: ---
Assigned To: Rui Matos
Depends on:
Reported: 2013-10-01 17:12 UTC by Allison Karlitskaya (desrt)
Modified: 2019-03-20 11:12 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Allison Karlitskaya (desrt) 2013-10-01 17:12:41 UTC
We currently store the list of input configurations in GSettings.

So that the information is available at the login screen (to allow the user to enter their password with their own layout) we want to move the settings to accountsservice.  At the same time, this will give us a chance to expand the format to be based on dictionaries rather than tuples (which will fix the current situation whereby it's not possible to specify the layout to use a given input method with).

Since we're storing the information in accountsservice, we need to stop storing it in GSettings (since syncing those two things up would not be fun).  It is also my opinion that the current-selected layout should be treated as transient state, and not stored anywhere persistent.

I particularly believe this to be the case because it is very important that the layout at the login screen (where the user is typing their password) be set in a predictable way, not affected by what happened to be the last-selected layout the last time the user was logged in.

This will impact at least the following modules:

 - accountsservice: see

 - gnome-control-center: will have to update accountsservice instead of

 - gnome-settings-daemon: will have to get values out of accountsservice
   instead of gsettings

 - gnome-shell: can no longer use gsettings to query/set the layout

 - gdm: will want to display the layout options to the user and set them
   up in the X server.

Aside from simply moving the data from GSettings to accountsservice, two interesting problems will need to be solved.  The first is that, if the user changes their layout at the login screen, we should expect that that changed layout will be the active one once the session is logged in.  We therefore need a way to get that information from accountsservice into the session.

I think the easiest way to do this would be via an X property that stores the current layout.  We discussed just now on IRC storing an index into the list from accountsservice, but maybe it would be better if we GVariant-text-serialised the current layout (dictionary) and stored that, in order to avoid possible races whereby the list of layouts changes out-of-sync with the index pointer.

Second is that although it is a bit weird, but OK for gnome-shell to be looking at gsettings in order to compute the list of possible layouts for display and switching, we probably don't want gnome-shell talking to accountsservice for the same purpose.  It would be much better, in my opinion, if we put a D-Bus interface for this on gnome-settings-daemon and made the code in the shell as dumb as possible.  The interface could be as simple as telling the shell which user-visible strings to display in the menu and which is the active one.

Maybe we could even use GMenuModel and GActionGroup and leverage the existing code for these that's already in the shell. ;)

Another interesting question is about what will happen when the user is changing the list of input sources in the control center.  Obviously, we need to update the accounts service and also notify g-s-d (somehow) so that it can make changes to the current session in realtime.  Maybe we should just have, as part of our input sources API on g-s-d, an interface for adding and removing configurations.  That would allow the code in g-c-c to be very simple, grouping all of the "smarts" of how this works into a single place.  That would also mean that g-s-d is the sole keeper of the "current layout" state in the session, which is nice for everyone.

Assuming we go along with all of the above, I guess we'd see an interface on gnome-settings-daemon along the lines of the following:

org.gnome.InputSources {
  aa{sv}   sources;         /* read-only */
  int32    active_source;   /* read-only */

  .Add          (int32   before_index,
                 a{sv}   input_source_info);

  .Remove       (int32   index);

  .SetActive    (int32   index);


  .ActiveChanged   (int32   index);

  .ListChanged     (int32   position,
                    int32   removed,
                    aa{sv}  inserted);    /* NB: similar to GMenuModel */

or another more brute-force approach:

org.gnome.InputSources {
  aa{sv}   sources;         /* read/write */
  int32    active_source;   /* read/write */

gnome-settings-daemon would make sure each a{sv} contained a "display-name" property for the benefit of simplicity of implementation in the shell.  Adding or removing sources would cause gnome-settings-daemon to take care of the legwork in dealing with accountsservice and handling setup of X/ibus/etc.

I'm implicitly assuming here that the user will be permitted to modify their own keyboard layout.  If the admin were to want to restrict that (using polkit) then we may need some way for g-s-d to notify g-c-c that changes are not permitted, because although the user would be making changes in g-c-c, the actual write to the backend would be done from g-s-d.  Maybe that is reason enough to make the g-s-d interface only useful for the shell (ie: viewing the currently-setup layouts and changing between them) and having g-c-c itself modify the accountsservice.

Implicitly, the first item in the list would be the default one.
Comment 1 Rui Matos 2013-10-02 12:07:58 UTC
I agree with the general idea here. The details will likely end up being different though since I already had plans to essentially move the g-s-d keyboard plugin into gnome-shell since we need that for wayland in any case. 

Mutter will provide an API for low-level keyboard settings/layouts (working both with X and with a wayland implementation in mutter-wayland). gnome-shell then can use that API and the IBus API to set the configuration from accountsservice. I don't think we'll need a specific DBus API, at least initially, since we only need runtime state inside gnome-shell.

In any case, g-c-c's region panel does need porting to the accountsservice API.

Regarding the gsettings schema we currently have:

org.gnome.desktop.input-sources current
org.gnome.desktop.input-sources per-window
org.gnome.desktop.input-sources show-all-sources
org.gnome.desktop.input-sources sources
org.gnome.desktop.input-sources xkb-options

we'll keep using 'per-window', 'show-all-sources' and 'xkb-options' and we can deprecate 'current' and 'sources'.

The 'xkb-options' here are for global things that apply to all input sources like swapping CapsLock and Ctrl. Each individual input source in the accountsservice API can provide specific xkb-options that we then merge with the user's global ones. We could also move this to the accountsservice API but I don't see the usefulness in that.
Comment 2 Allison Karlitskaya (desrt) 2013-10-02 16:35:08 UTC
The idea of global xkb options is mostly a question of user interface, I think.  If we expect a consistent experience in the session and at the login screen then we need to have the same treatment given for xkb options in both places.

I think it therefore makes sense to always copy the xkb-options into the input configuration.

That said, there could be a concept within g-c-c itself that some xkb-options are applied to all newly-configured input sources (or even to all existing sources when they are changed).  It might make sense to keep that in the GSettings key.  That's for a designer to decide.

Being strictly a question of UI, g-s-d would pay no consideration to this key when configuring the input setup (because it would not have access to the information at the login screen, so it couldn't do it there).
Comment 3 Allison Karlitskaya (desrt) 2013-10-02 16:35:55 UTC
One more note: I think putting this in the shell makes sense, but we should allow for the possibility where it is not integrated in the shell.  I think we should therefore have a well-known bus name that this interface is on, which may or may not be owned by the shell.
Comment 4 GNOME Infrastructure Team 2019-03-20 11:12:57 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: