layout repository

Well, there's no separate repository for layouts I am aware of. The layouts you see in Onboard are part of the source code repository. It's possible someone had tried a split layout before, but I haven't heard of it yet.

I put some thought into this myself some time ago. The goal was to spread a single layout across multiple "windows", here basically two windows for left and right section, with a variable gap between them that exposes the screen below. Most new code kept that in mind, but it still isn't really supported yet. I might work on that again if there's demand.

I also have an interest in a split layout; it would be really nice for all the new tablet-style devices and Surface clones.

Thomas, have you made any progress with this? So far, all I have tried is taking the Compact layout and compressing and spreading out the keys to the left and right edge without worrying about using multiple windows or anything complicated. I think that would be a good first step to achieve something useful and to give time for something more fancy to be worked out.

So far, I've had some partial success. I can move most of the keys using Inkscape, but if I move the return key even a small amount, I get divide-by-zero errors. I'll post a more detailed question in a separate thread if I can't figure out what's causing it. Mainly, I'm curious if anyone else has made any progress that could be built on.

There's been another question since, that had the beginnings of a Typematrix-like keyboard posted.
https://answers.launchpad.net/onboard/+question/380573
That could have been interesting, but I haven't heard back and the links are dead by now. Maybe leave a note there so he knows somebody is interested.

The divide by zero probably happens just by saving with the latest Inkscape. Inkscape lately started inserting horizontal and vertical lines into the svg paths of the return key, which Onboard couldn't handle until recently. Our snapshot PPA should have the fix
https://launchpad.net/~onboard/+archive/ubuntu/snapshots

This doesn't help right now, but I made progress on multiple windows in Onboard for gnome-shell. We'll probably get a split keyboard there eventually. It's a lot more likely than for the current code base, at least.

I'll take a look at that link.

Thanks for the info about the divide-by-zero problem. I'm using OpenSuSE Tumbleweed so the snapshot PPA doesn't help for me, but for now I've worked around the problem by just deleting the return key and creating a new one that is strictly rectangular. Whatever Inkscape is adding, it must not be doing it for simple rectangles, or is doing it in a way that the current version of Onboard can handle it. When the fix makes it into a release that appears on Tumbleweed, I can reintroduce the fancier return key.

Multiple windows would certainly create the best functionality. For the moment, I think I've mostly figured out how the files and key designators work and I've been creating an SVG and matching .onboard file which consists of the original single window where I have resized and moved the left and right keys to the sides. I noticed that in the Onboard settings, it is possible to make the main window transparent. While that makes it appear as a true split keyboard, the single window is still there and you obviously can't interact with anything beneath it; however, I think it will be a reasonable workaround for the time being. I'll post a screenshot once I have it somewhat optimized.

Once multiple windows are implemented, it should be pretty easy to chop the SVG file into two.

Here's the direction I'm trying to go, though this is far from optimized and still very much a work in progress. Basically, just learning how things work at the moment:

https://www.dropbox.com/s/wpexv248u1x9mun/split_kbd_idea_screenshot.png

Yep, that's about what I had in mind too. We just need that multiple window support, not only to keep the area in between accessible, but also to be prepared for a wide range of screen resolutions. The sections should be anchored to screen edges without affecting the aspect ratio of the keys.

I'll be busy with this bug for quite a while, though:
https://bugs.launchpad.net/bugs/1672465
Once that's done eventually, I planned to take a closer look at split keyboards. The new Onboard is already prepared for multiple windows/clutter actors, but we need layout changes to actually use this.

Here's the commit that fixes the divide-by-zero, btw:
https://bazaar.launchpad.net/~onboard/onboard/trunk/revision/2284
And yes, this only affects the <path> tag. Replacing the paths with <rect> should work just fine.

Yes, all of those are advantages of having multiple windows for a true split keyboard.

I agree that getting Onboard working correctly in Wayland is far more urgent! I'm not using Wayland yet because I have an Nvidia card and the situation with Wayland and Nvidia is still somewhat messy if one needs to use the proprietary driver, but hopefully we'll all be using it soon.

I plan on using onboard as my main keyboard on a double monitor setup.
Currently I use the default layout
(https://images.discordapp.net/attachments/295966125387284481/339467796822097920/unknown.png?width=396&height=440)
But I plan on making a more natural one inspired by
(http://www.damngeeky.com/wp-content/uploads/2015/06/Keyboardio-Model-01-keyboard.jpg)
I spend the past several days fiddling with the code to see if somethings like LiquidKeyBoard or Dryft Virtual Keyboard is possible.
(LiquidKeyBoard: http://assets.hardwarezone.com/img/2011/12/LiquidKeyboard_news.jpg)
This would provide a more steady way of typing on a touchscreen when you're not looking at it.

Blind typing is a challenge on the virtual keyboard currently.

I would be willing to contribute the design and perhaps cooperate on a deeper going solution.

Hi Adam, concerning Keyboardio, keys with fixed arbitrary shapes can be created with the svg <path> tag already. Try the "Object to Path" option in Inkscape. They have to be polygons only, i.e. no round corners, splines, etc. See the return key in Compact-Alpha.svg for an example.
For simple rectangular (rotated) keys a single path at 100% size should be enough. More complex shapes (like return) may require two paths per key, one at 100% size and one at 50% size, both grouped together. Again, see the return key for an example. Onboard then interpolates between these paths to arrive at the final shape.

LiquidKeyboard: there is no support for affine transformations (beyond translation) in the layout tree yet. For continuous rotation of keys, one would probably want to add transformation matrices to layout-items.Keys/groups of keys would probably have to be placed into popup windows. There doesn't seem to be much use for the regular rectangular keyboard window. Lots of challenges in the details, but I'd imagine with enough determination it could be done.

I've done a small proof of concept of another keyboard layout, it worked as expected for rectangular keys, but for trapezoid I had to edit Layoutroot's get_key_at to search a point in polygons instead of rects.

I'm currently looking into an alternative loader (to replace LayoutLoaderSVG but it's quite dense to get trough.
The goal is to parametrically define a keyboard in a simple way and update it's layout according to button presses,
so when a button gets pressed the layout changes ever so slightly to accommodate for drift like Dryft and secondly
place the keys initially in relation to the user's hands.
This to address the problem of blind typing drifting and feeling unnatural.

I'll probably be looking into a dict representation of the with the keys being a point within the hitbox and the values calling the existing action framework.

> it worked as expected for rectangular keys, but for trapezoid I had to edit Layoutroot's
> get_key_at to search a point in polygons instead of rects.
Yes, there might be bugs lurking, it's a rarely used feature. However, the rectangles tested are meant to be bounding boxes in that case. After the first test succeeds, there is a more expensive point in polygon test already (get_hit_path().is_point_within(point)). If you post the layout somewhere I'll look into it.

> The goal is to parametrically define a keyboard in a simple way and update it's layout
> according to button presses,
it's probably wise to create keys manually and skip the layout files at first , I agree.

I think the original question was about a place where custom layouts could be found by everyone and where people could also share their custom layouts.

I don't know that the question was answered, unless the answer is, "no."

Custom layouts can be created. I have a folder in my home directory for custom layouts and people somewhere out there are creating them but there is no way for them to share what they have created or for others to find all the other layouts out there.

I too desperately want a split layout. I'm good with XML and SVG but trying to alter the "compact" layout utterly failed. Maybe it is my version of inkscape?

I want a repository for layouts and a split layout like iPad and Android have. I'm willing to put in the work but documentation is obviously lacking . I am sure that I am not the only one with this experience. Likely many who would have been assets to the project have hit the same snags and given up.

If you are wondering why more are not contributing. Here is your answer.