GNOME Bugzilla – Bug 690436
Show the user's actual keyboard layout
Last modified: 2021-05-25 17:46:19 UTC
The layout shown in the onscreen keyboard UI in gnome shell does not match the keyboard layout that the user set in the control center and (if multiple layouts are present) which one the user selected in the shell's keyboard layouts menu. In my case, I need to be able to type accents (with a French Canadian dvorak layout), and the simplified qwerty layout presented by gnome-shell does not allow that.
it does allow it, actually - if you press and hold, you get a secondary popup with accents, for keys where such accents are meaningful. I think we should probably have some visual indication that there is such a popup
Interesting, didn't think of the "long press" feature. The point still stands though, it should reflect the user's chosen keyboard layout, or then I would argue that it should be alphabetic rather than qwerty (which is arbitrary and not the standard everywhere anyway).
the layout switching actually implemented, but there are only 3 predefined layouts: ara, il, us. if you create one under /usr/share/caribou/layouts/touch/ it should be picked. there's a patch to use XKB geometry (bug 660368) but it might not be ideal for onscreen keyboards. another idea could be to utilize Unicode CLDR keyboards data (for example, http://www.unicode.org/repos/cldr/tags/latest/keyboards/android/) to generate the layout files.
(In reply to comment #3) > the layout switching actually implemented, but there are only 3 predefined > layouts: ara, il, us. if you create one under /usr/share/caribou/layouts/touch/ > it should be picked. > > there's a patch to use XKB geometry (bug 660368) but it might not be ideal for > onscreen keyboards. another idea could be to utilize Unicode CLDR keyboards > data (for example, > http://www.unicode.org/repos/cldr/tags/latest/keyboards/android/) > to generate the layout files. That sounds like a great first step. The number of layouts is also limited, but they still have more than us :) Is there documentation on the file format and/or a preview application to consume those files? We'll probably need to work on some design requirements for the various keyboards, as we probably don't want to start shipping on-screen keyboard keymaps with every physical key shown.
See also https://wiki.gnome.org/Design/OS/ScreenKeyboard
(In reply to comment #4) > Is there documentation on the file format and/or a preview application to > consume those files? The format is described in UTR#35 Part 7: http://www.unicode.org/reports/tr35/tr35-keyboards.html#Keyboards I haven't heard of a previewer, but I think it would be straightforward to implement, reusing the caribou antler code.
Created attachment 294651 [details] [review] libcaribou: Enable keyboard creation from a file
Created attachment 294652 [details] [review] antler: Add --preview option to antler-keyboard As suggested by Bastien Nocera in https://bugzilla.gnome.org/show_bug.cgi?id=690436#c4, a previewer would come in handy for designers to tweak auto-generated / imported layout files. This adds 'preview' sub-command to antler-keyboard. To use: ./bin/antler-keyboard -c preview -f data/layouts/touch/us.xml
Review of attachment 294652 [details] [review]: Commit subject says "--preview" but the message says "-c preview", which is it?
Oops, the subject is wrong. Thanks for pointing it out before committing.
Attachment 294651 [details] pushed as 927311e - libcaribou: Enable keyboard creation from a file -- Pushed with the typo fix.
*** Bug 770761 has been marked as a duplicate of this bug. ***
I have a question that should relate to this. Which keyboard layout does caribou actually load? I've tried messing around in /usr/share/caribou/layouts, but I'm still stuck with a qwerty layout, no matter what I try. I would prefer to use a tablet qwertz layout, because it has arrow keys and fits my language. This works perfectly fine using the preview command, but not during regular usage.
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 enhancement request ticket at https://gitlab.gnome.org/GNOME/caribou/-/issues/ Thank you for your understanding and your help.