On Feb 13, 2008 12:40 PM, MythTV <<a href="mailto:mythtv@cvs.mythtv.org">mythtv@cvs.mythtv.org</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
#4658: Lirc Improvment<br>-------------------------+--------------------------------------------------<br> Reporter: xavier | Owner: ijr<br> Type: enhancement | Status: new<br> Priority: minor | Milestone: unknown<br>
Component: mythtv | Version: unknown<br> Severity: medium | Mlocked: 0<br>-------------------------+--------------------------------------------------<br> Hi,<br><br> I am trying to improve lirc support in myth:<br>
My goal is :<br> - to be able to configure lirc without simulating QKeyEvent<br> - To get ride of the .lircrc and use the socket which should make easier<br> to configure (without restarting mythtv)<br> - to be able to program each remote control differently (as long as their<br>
are not the same make)<br> - Potentially each Input would be configurable individually<br><br> This patch is just a draft.<br> I implement the MythInputEvent as well as the child class MythLircEvent<br> (future class could be MythKeyEvent,MythKeyExternalEvent...)<br>
I create the inputEvent method only in mythmenuthemed as a example.<br><br> If well written, this patch could also make MythMainWindow unaware of the<br> different kinds of InputEvent (remove some ifdef ...).<br><br> If adopted, Widget would have to use inputEvent methods to handle it and<br>
get rid of the keyPressEvent<br><br> I still need :<br> - to create the MythKeyEvent (which will encapsulate a QKeyEvent) and<br> redirect the main keyPressEvent to inputEvent<br> - make the jump work the same way<br> - replace my dirty mapping in keyContext by something else<br>
<br> I am facing few problem also:<br> - I am not to sure how to manage the retro compatibility, maybe by using<br> the old way if a .lircrc file is found ?<br> - To make this work, I have to replace all keyPressEvent method by<br>
inputEvent, And there is quite a lot :). Any idea to allow some kind of<br> cohabitation?<br><br> Is there a chance that such patch would be applied (when it will be<br> finished and clean of course) or do I waste my time?<br>
<br> The bz2 contain the diff file, the mythinputevent file and an example of<br> keybindings table<br><br> I did change my keybinding table too:<br> - add a column input which should include 'keyboard', 'lirc' as retrieved<br>
by MythInputEvent::getInputName<br> - replace the primary key on context,action,hostname by<br> context,action,hostname,input<br><br> I wonder if this primary key is a good idea as we could have a primary key<br> as context,action,hostname,input,keylist and have only on bindings per row<br>
(in keylist i mean). The present modele us QKeySequence which have a<br> limitation of 4 QKeyEvent, I don't this this limitation is a good idea. To<br> have only on key per keylist would simplify the parsing too.<br>
<br> No change have been done in MythControl neither, Is there any reason to<br> have MythControl as a plugin ? Would be better to have this in the core,<br> Each plugin/dialog/context could be configurable from their menu (may be<br>
in the help page). it make more sense for the user point of view and it<br> would be also easier to bind a missing key quickly without quiting what<br> the user is doing.<br><br> Any review, suggestion would be a great help.<br>
<br><br> Regards,<br> Xavier<br></blockquote></div><br>It's not clear to me what problem exists that this will fix.<br><br>Lirc works fine for me now. This looks like this could break my existing setups.<br><br>If there is a real problem that needs to be solved, I am all for that. But if it is not broken, let's not fix it. There are plenty of real problems that could use attention.<br>
<br>Tom<br>