Tk Source Code

View Ticket
Login
Ticket UUID: 499526180d6cd5ca7c02eed96c10e9d3630a807c
Title: add support for windows multimedia virtual keys
Type: RFE Version: 8.5.19, 8.6.6
Submitter: anonymous Created on: 2017-01-25 17:09:13
Subsystem: 01. Bindings Assigned To: fvogel
Priority: 5 Medium Severity: Important
Status: Closed Last Modified: 2017-03-26 15:29:17
Resolution: Fixed Closed By: fvogel
    Closed on: 2017-03-26 15:29:17
Description:
Tk is lacking support for the multimedia keys as described on
https://msdn.microsoft.com/en-us/library/windows/desktop/dd375731(v=vs.85).aspx

VK_VOLUME_DOWN 0xAE Volume Down key
VK_VOLUME_UP 0xAF Volume Up key
VK_MEDIA_NEXT_TRACK 0xB0 Next Track key
VK_MEDIA_PREV_TRACK 0xB1 Previous Track key
VK_MEDIA_STOP 0xB2 Stop Media key
VK_MEDIA_PLAY_PAUSE 0xB3 Play/Pause Media key

Linux supports these as eg. XF86AudioPlay XF86AudioPrev XF86AudioNext.

I understand that some changes are required to win/tkWinKey.c and probably the included X11 headers.  I would be willing to work on this and supply a patch but would need someone with knowledge of the keybinding process on windows to assist.
User Comments: fvogel added on 2017-03-26 15:29:17:
TIP 464 merged to core-8-5-branch, core-8-6-branch and trunk, after discussion and vote by the TCT.

Closing now, thanks to all!

fvogel added on 2017-02-27 04:57:33:
TIP #464 was finally issued on 22/02/17.

ralfixx added on 2017-02-06 08:39:52:
TIP seems to be in stall.  I had sent the following, but received no reply yet.
(Email addresses obscured but you get the idea).

From: Ralf Fassel <xxx>
To: "Donal K. Fellows" donal dot k dot fellows at manchester dot ac dot uk
Subject: Tk: support for multimedia Keys on Windows
Date: Sat, 28 Jan 2017 17:34:08 +0100

TIP:           ???
Title:         Support for multimedia Keys on Windows
Version:       $Revision$
Author:        Ralf Fassel <xxx>
State:         Draft
Type:          Project
Tcl-Version:   8.5 8.6
Vote:          Pending
Created:       28-Jan-2017
Post-History:

~ Abstract

Tk is lacking support for the multimedia keys as described on
https://msdn.microsoft.com/en-us/library/windows/desktop/dd375731(v=vs.85).aspx

VK_VOLUME_DOWN 0xAE Volume Down key
VK_VOLUME_UP 0xAF Volume Up key
VK_MEDIA_NEXT_TRACK 0xB0 Next Track key
VK_MEDIA_PREV_TRACK 0xB1 Previous Track key
VK_MEDIA_STOP 0xB2 Stop Media key
VK_MEDIA_PLAY_PAUSE 0xB3 Play/Pause Media key

Linux supports these as eg. XF86AudioPlay XF86AudioPrev XF86AudioNext.

~ Implementation

The support can be added by extending some keymapping lookup tables in Tk.

A Ticket already exists with a proposed patch:

Ticket UUID: 	499526180d6cd5ca7c02eed96c10e9d3630a807c

http://core.tcl.tk/tk/tktview/499526180d6cd5ca7c02eed96c10e9d3630a807c

fvogel also created a branch on

http://core.tcl.tk/tk/timeline?r=rfe-499526180d

~ Copyright

This document has been placed in the public domain.

fvogel added on 2017-02-05 16:26:04:
Is the TIP writing still ongoing or is it stalled? May I help perhaps?

fvogel added on 2017-01-29 17:12:52:

OK I trust you on this and have followed your advice: [5d73e53a5d]


ralfixx added on 2017-01-29 15:35:00:
I don't think auto-regeneration would work, since the ks_names.h table is used to set up a bidirectional hashtable mapping between the char-*-keysym and the integer in generic/tkBind.c

But the same integers occur for multiple keysyms in keysymdefs.h, eg 

#define XK_Greek_LAMDA                                 0x7cb
#define XK_Greek_LAMBDA                                0x7cb

#define XK_Greek_lamda                                 0x7eb
#define XK_Greek_lambda                                0x7eb

#define XK_Cyrillic_DZHE                               0x6bf
#define XK_Serbian_DZE                                 0x6bf  /* deprecated */

(i.e. different spelling of LAMDA/LAMBDA etc)
I'm haven't checked what the effect would be on the hashtables, but could imagine overwriting of entries, or missing keysyms in the tables.

I would instead add a comment to keep the files in sync manually.

