Thomas Hess

Results 86 comments of Thomas Hess

@deragon You can choose between a light and a dark theme in the settings. (Qt GUI updates instantly on saving the settings, the GTK GUI currently requires an application restart.)...

This is how the dark icon looks on a light theme: ![notification_area](https://user-images.githubusercontent.com/2143820/75727222-b6f48b00-5ce4-11ea-908d-a77aab65c87f.png) So the essence of this is that installing via `python3 setup.py install` installs the icons into the wrong...

@ineuw Never seen them before. I think they are part of the 'Mint-Y' icon theme. Those are definitely coming from a third party.

@deragon The white, black and red _`A`_ icons are SVGs named `autokey-status*.svg` (* is a wildcard) (We only ship the main program icon as a PNG, mostly because of #160)...

It does work natively with AutoKey. But you may run into an issue that your receiving application discards programmatically generated key presses. (For details see #132.) I tried sending `XF86AudioRaiseVolume`...

About which program causes the key press event to be handled: I’m not sure. The application (e.g. the volume meter) might listen on key presses on its own like autokey...

@jeebak This looks like a really clean solution. (But it only works for controlling pulseaudio directly.) Instead of going the route `keyboard` → `AutoKey` → `emulated keyboard` → `some other...

This use case is unsupported. AutoKey reads it’s input on a high level API (XRecord), where it can’t distinguish between the original event source. Changing how AutoKey reads the keyboard...

I tried to reproduce it and failed. - Tried both autokey-gtk and autokey-qt. - Reduced my system CPU clock speed to (the minimum of) 800MHz. - Tried local text editor...

@ronjouch Thank you for checking back on this. So this looks like it is indeed a performance issue in the target application. I added some delays to the key send...