Opened 11 years ago

Closed 4 months ago

#10053 closed Patch - Feature (Trac EOL)

MythUI KeyBinding reworked

Reported by: Xavier Hervy <xavier.hervy@…> Owned by: stuartm
Priority: minor Milestone: 29.2
Component: MythTV - User Interface Library Version: Unspecified
Severity: medium Keywords: mythui lirc
Cc: xavier.hervy@… Ticket locked: no


This patch is an attempt to dissociate the key-bindings for the keyboard from other inputs such as lirc, apple remote...


This is just a proof of concept and should probably NOT be apply to any local source code. I only attached this patch to avoid a Feature request without patch response and also to show that I am willing to work on this area.

This patch have been done somewhere between 0.24 and 0.24.1 then ported to the HEAD. I did not try it on head, only build it.

What is the problem with the current implementation

  • It is difficult to create a remote configuration
    1. Setup lirc and add all the remote control we plan to use in lircd.conf
    2. Create a .lircrc file and map the button to key
    3. Start mythfrontend to test the configuration
    4. Go in mythcontrol to check what key is doing what
    5. Change the .lircrc configuration accordingly
    6. restart step 3 for all remote control until it does work properly
  • It is even more difficult with more than on remote which haven't got the same buttons i.e. some remote have previous/next and rwd/ffd, another one only have previous/next but have the pause/play button separately ... you get the picture
  • If the user change the default key-binding, he take the risk to break any client application which rely on the network control interface such as mythmote ...
  • Only 4 keys can be bind to an action
  • The End user can not check in mythcontrol how a remote control have been configured as only key are displayed (not the real name from lircd.conf).

What this patch do

(I wrote this code 9 months ago so I am writing it down as I remember)

  • Allow to use lirc without .lircrc
  • if .lircrc is missing, the remote control can be configure with the real name in mythcontrol
  • any number of remote control (via lirc) can be configured independently (as long as there not identical)

How does it work

Main classes

I create a MythInputManager singleton class which is responsible to deal with the binding of keys and jumps for the keyboard. MythInputManager is also responsible to start any input such as lirc, appleremote ... (in my patch this is done statically as I am not very good with .pro files)

MythInputInterface is a new abstract class which implement QT Plugin facilities (declare "org.mythtv.MythInputInterface/1.0"); The new abstract class MythInputEvent represent an button press event such a QKeyEvent, MythLircEvent ...

Basically creating a new input interface is a matter of implementing few method:

  • start(): Start a service such as reading from a socket, ...
  • stop(): stop the service
  • restart(): ex: stop, reload a configuration file and start
  • name(): This is use when a binding need to be store in the database.

With a new input interface come an new implementation of the MythInputEvent class. A valid MythInputEvent class need to implement the following method:

  • clone(): to do a copy
  • inputName: return the name of the input which produce the event, except if the event have not been produce by any MythInputInterface such as MythKeyboardEvent and MythActionEvent
  • remoteName: return the name of the remote control which produce the event
  • buttonName(): user friendly name of the button pressed
  • buttonId(): a unique id of the button press (unique for the input/remote) during runtime, as this id is not persistently stored a simple auto increment does work. This is use by MythInputManager to store the mapping in memory
  • translateToActions(context,&actions): get the list of action an input event is linked to for a particular event
  • translateToJump(): same but for a jump
  • keyEvent(): return a QKeyEvent, this is for backward compatibility only and temporary. For Lirc, the QKeyEvent represent the configuration in .lircrc

Additional changes

!MythUIType::keyPressEvent(QKeyEvent * e) 

method have been replace by

!MythUIType::keyPressEvent(MythInputEvent * e)
bool MythMainWindow::TranslateKeyPress(const QString &context, QKeyEvent *e, QStringList &actions, bool allowJumps = true)

have been replaced by

bool MythMainWindow::TranslateKeyPress(const QString &context, MythInputEvent *e, QStringList &actions, bool allowJumps = true)

Every class which extends indirectly form MythUIType need to be converted (done in the patch)

I also added to field in the database in the keybinding and jumpoint table to hold the inputName and remoteName

Additionnal classes

  • MythKeyboardEvent: encapsulate a QKeyEvent
  • MythActionEvent: basic class which return the "buttonName" as a list of action when translateToActions is invoke regardless the context. This is usefull as in some part of the code a QKeyEvent is created to exit a dialog (If my memory is corrected)
  • MythLircInput and MythLircEvent