fvogel added on 2017-01-29 15:07:28:
Second thoughts.

I'm wondering if the TIP could/should not address the regeneration of ks_names.h from keysymdefs.h, in addition to the new keysyms you propose. Would be the occasion to do it, isn't it?

fvogel added on 2017-01-29 15:02:13:
Thanks for the awk script. COuld turn to be uselful some day.

I have removed the misleading comment on top of ks_names.h

ralfixx added on 2017-01-28 16:24:13:
About ks_names.h: I saw that comment, too, but it seems to me it is some left-over from where the file originally came from.  

- There is no INCLUDESRC in any file of the Tk distribution, 
- there is no rule to regenerate it in any of the Makefiles, 
- and the only keysymdefs.h is in xlib/X11/keysymdefs.h, but not all entries in keysymdefs.h appear in ks_names.h

So I doubt that the ks_names.h in the current distribution was in fact auto-generated from that keysymdef.h file.

A simple awk script may be used to regenerate the complete contents:

awk '/^#define *XK_/ {print "{ \"" substr($2,4) "\", " $3 " },"}' xlib/X11/keysymdef.h

but as you said, this would be another harmlessly looking change :-)

I will submit a starting TIP to Donal.

fvogel added on 2017-01-28 15:44:11:

Branch rfe-499526180d now created to host your patch.


fvogel added on 2017-01-28 15:37:12:
About file ks_names.h: on top of this file there is a comment saying it's a generated file that should not be edited. Do you know how to re-generate this file?

fvogel added on 2017-01-28 15:10:50:
Nevertheless I believe this should be TIPped. Be it for reaching agreement on the binding names, for gathering comments about the macosx side of things, and so on. Been bitten by such kind of harmless, obvious, small, useful changes numerous times. Let's just write a non-controversial TIP (could you start it? I would then sponsor it).

Further than the patch, this probably needs new tests and certainly documentation, too. I can create a fossil branch with your patch as a starting point.

ralfixx added on 2017-01-28 14:38:55:
- new feature? I would say no, since it simply adds support for bind(n) for some more keys on current keyboards. It is not even new code, just some more entries in already existing keymapping tables.
- it is not a bug fix (Type: RFE)
- the patch targets Windows only, since I don't have access to MacOS and don't know whether these keys exist on a Mac keyboard at all and how they are reported to Tk if they exist. Linux already supports the Multimedia keys.

fvogel added on 2017-01-28 14:01:31:
I believe this deserves a TIP, and should target 8.7 since it's a new feature and not a bugfix (or is it a bugfix?).

Does this target Windows only?

ralfixx added on 2017-01-26 11:07:34:
Ok, wasn't that hard after all to get a first version working.

See patches attached for tk 8.5 and tk 8.6 (diff is a "const" keyword in tkWinKey.c, otherwise they're identical).

I have re-used the Linux Keysyms starting with XF86, so I can use the same bindings on Linux as on Windows.
  bind . <XF86AudioPlay> ...

ralfixx added on 2017-01-26 08:43:47:
Please note that my point is not Windows intercepting the media keys.
The media keys _are_ delivered to Tcl/Tk already, I just cannot bind them by _name_.

Here is a simple dump from wish:

 bind . <Key> {puts stderr "%%K %K %%N %N %%k %k"}

Keys pressed in order
 VK_MEDIA_PLAY_PAUSE
 VK_MEDIA_PREV_TRACK
 VK_MEDIA_NEXT_TRACK
 VK_VOLUME_UP
 VK_VOLUME_DOWN

Linux:
 %K XF86AudioPlay %N 269025044 %k 172
 %K XF86AudioPrev %N 269025046 %k 173
 %K XF86AudioNext %N 269025047 %k 171
 %K XF86AudioRaiseVolume %N 269025043 %k 123
 %K XF86AudioLowerVolume %N 269025041 %k 122

Windows:
 %K ?? %N 0 %k 179
 %K ?? %N 0 %k 177
 %K ?? %N 0 %k 176
 %K ?? %N 0 %k 175
 %K ?? %N 0 %k 174

(Note that the keycodes %k are different.)

My goal is to avoid a [bind <Key>] since that seems overkill to me. I'd rather do [bind <XF86AudioPrev>] etc (ideally some platform independent keysym).

bll added on 2017-01-25 17:35:56:
The multi media keys are not so simple.

In some cases, Windows will intercept these key presses and they are not readily available to the application.

See also: http://kodi.wiki/view/Using_a_Microsoft_remote_control_in_Windows

I haven't researched the multi media keys in a long time, and I remember the remote issues better.  I don't think I ever found a way for windows to not 
intercept these keys without a lot of work.

Try this utility and see what you get back from the multi media keys.  Try it on different systems.

https://sourceforge.net/projects/xbmcmce/files/?source=navbar

Attachments: