Unicode Common Locale Data Repository has a good number of touch layouts defined (see 
http://www.unicode.org/cldr/charts/latest/keyboards/layouts/index.html).

I adapted a carobou script to convert them to JSON usable in GNOME Shell. You can find it on: http://www.unicode.org/cldr/charts/latest/keyboards/layouts/index.html

Sorry http://repo.or.cz/cldr2json.git

I really think you should consider switching to Onboard.

It has a few issues with GNOME because it has had to be developed as a third-party addon (sort of like how Night Light wouldn't work in Wayland, etc.). Try it with GNOME on X. Enable its GNOME Shell extension. It natively supports a lot more keyboard layouts, is themeable and is actively maintained. Ubuntu has been including Onboard by default for years with Unity.

I tried Onboard under GNOME Shell (on Debian stable).

Its layout support looks pretty good. It has support for word suggestions while typing, which is in the GNOME OSK design, but have no implementation plans.

However, it doesn't look integrated with the desktop and the window placement is often over the entry. It also has a way too much settings. It doesn't obey the accessibility settings defined in the desktop.

I wonder how easy would it be to use its layout and engines, but display our own interface?

(In reply to Jeremy Bicha from comment #3)
> I really think you should consider switching to Onboard.

This usually goes together with mentioning the virtues of the proposed replacement, and is usually done by the maintainers of the software since they'd also have an integration cost. Assessing the code this is what I see:

Pros:
- Has completion support for a number of languages
- Seems to handle more keymaps than Caribou

Cons:
- It's totally tied to X, can't be made to work as is for Wayland clients (no external OSK can really without special protocol). gnome-shell OSK has the bits necessary for both windowings, and none of the missing bits should be windowing dependent, let alone dragging a perpetual dependency on X11.
- Same as Caribou, much logic in focus determination and event delivery largely overlap with code we have in place in mutter/gnome-shell, and need for other unrelated pieces (eg. a11y, wacom pads). Such proposal at this time involves us bringing back code duplication that we already managed to get rid of.
- The keyboard *layout* is fixed (based on SVGs), the keycodes that belong to each key are determined using X facilities
- The code and data is not quite reusable externally. Everything is written in python, and the keyboard model is obtained with X as mentioned. The completion data might be parseable but that doesn't solve the question that this bug tries to address, and I'm pretty sure there's other better sources for per-locale lists of words.
- It doesn't bring us any closer to integrating ibus and other input methods with the onscreen keyboard.

So, using Onboard as-is is just not an option. The effort involved in making the pieces we miss reusable is just too high on both onboard/gnome-shell sides, and it wouldn't take any less code from our side at least. That's a no.

FWIW, work is being carried out at https://git.gnome.org//browse/gnome-shell/log/?h=wip/carlosg/osk-cldr

The script helped a great deal, I just needed this minimal patch on it for it to be able to generate all json files for the android directory in a go:

diff --git a/cldr2json.py b/cldr2json.py
index 1a25746..819899f 100755
--- a/cldr2json.py
+++ b/cldr2json.py
@@ -202,6 +202,5 @@ if __name__ == "__main__":
     if os.path.isfile(source):
         convert_file(source, destination)
     elif os.path.isdir(source):
-        os.chdir(source)
-        for path in glob.glob("*-t-k0-android.xml"):
+        for path in glob.glob(source + "/*-t-k0-android.xml"):
             convert_file(path, destination)

Btw, it's probably worth to clarify what this branch does:

- It uses the JSON files generated from Unicode CLDR data, which support many more layouts than Caribou (Although I'm surprised to find that it still lacks layouts for some notable ones)
- It updates the generated OSK UI to be like the mockups at https://wiki.gnome.org/Design/OS/ScreenKeyboard.
- It does not fix the OSK working atop generated keyboard events. Compositor and apps still need to agree on the keymap, and still fails for certain chars that can't be represented with a single keycode. This requires additional protocol support along mutter/gtk+, and will be addressed in a separate bug.

Carlos, would you reconsider Onboard if it wasn't written in Python anymore and not stricly tied to X? We've been working on a C++ port for a few months:

https://launchpad.net/onboardosk

> - It's totally tied to X
No longer, the port is meant to work on Wayland as well, though admittedly this part isn't complete.
> can't be made to work as is for Wayland clients (no external OSK can really without special protocol). 
It's not external anymore. libonboardosk.so is a shared library that can be embedded into GNOME Shell with the help of of some gi glue code and a shell extension.

> gnome-shell OSK has the bits necessary for both windowings, 
> and none of the missing bits should be windowing dependent
I agree, all "windows" are St derived actors now. They handle as if they were windows, though, with interactive moving, resizing, floating or docked as Caribou.

> let alone dragging a perpetual dependency on X11.
Still there, but unused on Wayland and could be removed with a configure switch if needed.

> Same as Caribou, much logic in focus determination and event 
> delivery largely overlap with code we have in place in mutter/gnome-shell, and need for other unrelated pieces (eg. a11y, wacom pads). 
> Such proposal at this time involves us bringing back code 
> duplication that we already managed to get rid of.
Agree again and I can't offer a solution here. I'm trying hard to rely on whatever GNOME Shell provides, but often there is no replacement for what we already had in the old Onboard. Monitor size in mm? Focusing/auto-show works independently of GNOME Shell, because it works now, but I'm not opposed to changing that.

> - The keyboard *layout* is fixed (based on SVGs), the keycodes that
> belong to each key are determined using X facilities
Still using SVGs, but there is quite a bit of flexibility in determining key labels. Where used, keycodes are fixed, but labels and actions are assigned at runtime, based on either Xkb or Wayland keymap information.
The advantage of SVG based layouts has been for us, that they are customizable by users. I don't know if this is relevant to GNOME Shell, though.

> - The code and data is not quite reusable externally. Everything
> is written in python, and the keyboard model is obtained with
> X as mentioned. 
The vast majority of the code is C++ now, some C for the GObject introspection library and JavaScript for the shell extension.
The core library doesn't depend on a particular toolkit and could theoretically be embedded into stand-alone Gtk or Qt applications. The focus is on the GNOME Shell extension, however. 
Keymap information can come from either X or Wayland, extensible to whatever comes next.

> The completion data might be parseable but that doesn't solve 
> the question that this bug tries to address, and I'm pretty sure
> there's other better sources for per-locale lists of words.
I'm sure there is better, but its not just completion and word lists. There is spell-checking, auto-capitalization, completion and prediction based on an n-gram trie (unlimited order but configured to store trigrams), with interpolating smoothing and recency caching. The language models look like word lists mainly due to memory constraints with the old Python Onboard. Whatever you typed has always been remembered as trigrams, though. Getting better language models is a matter of re-running a script. They used to be 30MB in the beginning, then shrank down to >1MB. Now with python out of the picture they could grow again.

> - It doesn't bring us any closer to integrating ibus and other 
> input methods with the onscreen keyboard.
True, though input method integration is high on my list. Also, whatever Wayland interfaces for OSKs GNOME Shell/mutter will add, we'll welcome and support them. AFAICT, there's nothing of that sort available currently (unlike in Weston).

If there's interests I'd be happy to work with you. This message was typed with the OnboardOSK, embedded into GNOME Shell (because I can and it needs more testing).

This was done for 3.28.