Hotkey Dialog implement key stroke capturing

[ewerybody]

Current Behavior

There is the "Hotkey Dialog" and you can only Click the buttons that should be captured. The (super old) "simple dialog" just offers to type the combinations.

Expected Behavior

@Cyberklabauter in #250 suggested to have the simple dialog accept actual key compbinations like Ctrl+D for instance. You actually press it and it takes exactly that key.

The “simple dialog” of the "hotkey definition dialog" could recognize and display just a hotkey combination which I press (look at A_ThisHotkey).

bla

Well, I would really like the ability to do that but I don't like the idea to have it in the simple dialog only. 🤔 In would consider the ability to see what's actually free and what not to be rather important! If you don't know you might actually already trigger something that you might not want. I mean ... there are things we could do to mitigate that and some other ideas we could have implemented:

• [ ] Make the display field a QKeySequenceEdit to accept key combinations. (this widget is not really "new" to Qt but I think I didn't have it when a2 was first created ;]) The a2ui is actually not Autohotkey itself so we could not look at A_ThisHotkey directly. Let's have a look how this Qt widget performs. We could also talk to the Qt devs if something is missing and fix it ourselves. If all breaks we can of course have an extrea Autohotkey script looking and the pressed keys on the dialog (e.g. like the coords field is done with coordinates picking)
• [ ] Unload the a2 runtime for the time the Hotkey Dialog is open to avoid triggering other a2 actions. I mean I'd try it without this first and if it's really bad we could try that.
• [ ] make the keyboard display optional?
• [ ] what else?

[Cyberklabauter]

I have no clue about Python. So I can't judge this approach (but first idea sounds worth exploring it.)

Unload the a2 runtime for the time the Hotkey Dialog is open to avoid triggering other a2 actions. I mean I'd try it without this first and if it's really bad we could try that.

In AHK you simply could use the "Suspend" command to deactivate and activate the hotkeys. Other programs still will be affected (But maybe it is good to notice that a hotkey is already in use).

[ewerybody]

Well, the UI is Qt for Python. Python using Qt is a little like AHK is using other DLLs in a more sophisticated way ;] But yeah: we should try the obvious first then look into this 2-fold approach with Autohotkey.

About Suspend: So far we thought about sending commands to the a2 runtime but it's not really in place. So we could not yet tell the runtime to go "suspend". But as a change on hotkeys would trigger a reload anyway shutting it down completely and load it up again wouldn't be too bad :)

[Cyberklabauter]

Did you try "Suspend, off" global and "Suspend, permit" in a subroutine. Never use it, but thought it should work :)

[ewerybody]

No, didn't try. I would need a way to tell the runtime to do that from the UI. And thats not the idea of a2 :) We would just shutdown the runtime and reload it.

But actually: we could add this functionality to the tray menu of a2 🤔 I mean as it was once an ac'tivAid option there. But I dunno... is that needed? I never used that functionality if I could just unload and reload.

[Cyberklabauter]

Makes sense. I rarely use "suspend" and I could probably had used pause as well in these cases. So you may leave it out until someone complains. I doubt that many users need this. Have an uncluttered menu is important as well.