Some Windows Key Combinations Don't Work

[algotastic]

I'm not sure what the intended experience is for Windows keys combinations, but I've noticed many of the Windows + \ commands don't work while a couple of them do work, seemingly no matter what layout I have set. Some Windows commands that appear to work are Win + L (Lock) and Win (+ Shift) + \. Win + L works if I use the L key on my keyboard, not the keymapping from EPKL.

In particular, I'd like at least Win + P (Project, for changing monitor output) and Win + Shift + S (Snip & Sketch) to work as these are two commands that I use very frequently which don't have alternate ways that I know of to access their functions, and I don't want to have to close EPKL every time I need to use them.

When I press the RWin key alone, in the AHK key history I see what I would expect:

VK	SC	Type	Up/Dn	Elapsed	Key	Window
5C	15C		d	1.53	RWin
5C	15C		u	0.06	RWin

When I press the RWin + L combination (using Colemak\Cmk-eD_ANS_Curl), which works correctly, I see a strange series of keys:

VK	SC	Type	Up/Dn	Elapsed	Key	Window
5C	15C		d	4.44	RWin
4C	026	h	d	0.14	l
5B	15B	i	d	0.01	LWin
A2	01D	i	d	0.00	LControl
A2	01D	i	u	0.00	LControl
5C	15C	i	u	0.00	RWin
49	017	i	d	0.00	i
49	017	i	u	0.00	i
5B	15B	i	u	0.02	LWin
A0	02A	i	u	4.31	LShift	Windows Default Lock Screen
A2	01D	i	u	0.01	LControl
A4	038	i	u	0.02	LAlt
5B	15B	i	u	0.01	LWin
A1	136	i	u	0.02	RShift
A3	11D	i	u	0.02	RControl
A5	138	i	u	0.01	RAlt
5C	15C	i	u	0.02	RWin

When I press the RWin + P combination (using Colemak\Cmk-eD_ANS_Curl), which does not work, I see a similar series of keys:

VK	SC	Type	Up/Dn	Elapsed	Key	Window
5C	15C		d	3.66	RWin
50	019	h	d	0.22	p
5B	15B	i	d	0.02	LWin
A2	01D	i	d	0.00	LControl
A2	01D	i	u	0.00	LControl
5C	15C	i	u	0.00	RWin
BA	027	i	d	0.00	;
BA	027	i	u	0.00	;
5B	15B	i	u	0.02	LWin
A2	01D	i	d	0.00	LControl
5C	15C	i	d	0.00	RWin
A2	01D	i	u	0.00	LControl
50	019	h	u	0.05	p
5C	15C		u	0.26	RWin
A2	01D	i	d	0.00	LControl
A2	01D	i	u	0.00	LControl

Please let me know if you need more examples. I would be happy to help work on this, but I first need to understand the intended experience and how the Windows key mappings are controlled within EPKL.

[DreymaR]

I've tested your combos such as Win+L and Win+P and they work just fine on EPKL with both ENG US and other underlying OS layouts. You don't use a custom KLC installed layout, by any chance?

In the first output example you see a cleanup after 4 s idle time, that's just a little precaution I have against stuck modifiers. It may not be strictly necessary for most, but it shouldn't hurt either.

Here's my Key History

VK	SC	Type	Up/Dn	Elapsed	Key	Window
5B	15B		d	0.45	LWin
52	013	h	d	0.31	r
50	019	i	d	0.02	p
50	019	i	u	0.00	p
5B	15B	i	u	0.01	LWin
A2	01D	i	d	0.00	LControl
5B	15B	i	d	0.00	LWin
A2	01D	i	u	0.00	LControl
52	013	h	u	0.05	r
5B	15B		u	0.41	LWin	Project
A2	01D	i	d	0.00	LControl
A2	01D	i	u	0.00	LControl

How did you paste the key history in table format, by the way? I ended up doing it manually. ᏊᵕꈊᵕᏊ

Yeah, there's something strange going on with the virtual LWin+LCtrl down then up. But it doesn't break the functionality.

Why your Win+L works when an i is sent is strange. As you can see, Win+P works with the QWERTY R key for me, being mapped to P.

[algotastic]

How did you paste the key history in table format, by the way? I ended up doing it manually. ᏊᵕꈊᵕᏊ

I also did it manually -- I used VS Code to make use of the multiple cursor functionality to insert the pipes between the columns.

You don't use a custom KLC installed layout, by any chance?

I did download and install the Colemak layouts from colemak.com a while back, but I've had them disabled (and reverted the remaps) ever since I downloaded EPKL. Are those KLC layouts, or are you referring to something different?

[DreymaR]

Yes, the standard Colemak installs are made with the MSKLC program from Microsoft. So, basically... I've no idea then why your EPKL would behave differently from mine? I suppose you're using the latest release, v1-2-0?

Looking at your key history, turns out that your physical L key still being held down when RWin was released can trigger the Windows Lock screen. It's a bit strange that lock screen: I could activate it with both the physical QWERTY L key and the QWERTY I key that's remapped to L in Colemak-Wide. That's how Microsoft implemented it I guess. The same is not true for Win+P which only works with the key I've remapped to P – the QWERTY R key. So there's that mystery explained I guess?

[algotastic]

I just discovered something interesting. I recently switched to a Kinesis Advantage 2 which only has a right Windows key, so I picked up my old keyboard and discovered this: It appears RWin + P does not work, whereas LWin + P does work. Is there intentionally a difference in functionality between the two Windows keys?

[DreymaR]

That's regardless of EPKL? Sloppy programming from Microsoft's side it would appear?

[algotastic]

No, without EPKL running, both Windows keys perform the same.

[dogbertai]

I believe I have the same problem with Win Key Combinations.

In normal Windows: If you hold the Win key and press a number corresponding to a task with multiple windows (like explorer or a web browser), you can press the number repeatedly to switch between windows of that specific application. e.g. Win + 1,1,1,1 will switch to the 4th explorer window if I have at least 4 open. The same goes for Win + P to select a projection option. Win + P,P,P. The selection doesn't take effect until you release Win key.

With Colemak VK this behavior still works OK.

With Colemak eD this behavior does NOT work. It seems that it releases the Win key immediately.

I am using Windows 10 Pro x64 20H2, EPKL v1.2.0. Windows is using the US QWERTY layout.

Colemak\Cmk-VK_ANS_CurlAWideSym Attempting to press Win + 1,1, release

5B  15B     d   6.95    LWin            <Non Explorer>
31  002     d   0.39    1               
31  002     u   0.13    1               
31  002     d   0.20    1               
31  002     u   0.16    1               
5B  15B     u   0.48    LWin            <Second Explorer Window>

Colemak\Cmk-eD_ANS_CurlAWideSym Attempting to press Win + 1,1, release

5B  15B     d   6.48    LWin            
5B  15B     d   0.52    LWin            
5B  15B     d   0.03    LWin            
5B  15B     d   0.03    LWin            
5B  15B     d   0.03    LWin            
5B  15B     d   0.03    LWin            
5B  15B     d   0.05    LWin            
31  002 h   d   0.02    1               
31  002 i   d   0.01    1               
31  002 i   u   0.00    1               
5B  15B i   u   0.05    LWin            <First explorer window><I did not release it here>
31  002 h   u   0.09    1               
31  002 h   d   1.66    1               
31  002 i   d   0.02    1               
31  002 i   u   0.00    1               
31  002 h   u   0.11    1               
5B  15B     u   1.16    LWin            <I released it here><It shouldn't be possible to release twice>
A2  01D i   d   0.00    LControl        <I didn't press this>
A2  01D i   u   0.00    LControl        

I thought I read somewhere that EPKL or PKL intercepts the Windows key and resends it? I could be wrong.

Another note: I think it should be documented in Known Issues that Win + L is intercepted by Windows and can't be changed; likewise for Ctrl+Alt+Del. For me, it's annoying because Win + E to launch explorer is one of my most used combos, but in Colemak E is on the L key!

[DreymaR]

Thanks for the update! You're right, I'll add this caveat to the EPKL README.

VK remapping just resends the key as it is, so it should indeed be less impactful. An eD/state remapping will send input events instead of key presses, so it may work differently with regard to such combos. Short of a rather substantal rewrite there's little I can do about that. If you don't need the AltGr remapping for any one key, you can make it a VK mapping instead in your layout.ini file.

I'll also add this to the Deadkey file, so using "MoDK" Ext-tap you'll be able to tap Extend then w for the Explorer. There's also one on {AltGr+Ext-tap,e} but I think that's less convenient in use.

<w>     = α#e    ; w -> Win+e – Open Windows Explorer
<f>     = α^f    ; a -> Ctrl+f – Find

[dogbertai]

Currently keys are defined like this:
;; SC = VKEY        CStat   Base    Shift   Ctrl    AltGr   AGrSh   ;   SGCap   SGCSh
QW_1  = 1           0       1       !       --      @323    ¡       ; SC002: US 1! - dk_DotBelow

What if instead '--' meant treat as virtual key for that shift state? And send those with {Blind}
QW_1  = 1           0       --      --      --      @323    ¡       ; SC002: US 1! - dk_DotBelow
would be equivalent, and allow for Windows or Alt key modifiers.

If someone wanted to not use {Blind} and force it, they would use the old:
QW_1  = 1           0       1       !       ^1      @323    ¡       ; SC002: US 1! - dk_DotBelow
And if they wanted to go crazy swapping shift
QW_1  = 1           0       !       1       ^1      @323    ¡       ; SC002: US 1! - dk_DotBelow

[DreymaR]

Interesting idea. For compatibility and sanity, I don't think I should change the meaning of -- as it can still be useful to define a shift state as non-outputting. But having a way to make the shift state simply send the VKey is a good idea. The Send routine in EPKL is quite complex as I'm sure you can see in the code, but I'll look into it.

[DreymaR]

@dogbertai I've followed your suggestion! A ## state mapping will now blind send the key's VK code. I've changed the Colemak-eD BaseLayout to use this for the number keys by default, so Win+Number should work now. You may make and use your own BaseLayout copy that has ## mappings for all keys if you wish, but be aware that the underlying OS layout mappings will be used then. So if I want a ## mapping for Shift+2 to allow Win+Shift+2 to work as it should, then with, say, a Norwegian layout underneath Shift+2 will send a quote symbol instead of the @ sign I want it to send. Therefore, I've not ##-mapped the shifted states by default. If you use a US layout or similar, you might want every key's state 0/1 to be ##-mapped. Maybe I should include a BaseLayout with that feature...?

To get this change, download the latest EPKL commit and compile epkl.exe using the .bat file included. I will release a new version shortly.

[dogbertai]

I am not completely sure about my idea. I am still bothered that the Ctrl shift-state has a different interpretation of -- than the other shift states. It also overrides Ctrl+Shift. It doesn't solve the issue for international layouts. Maybe I'm just scope-creeping this issue.

I will download it and try it out.

BTW, you can use git branches to test out new features before merging them into master.

---

• Another idea is that all states not covered by the shift states specified in config should send the blind virtual key specified in the first (VKEY) column.
  • This would be anything with Win key (Win, Win Shit, Win Ctrl, Win Ctrl Shift, Win Alt, etc.) and anything with Alt key (Alt, Alt Shift, Alt Ctrl, etc.).
    • The ini key mapping would only cover (nomod, Shift, Ctrl, Ctrl+Shift (implicitly), AltGR, AltGR+Shift).
  • Currently, Win or Alt send the Base key, but there really aren't any Win or Alt commands that use international symbols.
    • For example, currently, intending to use Alt-F by pressing Alt-ф in the Russian layout just sends the character ф itself. There is no Alt-ф used by any application.
  • For Norwegian, this means that pressing Win+Shift+2 on the keyboard will be sent as Win+Shift+2, and not Win+"
    • At least with number keys, commands are usually interpreted psychologically as Ctrl+Shift+# and not Ctrl+symbol.
    • Since we're running on top of the built-in Windows language and layout, users would already be used to this.
    • I think this is OK. Documentation is important.

[DreymaR]

The Ctrl state doesn't have a different interpretation than other states. A -- mapping means that this state doesn't produce output, like with the MSKLC -1 mapping. This is inherited from MSKLC in which there's usually a column for state 2 (Ctrl) but none for state 3 (Ctrl+Shfit). You could map state 3 if you wish, by specifying its existence as a column in the layout.ini file. This would be quite untraditional.

Alt and Win are not Shift states but special keys. Their implementation in Windows is a bit of a nightmare, to be honest. Ctrl is and isn't, sort of: It's mostly a special key but in rare cases it's also used as Shift state 2 for output; the best-known example is how Ctrl+[ = Esc in most layouts, by tradition.

I'm not sure there is an actual Alt+F or whether Windows interprets it as Alt then F. At any rate, that isn't handled by the layout.

I don't know what you mean overrides Ctrl+Shift? Can you give an example? Using EPKL, both Ctrl+Z and Ctrl+Shift+Z function as expected for me. This also holds true when using a script layout like Greek.

[dogbertai]

I guess I don't know what "doesn't produce output" means.

If I have

QW_E  = F           1       --      F       --      ’       ”       ; SC012: QW eE
QW_R  = P           1       p       P       F       π       ¶       ; SC013: QW rR

Pressing keyboard e does nothing. Ctrl+e opens the search. Even though they both have --, one does nothing, one does Ctrl+VKEY

Ctrl+Shift+e opens the VSCode search sidebar. Ctrl+Shift+r types F Even though there is no CtrlShift column, it uses the Ctrl column, not VKEY nor Base nor Shift. There is no Win or Alt column, yet those use the Base column.

This is mainly concerning the intuitiveness of the config file format. If it's the same as the MSKLC format, fine. But coming from someone who is unfamiliar with the MSKLC format, it looks strange to me.

[DreymaR]

It means that the layout does nothing with the key event. If you press e with your setup, the layout does nothing. As I understand it, the key event then falls through to any other Windows entities interested. Usually, no entities pick up such an event, so nothing happens. (I'm not 100% sure on this point.)

If you press Ctrl+[ with a definition for it as in my Cmk-eD_BaseLayout, the layout produces an output for the corresponding event like an active Windows MSKLC layout would do. In that case, Esc is sent. The event is then used up and nothing else happens. QW_LB = vc_LB 4 [ { &Esc å Å ; SC01a: US [{

If you press Ctrl+f, the layout does nothing with that key event as specified by the -- entry. The event falls through and is used by lower-level program or system hooks that decide what to do with it. A common result is opening a Find dialog.

EPKL in itself makes no fundamental difference between these cases. The difference is a result of processes happening outside the scope of a keyboard layout.

If you want to discuss layout and input chain technicalities instead of EPKL, please take time to study these some more first. I don't have time for a full course on the subject.

[dogbertai]

I replaced all Base and Shift with ## in my BaseLayout_Cmk-eD.ini. Tested and seems to be working. Win+1,1,1 works. Win+P works. I never had a problem with snipping. Win+Shift+S works.

Thanks for the fix.