Ability to use the Win key to assign a specific IDE function

[flowCRANE]

Already now, Lazarus not only allows you to set shortcuts that are reserved by the system and will never work as intended by the user (e.g. Alt+Tab or Ctrl+Alt+Del), but it also does not inform the user about potential problems while setting these shortcuts.

You're going to use that as a rationale to justify using the winkey in your app ?

Lazarus is not my app.

Regardless of whether or not support for the Win key for IDE shortcuts is added, the user already has the ability to break the IDE in many ways. That's why I'm pointing out that avoiding Win key support so that the user doesn't experience problems doesn't sound very wise.

[Thaddy]

It is just only a matter of the constants being declared. 

[flowCRANE]

So do it! Do it now!

In case a decision is made not to add official support for the Win key, I will ask you for help — we will try to modify my Lazarus installation so that I could use this key and assign it to some IDE functions. The Lazarus code base is huge and I'm not a contributor, so any help would be greatly appreciated.

[Thaddy]

Code: Pascal  [Select][+][-]

1. const
2.   VK_LWIN = $5B;
3.   VK_RWIN = $5C;

You can do it yourself.
BTW they are declared in windows.

Code: Pascal  [Select][+][-]

1. uses
2.   Windows, Classes, SysUtils, Forms, Controls, Graphics, Dialogs, StdCtrls, ActnList;
3.  
4. type
5.  
6.   { TForm1 }
7.  
8.   TForm1 = class(TForm)
9.     Action1: TAction;
10.     ActionList1: TActionList;
11.   private
12.     procedure WMKeyDown(var Msg: TWMKeyDown); message WM_KEYDOWN;
13.   public
14.  
15.   end;
16.  
17. var
18.   Form1: TForm1;
19.  
20. implementation
21.  
22. {$R *.lfm}
23.  
24. { TForm1 }
25.  
26. procedure TForm1.WMKeyDown(var Msg: TWMKeyDown);
27. begin
28.   case Msg.CharCode of
29.     VK_LWIN: ShowMessage('Left Windows Key Pressed');
30.     VK_RWIN: ShowMessage('Right Windows Key Pressed');
31.   end;
32.   inherited;
33. end;
34. end.

[Thaddy]

Console example that prevents the win key being passed to the OS after all:

Code: Pascal  [Select][+][-]

