Feature #985
closed
Add keyboard app
100%
Description
There is a cairo keyboard embedded in the old dialer app for the custom hardware Xeon project. This might still be used, perhaps as a library. Or I could try using matchbox-keyboard and fix up the display. Or I can try more sophisticated X/Wayland on-screen keyboards, like virtboard or squeekboard.
But I think the idea of having to use dbus for a keyboard seems odd. I don't want the keyboard to get keyboard focus either. But I need a general purpose solution that I can re-use across apps.
See- https://github.com/mwilliams03/matchbox-keyboard or https://github.com/xlab/matchbox-keyboard
- https://gitlab.com/cubocore/coreapps/corekeyboard
- https://source.puri.sm/Librem5/squeekboard
- https://source.puri.sm/Librem5/virtboard
- https://github.com/maliit/keyboard
- https://github.com/KDE/kvkbd
- https://www.semicomplete.com/projects/xdotool/ - fake keyboard input via XTEST. Comes with a library.
There is also bui-keyboard (cdtools buik), the Matchbox keyboard build I tested long ago. This could be embedded in a GTK+2 app. There are examples of how to do this. If nothing else, this could be a template for writing my own keyboard app. And then there is bui-fakekey (cdtools buif) that provides a library for simulating keypresses. With the latter I can capture a touch on a Cairo button and simulate the keypress in another widget.
Related issues
Updated by Hammel 5 months ago
- Status changed from New to In Progress
- % Done changed from 0 to 30
This mostly works. The build is updated to work with cross.sh. The metabuild includes a build for the keyboard. The package installs correctly but needs to fix the chmod in the postinstall to reference the correct program name.
The biggest problem is that the keyboard is teeny-tiny. It is no where big enough to actually use. You can see it, and you can tell it's a keyboard. But you can't really use it.
Updated by Hammel 5 months ago
Googling around, I found a newer version of Matchbox keyboard. This might help with the size issues. But I'll have to switch from local source (an app template) to remote source (a wrapper template) to use it.
There are other forks as well.- https://git.yoctoproject.org/matchbox-keyboard/ - the original version
- https://github.com/Xlab/matchbox-keyboard - even more recent, I think, than mwilliams03.
One other thought: I tested this without running matchbox. Maybe I should try that and see if the keyboard works better.
Updated by Hammel 5 months ago
The Xlab version doesn't build with a wrapper template because it requires the fakekey lib in the staging tree. That's when I discovered that matchbox-* are already in Buildroot.
So now I'm testing the keyboard that comes with buildroot to see how it works. Since these are already in the build I should be able to switch to the alternate repos and try them.
Updated by Hammel 5 months ago
Duh. It does work and is a full sized keyboard that fills the top of the display. This is fine for now. But I'll need to integrate different keyboard xml files for the phone, likely with larger keys. The numpad keys are fine, as in
matchbox-keyboard numpadThe keyboard name "numpad" is the suffix of the keyboard-<suffix>.xml layout files in /usr/share/matchbox-keyboard/. So dropping new keyboard descriptions there is how to go forward.
Note that the layouts directories in both of the alternate repos have additional keyboard layouts. I can also google for matchbox-keyboard layout for additional examples.
Eventually I may want to embed the keyboard in apps, but I'll decide that later when I need the keyboard input with, for example, the pidialer.
Updated by Hammel 5 months ago
Buildroot downloads a released file from yocto: https://git.yoctoproject.org/matchbox-keyboard/snapshot/matchbox-keyboard-0.1.1.tar.gz
This file says it's 0.1.1 but it's not the master branch. The master branch has lots of updated keyboard layouts, with the ones in the release archive pushed to an "old" directory. But those "new" keyboard layouts are from as far back as 2012, so 0.1.1 is really old.
I should try- Change the MATCHBOX_KEYBOARD_VERSION in the matchbox-keyboard.mk to "master" to have it pull the latest code instead of the older 0.1.1. This works if done manually.
- switching to git/master for the yocto releases
- switching to the mwilliams repo using GitHub's zip release.
Note that the layouts in mwilliams are similar to the latest in Yocto's release but the former has, at a minimum, added a keyboard-mobile layout. The ones in Xlab are limited, possibly just for use in Taiwan.
Updated by Hammel 5 months ago
Bumping to master mostly works, but the install process is broken on the yocto repo. There are also multiple warnings from autoconf/autotools.
Switching to mwilliams03 to see if that works better. Based on the commits it doesn't look like any install changes were made. I'll have to figure this out myself and patch it.
Updated by Hammel 5 months ago
Going back to my template build: I can build the Yocto master branch with the template build, after adding -lXrender to the CAIRO_LIBS env variable. Normally this would get added to the LIBS= but that variable gets overridden by the build. Since Cairo only has one lib, and I know that its libcairo, I just add CAIRO_LIBS="-lcairo -lXrender" and the linking for the Yocto master branch succeeds.
Doing this build gets me the updated keyboard layouts, but does NOT include the mobile keyboard.
So now I'll try the same build with the mwilliams03 build since it DOES have the mobile keyboard layout.
Updated by Hammel 5 months ago
ugh. The mwilliams03 source includes the mobile keyboard but it doesn't include it in the build install. It's just an extra file. I'll need to create a patch to the Makefile.am to generate the keyboard layout file from a *.in file (which will look exactly the same as the existing file) and then install it. Alternatively, I can just add it to the end of keyboards_DATA, which should skip the file generation process for that layout file.
Updated by Hammel 5 months ago
- % Done changed from 40 to 50
This is bizarre, but I cannot reproduce the Buildroot build of matchbox-keyboard. That build works, fills the display horizontally and uses a light white-to-gray gradient on the keys. It is the best build I have found of all the repos around, and it comes from the 0.1.1 release of the Yocto repo. After much testing I've decided to use this version and deal with display features (colors, font, etc.) later.
They text on the keys is black, so they keys don't show up well. But it's possible that the keyboard launched under the PiBox UI would pick up the GTKrc and the colors would be different. Maybe.
It's also possible that I can set the colors with Xresources. I'll try installing the pmsui package and see if that changes anything. I may need to install launcher too, though I kind of doubt it for this test.
Updated by Hammel 4 months ago
- % Done changed from 50 to 70
The matchbox-keyboard is working using the GTKRC installed for piboxmedisystem-ui (aka pmsui). The theme matches the rest of the display.
However, the default keyboard is very short vertically, making the keys unusable. The numpad layout has the same problem. The -geometry (or --geometry) option is not supported by the app.
I should look into the various other repos for mobile keyboards.
Updated by Hammel 3 months ago
The mwilliams03 version has a mobile keyboard configuration, but the others do not. So I'm trying that.
I created a tarball, /home/mjhammel/src/ximba/work/matchbox-keyboard/mwilliams03.tar.gz, that I can unpack on the SD card for Xeon. After boot I can copy these over to /usr/share/matchbox-keyboard/layouts (after moving the existing layouts out of the way). Then I can try the keyboard variants.
Updated by Hammel 3 months ago
The mwilliams03 layouts seem to work okay but have the same size problem. I should note that the keyboard.xml from the mwilliams03 collection doesn't work, but switching back to the yocto version of that file make it and the others work fine.
It looks like this bit of code in matchbox-keyboard-ui.c sets the height of the app:
if (get_desktop_area(ui, NULL, &desk_y, &desk_width, &desk_height))
{
/* Assuming we take up all available display width
* ( at least true with matchbox wm ). we resize
* the base ui width to this ( and height as a factor )
* to avoid the case of mapping and then the wm resizing
* us, causing an ugly repaint.
*/
if (desk_width > ui->xwin_width)
{
mb_kbd_ui_resize(ui,
desk_width,
( desk_width * ui->xwin_height ) / ui->xwin_width);
}
wm_struct_vals[2] = desk_y + desk_height - ui->xwin_height;
wm_struct_vals[11] = desk_width;
XChangeProperty(ui->xdpy, ui->xwin,
atom_NET_WM_STRUT_PARTIAL, XA_CARDINAL, 32,
PropModeReplace,
(unsigned char *)wm_struct_vals , 12);
DBG("desk width: %i, desk height: %i xwin_height :%i",
desk_width, desk_height, ui->xwin_height);
}
I could patch this and test if it changes the height, or I could write a an app that sets it's height and embed the keyboard in it. The widget that embeds the keyboard would then set the height instead of my trying to modify the keyboard code. See the example/matchbox-keyboard-embed.c code for an example of this. This seems like the best way to deal with this because the widget embedding the keyboard can then switch keyboards via user request.
One way to test this would be to use a VM so I could install matchbox libs from the yocto source to /usr/local, then play with the embed module to see how that would work.
Updated by Hammel about 2 months ago
- Status changed from In Progress to Closed
- % Done changed from 70 to 100
I spent the day looking at the examples in matchbox-keyboard and I just couldn't get the embed feature to work. Without a working version of that there is no point continuing to look at using matchbox-keyboard.
None of the keyboard projects I found are suitable for my needs. Some are Qt and/or Wayland based. Some are overly heavy to support all kinds of languages. While I do want different keyboard layouts, such a number pad vs alpha keys, I don't want this to be overly complex.
Instead, I'm going back to pidialer and try to generalize the keyboard use there into a library or GtkWidget (the latter would make more sense). And I'll integrate the use of JSON as the keyboard layout language since that's already built into libpibox.
This issue is going to be closed with the focus moving to RM #700 to work on the keyboard abstraction.