With the new layout switching, the size of the layout can change. The
scale depends on the size of the layout. Update the graphics scale when
the layout changes.
The core may need to control the scale of the input positions to layout
positions, such as when the layout is changed. Handle the scaling of
input positions in the button of the keyboard.
The main layout (e.g. latn_bone.xml and latn_neo2.xml) may disable the
bottom row by adding a property to the XML keyboard tag. Omit the bottom
row when this is the case.
In the Unexpected Keyboard, the bottom row always has the width of the
main layout despite being defined with a width of 10 units. Resize the
bottom row according to the main layout to improve layouts like
arab_pc.xml and numeric.xml.
Some fields in the layout can be abandoned when parsing is complete. The
code for opening and parsing a file is partially duplicated for the main
layout and bottom row. Separate the parsing into a new struct to make
the individual results easier to work with.
Some applications have features (like typing Unicode codepoints in foot)
that can only be used with key presses. Add a Meta key to allow the user
to always send a keypress.
Extend the height of the label when a glyph goes past the descent.
Also truncate the bitmap when the height is final.
Also remove statements added for debugging.
Some glyphs, specifically some Arabic text, may have a top that is
higher than the ascent value of the font, or a bottom that is lower than
the descent value of the font. For glyphs that fit inside the area, the
ascent and descent should be used for aligning with the top or bottom of
a key respectively. For glyphs that do not, align the top and bottom of
the text with the top and bottom of the key.
When one modifier key is released, only the same key is drawn, even if
there are other identical modifier keys. Be consistent with this
optimization, and only draw the exact key that was pressed when a
modifier key is pressed.
Most future modifier keys will be accents that wouldn't be represented
with an actual key press. Only emit modifier keys as key presses if they
are of the other type (Ctrl, Alt, Shift).
Keys are unsupported if they have no name, or if xkeysym uses a
different format for their name (e.g. XF86Fn). Skip key symbols that
have no name and can't be added to the text keymap.
To support this, set the availability of each keysym before updating the
keymap.
If the key value can emit text, it should put the text to be emitted in
the text field. It should not put any special symbol for the key label,
and it should instead be a special case in the display_label() method.
Some keys may have no XKB key symbol, but still have the ability to emit
text. Examples include the "‹" (U+2039) and "›" (U+203A) characters. Add
the text property to key parts so they can emit text even with no key
symbol.
Also, for keys that were not modified by the Function key because they
had no XKB key symbol name, modify them.
The Held state is for modifier that should be off when the corresponding
key is released. If the user presses the modifier key and a normal key,
it would be in this state. The modifier would continue to be active when
the user moves to a different key part (a cancel, e.g. from Fn to Alt)
afterwards. To fix this, add the HeldPressed and HeldLockedPressed
states that reset to the Released state when cancelled.
Keeping the keys pressed can confuse some compositors, and the key codes
may change. Release any keys that are pressed while the keymap is
changing, and press them again afterwards.