1. program GlobalHookExample;
2. {$mode objfpc}{$H+}
3. uses
4.   jwaWindows;
5.  
6. var
7.   hhkLowLevelKybd: HHOOK;
8.  
9. function LowLevelKeyboardProc(nCode: Integer; wParam: WPARAM; lParam: LPARAM): LRESULT; stdcall;
10. var
11.   p: PKBDLLHOOKSTRUCT;
12. begin
13.   if (nCode = HC_ACTION) then
14.   begin
15.     p := PKBDLLHOOKSTRUCT(lParam);
16.     if (wParam = WM_KEYDOWN) and ((p^.vkCode = Ord('K')) and
17.        ((GetAsyncKeyState(VK_LWIN) and $8000) <> 0))then
18.     begin
19.       writeln('Windows + K key combination pressed!');
20.       result := 1;// prevent windows from using the win+k itself
21.       exit;
22.     end;
23.   end;
24.   Result := CallNextHookEx(hhkLowLevelKybd, nCode, wParam, lParam);
25. end;
26.  
27. procedure SetHook;
28. begin
29.   hhkLowLevelKybd := SetWindowsHookEx(WH_KEYBOARD_LL, @LowLevelKeyboardProc, HInstance, 0);
30.   if hhkLowLevelKybd = 0 then
31.     writeln('Failed to set hook!');
32. end;
33.  
34. procedure Unhook;
35. begin
36.   if not UnhookWindowsHookEx(hhkLowLevelKybd) then
37.    writeln('Failed to unhook!');
38. end;
39.  
40. begin
41.   SetHook;
42.   MessageBox(0, 'Press OK to unhook and exit.'#13#10#13#10'Don''t kill me, leave open'#13#10#13#10'Just close me when you are finished', 'Global Hook Example', MB_OK);
43.   Unhook;
44. end.

Do not close the messagebox until you want to stop the program.

[Thaddy]

And a GUI version. Needs a form and a memo.

Code: Pascal  [Select][+][-]

1. unit Unit1;
2.  
3. {$mode objfpc}{$H+}
4.  
5. interface
6.  
7. uses
8.   jwaWindows,Classes, SysUtils, Forms, Controls, Graphics, Dialogs, StdCtrls;
9.  
10. type
11.  
12.   { TForm1 }
13.  
14.   TForm1 = class(TForm)
15.     Memo1: TMemo;
16.     procedure FormCreate(Sender: TObject);
17.   private
18.  
19.   public
20.  
21.   end;
22.  
23. var
24.   Form1: TForm1;
25.   hhkLowLevelKybd: HHOOK;
26.  
27.  
28. implementation
29. {$R *.lfm}
30. function LowLevelKeyboardProc(nCode: Integer; wParam: WPARAM; lParam: LPARAM): LRESULT; stdcall;
31. var
32.   p: PKBDLLHOOKSTRUCT;
33. begin
34.   if (nCode = HC_ACTION) then
35.   begin
36.     p := PKBDLLHOOKSTRUCT(lParam);
37.     if (wParam = WM_KEYDOWN) and ((p^.vkCode = Ord('K')) and
38.         ((GetAsyncKeyState(VK_LWIN) and $8000) <> 0)) and
39.         ((GetAsyncKeyState(VK_SHIFT) and $8000) <> 0)
40.     then
41.     begin
42.       form1.memo1.lines.add('Windows + shift + K key combination pressed!');
43.       result := 1;
44.       exit;
45.     end;
46.   end;
47.   Result := CallNextHookEx(hhkLowLevelKybd, nCode, wParam, lParam);
48. end;
49.  
50. procedure SetHook;
51. begin
52.   hhkLowLevelKybd := SetWindowsHookEx(WH_KEYBOARD_LL, @LowLevelKeyboardProc, HInstance, 0);
53.   if hhkLowLevelKybd = 0 then
54.     form1.memo1.lines.add('Failed to set hook!');
55. end;
56.  
57. procedure Unhook;
58. begin
59.   if not UnhookWindowsHookEx(hhkLowLevelKybd) then
60.    form1.Memo1.lines.add('Failed to unhook!');
61. end;
62.  
63. { TForm1 }
64.  
65. procedure TForm1.FormCreate(Sender: TObject);
66. begin
67.   Caption := 'Capture the Windows key';
68.   memo1.clear;
69.   memo1.lines.add('Installed a global hook for Windows key + shift + K');
70. end;
71.  
72. initialization
73.   sethook;
74. finalization
75.   unhook;
76. end.

Note that both the last programs prevent Windows to use the particular key combination while your app is running.
I noticed that the win+shift + <any key> works best, since the OS does not seem to use that, so you can integrate it with that provision.

[n7800]

I also think that it is worth implementing. Since the user assigns the combinations themselves, they are responsible for it. As already mentioned, conflicts can also arise with "regular" modifiers. Compatibility are important only for default shortcuts.

Of course, the IDE should warn the user about possible limitations, but not prohibit their use. By the way, it would be more cross-platform to call this key [Meta] instead of [Win].

The good news is that, AFAICS in the code, the IDE handles all modifier keys equally. This means that to implement "support" for the [Meta] key, you just need to add a checkbox for it!

Even more surprising is that they already work! There is no checkbox for it, but you can click the "Grab key" button and simply press the key combination. The window will close if it catches a valid key combination (not occupied by the OS). You will not see [Meta] among the checkboxes, but when you click "OK", you will see the entered combination in the list opposite the command. After saving the options, you can make sure that it works.

The fact that the flag is not visible when entering a combination with [Meta] can be called a bug. Users simply won't see it and won't understand why the key combination (without [Meta]) doesn't work, because it wasn't in the window when saving. That's why I still made patch to make its use more "legal" and to clearly warn the user about possible problems. I also fixed a couple of small bugs. Details are in the merge request, let's see what the developers say. Personally, I've only tested on Windows so far.

[flowCRANE]

Even more surprising is that they already work! There is no checkbox for it, but you can click the "Grab key" button and simply press the key combination. The window will close if it catches a valid key combination (not occupied by the OS). You will not see [Meta] among the checkboxes, but when you click "OK", you will see the entered combination in the list opposite the command. After saving the options, you can make sure that it works.

Wait, an additional checkbox should always be visible, on every platform, so that you can select a combination with e.g. the Win key, without having to use the Grab key option. You should also remember that there is also a Find key combination option and it should also support the ability to search for combinations with the Win key.

So in short, if you are going to add this extra key, then all the options related to keys and shortcuts should respect it and fully support it (setting, finding, displaying, etc.). Please think through all cases so that the UI/UX is neat and complete.

Details are in the merge request, let's see what the developers say.

I've checked the changes and in my opinion, the proposed solution is over-engineered (that's my impression).

