Console gets cluttered when PyKeyboardEvent._tap doesn't recognize keycodes pressed

[nikanar]

I keep getting messages like :

Unable to determine character.
Keycode: 65 KeySym 0

in my console, each time I press Shift+Space (not that I mean to, it just happens and clutters the console).

It also happens when I press Ctrl+Shift+Tab, which I do mean to press (Keycode 23 KeySym 65056) and C+S+ left and right arrows (Keycode 113/114 Keysym 0), among others.

As a new user, it makes me think keypresses are listened to, which I didn't see advertised and feels slightly worrying. I can only hope it is not logged in order, at most in aggregated form. I mean, I type passwords sometimes, and very much want that signal to be forgotten on the spot by all watchers. Even in aggregated form, I'm not sure I want to store statistics about how my typing contains many more %, &, and w than otherwise usual, or how some days all I type are the letters "adoprssw". Very less all individual events with high-precision timing, which is what the docs seems to indicate.

[johan-bjareholt]

Yeah, that's quite annoying.

aw-watcher-afk is utilizing the PyUserInput package which prints that. Since it's using print() instead of the python logging module we cannot silence that print message. I can try make a pull request to the package and see if they pull it upstream.

aw-watcher-afk simply works as a keylogger but never saves which keys were pressed, only reports if any key has been pressed to aw-server.

We have considered to later save aggregated forms of keypresses, but we currently are not. Your conserns are valid and noted. If we ever implement it we will at least make an option to disable it.

[nikanar]

Maybe the calls to PyUserInput could be silenced using https://stackoverflow.com/q/2828953/ (elaborated upon https://stackoverflow.com/q/8391411/). Would be less proper than using logging, admittedly.

[johan-bjareholt]

Correct me if I'm wrong, but wouldn't that also silence aw-watcher-afks logs to stdout aswell?

Anyway, i made a quick PR PyUserInput/PyUserInput#23

[nikanar]

Depends how it's done, really. At first all I could do would indeed silence the prints that would be done in KeyBoardListener.tap and .escape (but not in ._reset_data, has_new_event nor next_event).

I finally found a better way, using https://stackoverflow.com/a/2829314 ; add, in class KeyboardListener (in listeners.py) :

    lookup_char_from_keycode = nostdout(PyKeyboardEvent.lookup_char_from_keycode)

using

import sys
class DummyFile(object):
    def write(self, x): pass
def nostdout(func):
    def wrapper(*args, **kwargs):        
        save_stdout = sys.stdout
        sys.stdout = DummyFile()
        func(*args, **kwargs)
        sys.stdout = save_stdout
    return wrapper

and it works, and afaict, it doesn't silence anything from aw-watcher-afk.

[ErikBjare]

I'm aware of this issue, but thanks for creating a issue so it doesn't fall between the cracks.

Regarding your concerns of key-logging: None is made, we just need to catch each keypress to know when there is keyboard activity. The actual key being pressed is discarded. We share your concerns of keylogging, and therefore won't ever have it as a standard feature.

I'd rather just fix this by writing the message to a logger rather than printing it directly to stdout (by forking PyUserInput). This way we could disable the logging as we please.

[johan-bjareholt]

@ErikBjare

I'd rather just fix this by writing the message to a logger rather than printing it directly to stdout (by forking PyUserInput). This way we could disable the logging as we please.

Did you miss my comment? did exactly that

PyUserInput/PyUserInput#23

[ErikBjare]

@johan-bjareholt I did, thanks! BTW, the logs are send to stderr, not to stdout.

@nikanar: That would work, but would not be thread safe.

[ErikBjare]

BTW @nikanar, I wanted to send you an email but didn't find one on your GitHub profile. You might want to add one.

What I wanted to ask you: How did you discover the project?

[nikanar]

@ErikBjare Yes indeed, I added nikana496 at gmail dot com. Thanks for mentioning it.

I googled for open source rescue-time alternatives, and found you, along with selfspy (not tried yet, but looks very good a priori) and project hamster (which I disliked for some reason). I apparently missed TimeDoctor but I think I already discarded it before (again for some reason).
Since there are TONS of actual lists of RT-alternatives - e.g. 1 2 3, 4 - (generally not open-source), and you seem to appear on exactly none of them, it must be the combined textual mentions of "RescueTime" (in the feature comparison) and "open source" (first Common Dealbreakers bullet point) that got me here :)

I still badly miss the option of manually labelling some offline time periods, which isn't a fully satisfying feature in RT but exists and isn't too bad. Probably I'll hack myself something together to this end.
And I didn't look much into how to programmatically export AW data into something I can use / visualise, but I believe/hope it won't be too hard once I dive in the docs. Pointers welcome.

Looks like this is fixed in master and can be closed ?

[ErikBjare]

@nikanar: Regarding manual logging: I'm interested in that as well, but I'm a bit apprehensive about expanding the scope of ActivityWatch to include it at this point in development. It would be rather easy to write a ActivityWatch client that stores the data in the ActivityWatch datastore. That way you could leverage some of the visualization work we are doing. I do manual logging right now with a simple textfile (using Standard Notes), works well for me across all devices but lacks any visualization.

It's certainly something I'd want to add to the web UI (RescueTime-style), but right now it's not a priority. If you have any ideas, feel free to create an issue.

Regarding programmatical export: Check out the aw-client library, it makes fetching events easy from Python. Not very well documented right now, but the code should be pretty clear.