Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prefer AccountsService's InputSources property instead of custom KeyboardLayout/XkbOptions pair. #70

Open
Marukesu opened this issue Jun 26, 2023 · 1 comment
Labels
Needs Design Waiting for input from the UX team Priority: Wishlist Not a priority, but something that might be nice Status: Confirmed Verified by someone other than the reporter

Comments

@Marukesu
Copy link
Contributor

Currently (inspecting the system bus) we keep keyboard state in two AccountsService interfaces:

  • io.elementary.pantheon.AccountsService (ActiveKeyboardLayout, and KeyboardLayouts).
  • io.elementary.SettingsDaemon.AccountsService (ActiveKeyboardLayout, KeyboardLayouts, and XkbOptions).

At the same time, the standard org.freedesktop.Accounts.User interface has a InputSource property that can replace both KeyboardLayouts and XkbOptions properties from our custom interfaces.

@Marukesu
Copy link
Contributor Author

So, i did a little search about it, and seems to be a ubuntu patch (proposed upstream here).

it stores a array of dictionaries, the keys are ibus, xkb, and xkb-options. currently i have this value in my system (probably set by GSD):

~$ busctl --system get-property org.freedesktop.Accounts /org/freedesktop/Accounts/User1000 org.freedesktop.Accounts.User InputSources
aa{ss} 2 1 "xkb" "br" 1 "ibus" "xkb:br::por"

The major issue is that this is a Ubuntu patch, so maybe we want to mirror it in another interface for downstream usage (at least, i known that fedora doesn't include it).

@lenemter lenemter added Needs Design Waiting for input from the UX team Priority: Wishlist Not a priority, but something that might be nice Status: Confirmed Verified by someone other than the reporter labels Sep 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs Design Waiting for input from the UX team Priority: Wishlist Not a priority, but something that might be nice Status: Confirmed Verified by someone other than the reporter
Projects
None yet
Development

No branches or pull requests

2 participants