Multi-key bindings

[Jim Stichnoth <stichnot@…>]

This patch adds support for emacs-style multi-key bindings, which is useful for smaller remote controls without enough buttons to map all your favorite actions. This is especially useful for the TV Playback context which has more than 100 available keybindings.

Before using this patch, you must manually execute the following mysql command. Unpatched code will still work correctly even after executing the command. If you try the patch without executing the mysql command, there's a good chance that *all* your keybindings will be reset to their defaults.

ALTER TABLE keybindings ADD COLUMN multikey varchar(128) default NULL;

The implementation currently has a few limitations. (Translation: I'd rather not do all the work before the patch is in principle accepted...)

1. Multi-key bindings are only handled in the TV Playback context, as well as the associated Global bindings. It would be very simple to support other contexts, except that I don't know how to provide reasonable feedback without an OSD object available.

2. Multi-key bindings are not (yet) implemented for JumpPoints?.

3. The only way to edit the multi-key bindings is through MythWeb with the attached patch.

4. Multi-key bindings are limited to 4 keys, due to the use of QKeySequence.

5. There is practically no checking for conflicts between regular keybindings and multi-key bindings.

6. It might be better if there were a timer to reset multi-key input after so long, like the QueuedInput? related code currently there.

[Jim Stichnoth <stichnot@…>]

Added v2 patch, which fixes a major bug (should test more thoroughly after making a "minor' change...), plus a couple of minor problems.

[Jim Stichnoth <stichnot@…>]

Updated with new mythtv and mythweb patches that add similar multi-key binding support for jump points.

The jumppoints table needs to be modified before using this patch. As before, unpatched code will still work with the updated database. The complete mysql is:

ALTER TABLE keybindings ADD COLUMN multikey varchar(128) default NULL;
ALTER TABLE jumppoints ADD COLUMN multikey varchar(128) default NULL;

To simplify the code, the original single-key bindings are now treated as non-special cases of multi-key bindings.

To maintain a good user experience, if the current queued input sequence ends with a single-key jump point action, the jump point takes precedence and is immediately handled.

Because of the nontrivial interplay between jump points and regular bindings (specifically, the possibility that a jump point with a local action with the same key binding will be treated as the local action rather than the jump point action), MythMainWindow::TranslateKeyPress?() had to be largely refactored/rewritten.

[Jim Stichnoth <stichnot@…>]

Updated version.

[Jim Stichnoth <stichnot@…>]

Change VERBOSE() to LOG().

[Jim Stichnoth <stichnot@…>]

Add Multikeydata::clear() and call it in MythMainWindow::ClearKeyContext?().

[Jim Stichnoth]

Closing as Won't Fix. I've been using this patch for over a year and I have to conclude that it isn't the right user experience for increasing the effective number of buttons on a remote. The main problem is that it is not very practical to have to memorize a collection of multi-button sequences. Compounding the problem is the fact that it is important to give feedback on partial multikey sequences, but hard to do so in a meaningful way. For example, I have a sequence that begins with the Thumbs-Up button on my remote, which is mapped via LIRC to Shift+F8, which is a prefix for actions EDIT, ADJUSTSTRETCH, DEBUGOSD, and TOGGLEFILL. None of these names is particularly suitable for given user feedback on partially input sequences.

I still think it's important to have some way of expanding the effective number of buttons on a remote control, so I'll be looking into better ways of achieving this.