The fourth checkbox should always be visible and should be named according to the platform (e.g. Win on Windows, because Meta is not a valid name for a key on the keyboard and users will most likely not know which key it is). Secondly, this checkbox should be handled in the same way as the other three — it should be possible to check/uncheck it with the mouse, and the Grab Key option should automatically check/uncheck it based on the captured shortcut (without any confirmations).

[n7800]

should be named according to the platform (e.g. Win on Windows, because Meta is not a valid name for a key on the keyboard and users will most likely not know which key it is)

Sounds reasonable. I'll probably make a separate MR, since there are common functions for this, but this window uses its own function. I'll see if I can remove the duplicate code.

You should also remember that there is also a Find key combination option and it should also support the ability to search for combinations with the Win key.

So in short, if you are going to add this extra key, then all the options related to keys and shortcuts should respect it and fully support it (setting, finding, displaying, etc.). Please think through all cases so that the UI/UX is neat and complete.

OK, I think the key search window can always show this modifier. When I have time, I'll check the other uses.

Wait, an additional checkbox should always be visible, on every platform, so that you can select a combination with e.g. the Win key, without having to use the Grab key option.

This is what my patch adds. Only for the flag with [Meta] to appear, you need to check the checkbox with "confirmation".

I've checked the changes and in my opinion, the proposed solution is over-engineered (that's my impression).

The fourth checkbox should always be visible ... (without any confirmations).

That's right. Simply displaying an additional modifier requires literally a few lines (or even one). Everything else in the corresponding commit is handling all possible use cases of the confirmation checkbox... ((

I also feel offended by complicating things like that. If the developers agree to simply display this modifier, I will gladly remove the extra code.


Thanks for the feedback. When I find time, I'll do it. For now, I've marked MR as a draft.

[flowCRANE]

Ok, thanks everyone for the discussion! I have a hope that in the future I will be able to use shortcuts with the Win key.

[flowCRANE]

@n7800: I checked your proposal on Windows 10, but after making these changes Lazarus cannot be compiled because errors appear. The problem is that you are using the TShortCutGrabBox.GetDefaultShiftButtons method as static (class method), even though it is a normal method (must be called from an object, not from a class). If I make this method static, Lazarus compiles correctly, but I can't use shortcuts with the Win key.

The grab key dialog does not recognize shortcuts with the Win key at all, but if I set such a shortcut manually (by checking the Meta checkbox and selecting a key from the combobox), then such a shortcut will be accepted and saved by Lazarus, but it will not be detected by it. I have tested the combinations I care about, i.e. Win+Left/Right and Win+Shift+Left/Right, but neither is detected by the IDE.

So your merge request must wait because your patch code needs to be fixed so that Lazarus can compile correctly. Secondly, something else needs to be programmed because Lazarus doesn't see the aforementioned Win key shortcuts.

[n7800]

@n7800: I checked your proposal on Windows 10, but after making these changes Lazarus cannot be compiled because errors appear. The problem is that you are using the TShortCutGrabBox.GetDefaultShiftButtons method as static (class method), even though it is a normal method (must be called from an object, not from a class). If I make this method static, Lazarus compiles correctly, but I can't use shortcuts with the Win key.

Can I ask how exactly you checked it? There are several commits in the request, in one of them I make this method a class method.

I don't know your git skills, but a typical MR check includes (click the blue "Code" button on the MR page at the top right and select "Check out branch" for instructions):

Code: Bash  [Select][+][-]

1. git fetch "git@gitlab.com:n7800/lazarus.git" 'IDE/Options/Editor/KeyMap'
2. git checkout -b 'lazarus-IDE/Options/Editor/KeyMap' FETCH_HEAD

Or I recommend a simpler patch option - click the same blue button and select "Plain diff" to download the final patch (of all commits in MR) and apply it:

Code: Bash  [Select][+][-]

1. git apply <path-to-patch>

I have tested the combinations I care about, i.e. Win+Left/Right and Win+Shift+Left/Right, but neither is detected by the IDE.
...
Secondly, something else needs to be programmed because Lazarus doesn't see the aforementioned Win key shortcuts.

[Win+Left/Right] is used by the Windows to pin a window to half of the screen (try it on some regular window), and with [Shift] - to move a window between monitors. The OS will not allow any application to use these combinations. It is precisely about such restrictions that the checkbox should warn you ))

