More boring planning...

So its been a while since my last update, and for most of the time I've been busy planning the rest of my project. I'll get on to that later, but first let me sum up exactly where I got to with my coding.

Virtual Keyboard

• Dragging feature
  • made it possible to drag the keyboard around the screen when part of it that was not a key was clicked
  • also made it snap to the sides of the screen
• Fixed bug in event delivery
  • found that when many key presses were delivered after keyboard was shut the SCUMM game that I was testing with would ignore the first few keypresses and only register the final one
  • fixed this by implementing a delay in the event manager's delivery of queued events
• Handling of GUI and VK displaying at same time
  • before I would unconditionally clear the overlay before displaying the keyboard, but if the GUI had been displaying then bad things would happen once the keyboard was closed
  • to get round this, when the GUI was active I would save the overlays contents when the keyboard was opened
  • then this would be the background to blit the keyboard into, every time it had to be redrawn
  • and when the keyboard was hidden, the original overlay contents would be written back to the overlay
• Documentation
  • added comments to public interface of classes
  • added explanation of XML file format to VirtualKeyboardParser.h, which will later be added to wiki

After doing this, I started researching the keymapper task, so that I could get a better idea of all the stuff I have left to do. After reading up and asking questions on the mailing list I was ready to come up with a breakdown of my design.

Keymapper breakdown:

I chose to break down the keymapper task into four main classes that I would need to implement.

• Mapping class:
• will store details of a particular key mapping and offer simple methods to carry out the mapping
• will also provide methods to edit the mapping (which will be called by the Edit Mapping GUI dialog)
• Keymapper class
• will provide interface to rest of system, and will be accessible via EventManager
• will store a pointer to the active Mapping class
• and other state such as the active gameid, etc...
• will provide method to switch to a different Mapping (which will be called by engines or other parts of system, e.g. main menu dialog)
• engine will call methods on game start that will allow it to specify game-specific Mappings (and the UserActions they require)
• backend will call methods (or possibly subclass?) that will allow it to specify which HardwareKey's are available
• MappingManager class:
• will be responsible for managing all the different mappings that are available
• involves the loading and saving of mappings to the standard ini file
• will load global mappings on creation, and will load game-specific mappings when prompted by engine calling methods on Keymapper class
• if no valid game-specific mappings can be loaded from the ini file the automatic mapping algorithm will be run
• Edit Mapping GUI dialog:
• will be implemented using the existing GUI toolkit
• using the descriptions from the UserAction and HardwareKey structs will make the dialog easily understandable
• the will be a number of label / button pairs
• each label will contain the UserAction description text
• each button will contain the mapped HardwareKey description text
• clicking the button will start an event loop, and the first event that is recognised to have come from a particular HardwareKey will re-assign that HardwareKey to the UserAction in question

Now that I had a good understanding of the second part of my project I came up with a rough TODO list.

TODO list:

Virtual Keyboard

• prepare a complete virtual keyboard pack
• waiting on original images from rob (IRC: sanguineh)
• add textbox to show what user has entered - 2 days
• maybe a special part of the keyboard image could be marked with a rectangular imagemap area
• then this area will be filled with text as user clicks keys
• will then need left/right arrows and backspace keys to alter this text
• shift key functionality - 2-3 days
• currently the keyboard only offers functionality of a caps lock key because mode can be changed to caps but then must be switched back to normal
• should be easy to offer a key that switches the mode but only until another key is pressed, at which point the mode is switched back to the original mode
• this leads to a separate point - do we require the virtual keyboard to offer functionality of control / alt keys?
• if so, then shift functionality should probably be done without mode switching but by implementing modifier keys in the keyboard - I think this is the most flexible approach

Keymapper

• Mapping class - 1-2 days
• Keymapper class - 3-4 days
• MappingManager class - 4-5 days
• Edit Mapping GUI dialog - 2-3 days
• Integration into system for testing purposes - 2-3 days

The last part of my planning extravaganza was to plan how I would spend my time over the remaining weeks.

Plan of Action

I have decided to get going on the Keymapper class in the next few days, before hopefully coming back to finish the Virtual Keyboard once I have some good images available. 18th July - 23rd July

• Mapping class - complete
• Keymapper class - complete
• MappingManager class - basic outline done

24th July - 28rd July

• Finish remaining features of Virtual Keyboard

29th July - 8th August

• Bulk of the MappingManager class
• Integration with rest of system

8th August - 11th August

• Edit Mapping GUI Dialog

12 August onwards

• Cleanup and finishing off code
• Writing documentation
• Preparing for final evaluations

Done! Sorry for boring you guys with all my planning, but I guess this benefits us all! Time to get back to the code...