Time for another quick update on my progress recently. Generally, I think I am still on track with my plan of action that I set out a couple weeks ago.
Virtual Keyboard:
- Major refactoring of GUI code into a separate VirtualKeyboardGUI class. This meant VirtualKeyboard class only handled the detection of keypresses and the queuing of resulting events.
- This abstraction should make it easier to modify VK to use ScummVM’s GUI rather than being responsible for its own drawing like present.
- Display functionality complete – now a virtual keyboard pack can specify a rectangular area that will be used to display the virtual key presses that have occured.
- This was implemented by firstly creating a KeyPressQueue support class that not only kept track of the queue of KeyPress’s that the VK was generating, but also maintained a string representation of these.
- Then I added methods to the VirtualKeyboardGUI class to draw this String in the required area. I had to include textbox-like functionality e.g. handling when the string was too big for the area, drawing a caret, etc.
Keymapper:
- Saving/loading of keymaps to config file is implemented (but not tested extensively and saving of keymaps is not integrated yet)
- Simple automatic mapping algorithm has been implemented
- Keymapper class now uses a stack-based implementation for switching between active keymaps.
- This will make it easier for switching as we can push and pop keymaps onto the active stack (like ScummVM’s CursorManager does)
- The pushKeymap() method also takes an inherit boolean argument which says whether the Keymapper should use iterate down the active Keymap stack when a mapping for the given key is not found. This should be very powerful feature because it could allow the new keymap to only remap one or two keys, and get the rest of its mappings from the last active map.
- Started proper testing by integrating Keymapper into SDL backend. Just added method that sets up a simple HardwareKeySet and a simple Keymap.
Next steps:
- Develop the automatic mapping algorithm, considering the new stack-based implementation of the keymapper. My current thoughts:
- The automatic mapping algorithm should look at the maps that have already been added, so that it can use HardwareKeys that either have not been mapped yet, or at least have been mapped to a Action with low priority.
- This could be further improved by defining which keymaps will be parents of other keymaps. Then we only have to check the mappings of the parent Keymaps.
- In fact, the idea of keymaps having parents, and therefore being arranged in a tree structure, does seem like a good idea.
- More extensive testing of these new features
- Keymap dialog
So, finger’s crosses, I should have most of this done by the weekend. That leaves next week to really finish and clean up the code, test thoroughly and write documentation. OK…back to work!