Potential uses

Based on the this changes, the followings feature could be implemented

  • Start a quick configuration setup when a new remote control is detected which could setup the basic navigational buttons (Left/Right/Up/Down/Ok/Back/Info/Menu)
  • Display the current remote configuration in an help screen according to the context the help screen have been displayed
  • Quick implementation of new device without to have to build mythtv from scratch


This is the way I think I could implement every thing without disturbance:

  1. Move all the code for key binding in MythInputManager especially the SQL statement which are currently in MythMainWindow and in keybindings.cpp in mythfrontend. Are they are tightly link together then should not be apart
  2. Implement a simple MythInputInterface that can load dynamically some MythInputInterface implementation.
  3. Change AppleRemote, Lirc and other to implement this interface. QKeyEvent would still be use at this stage
  4. add MythInputEvent class
  5. Find a way to make keyPressEvent(QKeyEvent * ) and keyPressEvent(MythInputEvent *) works together
  6. remove the need to create some QKeyEvent to trigger an action by implementing MythActionEvent
  7. Change MythControl to work with MythInputEvent instead of QKeyEvent
  8. Slowly remove the need for keyPressEvent(QKeyEvent * )
  9. Take a rest and relax

Attachments (2)

mythinputinterface-2011-09-21.diff.gz (32.1 KB) - added by Xavier Hervy <xavier.hervy@…> 11 years ago.
mythinputevent-2011-10-18.diff (21.9 KB) - added by Xavier Hervy <xavier.hervy@…> 11 years ago.

Download all attachments as: .zip

Change History (12)

Changed 11 years ago by Xavier Hervy <xavier.hervy@…>

Changed 11 years ago by Xavier Hervy <xavier.hervy@…>

comment:1 Changed 11 years ago by Xavier Hervy <xavier.hervy@…>

I upload a much simpler design in mythinputevent-2011-10-18.diff: It does not create plugin for input see #10069 for that. In this version, mythcontrol is not included as I did not finish yet (been busy with frontend setup) and the diff file have been edited by hand to remove all the changes which are not relevant to this patch. In an other word I will do a correct patch when it will be all done. In the meantime, comment are welcome.

This patch add a new class called MythInputEvent?, this class inherit from QKeyEvent for backward compatibility, which mean I did not need to modify every keyPressEvent(QKeyEvent *e) for each UI class.

The MythInputEvent? add three new accessors inputName, remoteName and buttonName

When the method TranslateKeyPress? is called, if the QKeyEvent is a MythInputEvent?, a new method is called instead: TranslateKeyPress?(const QString &context,

MythInputEvent? *e, QStringList &actions, bool allowJumps)

This method is responsible to translate a MythInputEvent? to an action list in a similar fashion as QKeyEvent is translated into actions If this called failed, the previous method is use instead. (backward compatibility)

The inputName (say lirc), the remoteName (PVR-150) and Button name (Play) are save in the keybindings and jumppoint tables therefor 3 new fields ahve been create in those.

As an exemple and test, I modified lirc.cpp to produce MythInputEvent? instead of MythLircKeyCodeEvent? in two configurations:

  • When the lirc key is not translatable to QKeyEvent
  • when the .lircrc have not been found

comment:2 Changed 10 years ago by stuartm

Milestone: unknown0.26

comment:3 Changed 10 years ago by Kenni Lund [kenni a kelu dot dk]

Milestone: 0.260.27

comment:4 Changed 9 years ago by paulh

Milestone: 0.270.28

comment:5 Changed 6 years ago by Stuart Auchterlonie

Milestone: 0.280.29

Moving to 0.29

comment:6 Changed 6 years ago by Stuart Auchterlonie

Milestone: 0.2929.0

Milestone renamed

comment:7 Changed 5 years ago by Stuart Auchterlonie

Milestone: 29.029.1

comment:8 Changed 5 years ago by Stuart Auchterlonie


Moving remaining open tickets to 0.28.2 milestone

comment:9 Changed 5 years ago by Stuart Auchterlonie


Moving remaining open tickets to 29.2 milestone

comment:10 Changed 4 months ago by Stuart Auchterlonie

Resolution: Trac EOL
Status: newclosed

We have moved all bug tracking to github [1]

If you continue to have this issue, please open a new issue at github, referencing this ticket.

[1] -

Note: See TracTickets for help on using tickets.