Opened 15 years ago
Closed 15 years ago
#572 closed defect (fixed)
Keys doesn't handle extended keysyms correctly
| Reported by: | Owned by: | danielk | |
|---|---|---|---|
| Priority: | trivial | Milestone: | unknown |
| Component: | mythcontrols | Version: | head |
| Severity: | low | Keywords: | |
| Cc: | Ticket locked: | no |
Description (last modified by )
When setting keys, if I use a key such as XF86Audio_Play, the response dialog comes up with the message (approximate, from memory, sorry):
set key to ""?
It detects the key was pressed and seems to accept it but there is no effect.
I searched the mailling list, and there was mention that these keys are supported by Qt in 3.1. I'm using version 3.3.4.
While I'm on the subject, is there any possibility of accepting mouse buttons here as well? I have a logitech s510 media keyboard/mouse/remote, and the remote has a wheel on it that is sent as mouse wheel events.
Attachments (1)
Change History (9)
comment:1 Changed 15 years ago by
comment:2 Changed 15 years ago by
I'm attaching a patch addresses this problem in the keybinding plugin. If the user enters a key that does not have a symbolic representation in Qt, the user is told that the key is invalid, and they are unable to bind that key.
The patch also has a few minor formatting adjustments.
Changed 15 years ago by
| Attachment: | mc_reject_unrecognized_keys.diff added |
|---|
comment:3 Changed 15 years ago by
I doublechecked, and XF86AudioPlay specifically does not work, along with its related counterparts. Do you mean to include them in the group of keys that don't have symbolic representations?
comment:4 Changed 15 years ago by
| Description: | modified (diff) |
|---|---|
| Milestone: | → unknown |
| Owner: | changed from Isaac Richards to danielk |
| Priority: | minor → trivial |
| Severity: | medium → low |
| Version: | → head |
comment:5 Changed 15 years ago by
| Component: | mythtv → mythcontrols |
|---|
comment:6 Changed 15 years ago by
On my systems, the "XF86AudioPlay" keysym translates to "Media Play." I have Qt 3.3.5, but that should not make a difference, it worked with older versions. Does your system actually raise "XF86Audio_Play" (with the underscore)?
comment:7 Changed 15 years ago by
No, that was a mistake on my part. It's XF86AudioPlay. I checked and gnome at least sees it correctly, so it doesn't seem like it's a problem elsewhere. I haven't had a chance to try the patch included here, though.
This happens because Qt has no symbolic name for the key you have pressed. More common keysyms, like XF86AudioPlay, will work. I am familiar with the associated code (I wrote the plugin), so I will look into it if nobody gets to it first. This might also need to be validated in the myth code as well.
As for mouse buttons (and mosue gestures too), yes it could be done, but until the new UI is in use, I (personally) wont be putting any effort into it.