I hope that you will still be able to find a sufficient number of free combinations for the actions you often use. I will soon take care of the remaining tasks (display Meta as Win, and always display it in the shortcut search window) to finish MR.

[Martin_fr]

[Win+Left/Right] is used by the Windows to pin a window to half of the screen (try it on some regular window), and with [Shift] - to move a window between monitors. The OS will not allow any application to use these combinations. It is precisely about such restrictions that the checkbox should warn you ))

And that is why I personally think the Win-Key should not be an (advertised) feature in the Keymap.

If there is any (however minor) indication that the WinKey is a possible modifier for key combos, then people will expect it to work, always..., regardless of anything.

If there is some warning, it will just lead to "Why did the makers of Lazarus disable that combo?". Yes, even if it says "It's Windows doing the restriction". It's a very human feature to ignore inconvenient info...

----

Personally, I don't mind if there is some backdoor-ish hack (like something compared to a registry key to change some Windows settings).

But I wouldn't advertise adding it, because of the cost of maintenance. And because of it couldn't be guaranteed as future-safe. It may just disappear.

(Yes,  I did read that it already exists... So, for those using it, lets hope it doesn't disappear)

[flowCRANE]

Can I ask how exactly you checked it? There are several commits in the request, in one of them I make this method a class method.

I applied these changes manually, in the sources of a normal Lazaurs installation (I don't use Git or trunk). If your fixes work for you, it means I forgot something, so it's my fault. I'll try again when I have some free time, this time I'll do it more carefully, so there's no misunderstanding.

[Win+Left/Right] is used by the Windows to pin a window to half of the screen (try it on some regular window), and with [Shift] - to move a window between monitors. The OS will not allow any application to use these combinations.

However, both of these shortcuts do nothing on my computer (Win10, two monitors), so I wrongly assumed the system was not using them at all (so they are free). Again, my fault.

It is precisely about such restrictions that the checkbox should warn you ))

Indeed. It's a pity that trying to capture a shortcut reserved by the system does not provide any feedback from Lazarus, so you never know why such a shortcut cannot be used. This is where it gets a bit complicated, because since the IDE does not receive messages about the shortcut being executed, there is no way to inform the user that the executed shortcut is reserved.

To solve this and inform the user about which keyboard shortcuts are reserved, it would be good to check their list in Microsoft's documentation and provide access to this information in the IDE interface (maybe a button or link that opens documentation with a list of shortcuts and information about what the system uses them for), so that the user can familiarize themselves with this information. You can also add such link in the Grab key window.

You would have to think about how to do it properly, i.e. on the one hand, it would be possible to assign shortcuts with the Meta key, and on the other hand, so that the user has access to information about which shortcuts are reserved by the OS (i.e. so that he does not have a grudge against the IDE developers that something does not work and does not consider it a bug).

I hope that you will still be able to find a sufficient number of free combinations for the actions you often use.

There are a lot of free shortcuts with the Win key — for example, I can use the Win+Alt+Left/Right shortcut to switch between editor tabs and the Win+Alt+Up/Down shortcut to switch between code editor windows. The system does not use shortcuts with the Win+Alt+<key> keys, so this should not be a problem.

And that is why I personally think the Win-Key should not be an (advertised) feature in the Keymap.

Just because something is difficult or troublesome doesn't mean you should give up. Especially since you've made an entire IDE and adapted it to various systems, which required a lot of work and dealing with system-specific things.

If there is some warning, it will just lead to "Why did the makers of Lazarus disable that combo?". Yes, even if it says "It's Windows doing the restriction". It's a very human feature to ignore inconvenient info...

It will always be like this and there is nothing you can do about it, because if someone really doesn't want to acknowledge something, they won't. If you take care of supporting shortcuts with the Meta key, just describe their use and adapt the IDE interface to capture them, then you will do everything that needs to be done.

So if someone reads the documentation and sees in the IDE that a given shortcut cannot be used because the IDE doesn't even receive data about its pressing, but still doesn't acknowledge it and has complaints, well — you can't conclude anything more than that such a user is simply an idiot and you can do nothing with it. This applies to all IDE features, not just the shortcut capturing discussed here.

[flowCRANE]

If needed, adding support for Meta key shortcuts does not need to be implemented in the Lazarus sources — it can be in a separate package, installed optionally (like AnchorDockingDsgn for docked IDE, or metadarkstyle for the IDE's dark theme on Windows).