There’s been a rumor that I was working on improving gnome-shell on-screen keyboard, what’s been up here? Let me show you!
The design has been based on the mockups at https://wiki.gnome.org/Design/OS/ScreenKeyboard, here’s how it looks in English (mind you, hasn’t gone through theming wizards):
The keymaps get generated from CLDR (see here), which helped boost the number of supported scripts (c.f. caribou), some visual examples:
As you can see there’s still a few ugly ones, the layouts aren’t as uniform as one might expect, these issues will be resolved over time.
The additional supported scripts don’t mean much without a way to send those fancy chars/strings to the client. We traditionally were just able to send forged keyboard events, which means we were restricted to keycodes that had a representation in the current keymap. On X11 we are kind of stuck with that, but we can do better on Wayland, this work relies on a simplified version of the text input protocol that I’m doing the last proofreading before proposing as v3 (the branches currently use a private copy). Using an specific protocol allows for sending UTF8 strings independently of the keymap, very convenient too for text completion.
But there are keymaps where CLDR doesn’t dare going, prominent examples are Chinese or Japanese. For those, I’m looking into properly leveraging IBus so pinyin-like input methods work by feeding the results into the suggestions box:
The suggestion box even kind of works with the typing booster ibus IM. But you have to explicitly activate it, there is room for improvement here in the future.
And there is of course still bad stuff and todo items. Some languages like Korean neither have a layout, nor input methods that accept latin input, so they are badly handled (read: not at all). It would also be nice to support shape-based input.
Other missing things from the mockups are the special numeric and emoji keymaps, there’s some unpushed work towards supporting those, but I had to draw the line somewhere!
The work has been pushed in mutter, gtk+ and gnome-shell branches, which I hope will get timely polished and merged this cycle 🙂
Can we put the keyboard onto the right side of the screen?
@Frank: The keyboard is just another Clutter actor and can be positioned otherwise through extensions. But what is the “right” side of the screen? :). Left handed users would be pushed to having to reach the far edge, maybe partly covering the display with the arm.
One thing I’d like to investigate is splitting the OSK into left/right halves for wide screens while in landscape mode. I don’t know if that’s the usecase you had in mind.
Hi Carlos, currently the keyboard gets displayed in the lower left corner, what’s a but cumbersome for right-handed users. We may need a button for switching then…? Split-keyboard could be nice for users having their tablet lying on the table – but I own a Dell XPS 15 and I don’t think that this would be usable/comfortable for regular laptops. And thanks for your work!
> One thing I’d like to investigate is splitting the OSK into left/right halves for wide screens while in landscape mode. I don’t know if that’s the usecase you had in mind.
Yep there is definitely some waste of space on larger screens!
Actually even in your screenshot, you completely have space to add the numbers and more special characters (rather than having to switch between 3 or 4 layouts like right now, whatever the screen size!).
We have a bug report about this. 😉
https://bugzilla.gnome.org/show_bug.cgi?id=790581
@Frank: That is a bug in the current OSK, the keys aren’t given a size so the OSK ends up stuck to the left. The OSK should always expand to the full screen width. This gnome-shell branch also addresses that bug, and I intend to backport the fixes once it starts landing.
@Jehan: I don’t care about the waste of space :), this is UI that should disappear as soon as it’s unneeded. OTOH, the current position is uncomfortable whenever the user is actually holding the device, a split keyboard would allow to use 2 thumbs, as opposed to one index finger while the other hand is holding the device.
All layers of keys (lowercase, uppercase, special keys) come from CLDR, and I do not intend to deviate from that.