Track active window, not just running processes

[1j01]

There's a package active-window (repo) that looks to be just enough to be able to do this, and no more, assuming it works well enough. Which it might not, looking at the issues. But there are several PRs addressing the issues, and even if they aren't merged in the main repo, they could still be used in a fork.

We'd want to do regex matching generally anchored on the end of the title, e.g. /.* - Sublime Text( \(UNREGISTERED\))?$/ to avoid matching for example Sublime Text - Download - Google Chrome.

Also you'll get noisier data when tracking the active window, such as when switching between your IDE and a program you're working on, or documentation etc. so it would probably be good to automatically connecting the spans of time labeled as programming, but that could happen later when displaying/graphing the data, or earlier.

[abhisheksoni27]

active-window sounds cool. Right. Regex matching is a great idea, Sir. 🎉

I believe what you are trying to say is to be able to pause the timer(sort of), and then continue it when the editor gains focus. And you're right. That can be done later. Though, it'd make more sense to just pause the timer when it loses focus. What do you think?

[1j01]

Oh, I was imagining it was recording timespans, but now I'm guessing it's a timer incremented per day? The readme poses the question of what the numbers mean, but doesn't really answer it.

I'd prefer it to record timespans so the actual hard data is there, and then there could be a heuristic threshold within which to consider timespans joined, which could be updated retroactively.

If it works per day, it could pause the timer "sort of" as I'm guessing you mean, like by storing the end time temporarily so it can choose to whether to join the next timespan that's started based on that threshold. But that wouldn't work retroactively.

You know, I haven't actually tried the time tracking tools that are out there, so I'm going to try Toggl...
So don't worry about me as a user for now.

[abhisheksoni27]

Actually, the JSON file is generated for each and every day, thereby removing the need of incrementing the timer every day. The idea was to enable developers to keep track of how many hours they coded yesterday, and not how many hours they coded since December 21. We could do that, but it beats the purpose.

This means that all you gotta do is make sure the timer is only incremented if the editor (being currently tracked) is the active one or not.

Maybe you need to be able to track the time in the way you suggested, and that's great. But that's not what this does, and I am not sure I see the obvious upside for other users with this. Like I said, it beats the purpose.

Tracking active window, of course, is the number one priority. 🎉