Screen Capture

github.com/prashantgupta24/activity-tracker

It is a library that lets you monitor certain activities on your machine, and then sends a heartbeat (explained later) at a periodic (configurable) time detailing all the activity changes during that time. The activities that you want to track are monitored by pluggable handlers for those activities and can be added or removed according to your needs. An example of an activity is MouseCursorActivity, i.e. whether your mouse cursor was moved or not. The library can be installed using: The usage is as following: The above code created a tracker with all ('Mouse-click', 'Mouse-movement', 'screen-change' and 'machine-sleep') handlers activated. The heartbeat Interval is set to 60 seconds, i.e. every 60 seconds I received a heartbeat which mentioned all activities that were captured. There are 2 primary configs required for the tracker to work: HeartbeatInterval The Interval at which you want the heartbeat (in seconds, default 60s) and WorkerInterval The Interval at which you want the checks to happen within a heartbeat (default 60s). The activity tracker gives you a heartbeat object every 60 seconds, that is based on the 'HeartbeatInterval'. But there is something else to understand here. In order for the tracker to know how many times an activity occurred, like how many times you moved the cursor for example, it needs to query the mouse position every 'x' seconds. That's where the 'WorkerInterval' comes into play. The 'WorkerInterval' tells the tracker how frequently to check for an activity within a heartbeat. It does that by querying the handler associated with that activity. Let's say you want to know how many times the mouse cursor was moved within 60 seconds. You need to constantly ask the 'mouseCursorHandler' every 'x' seconds to see if the cursor moved. What you want to do is to start the tracker with the usual 60s 'HeartbeatInterval ', configured with a 'Mouse-cursor' handler. In this case, you set the 'WorkerInterval' to 5 seconds. The tracker will then keep asking the mouse cursor handler every 5 seconds to see if there was a movement, and keep track each time there was a change. At the end of 'HeartbeatInterval', it will construct the 'heartbeat' with all the changes and send it. For example, in the output that you saw above, it says 'cursor-move times: 12'. That doesn't mean the cursor was moved only 12 times. Since the 'WorkerInterval' was 5 seconds in the example, that means 'cursorHandler' was asked every 5 seconds (i.e. 12 times in 60 seconds) whether the cursor moved. And it replied that the cursor had indeed moved everytime. - If you want to know how many 'times' an activity occurred within a heartbeat, you might want to set the 'WorkerInterval' to a low value, so that it keeps quering the handlers. - If you are just concerned whether any activity happened within a heartbeat or not, you can set 'WorkerInterval' to a high number (something around 10-15 seconds should do the trick). That way, the workers need not be bothered a lot of times within a 'heartbeat'. Note: If the 'WorkerInterval' and the 'HeartbeatInterval' are set the same, then the 'WorkerInterval' always is started a fraction of a second before the 'HeartbeatInterval' kicks in. This is done so that when the 'heartbeat' is going to be generated at the end of 'HeartbeatInterval', the worker should have done its job of querying each of the handlers before that. Suppose you want to track Activities A, B and C on your machine, and you want to know how many times they occurred every minute. You want a report at the end of every minute saying 'Activity A' happened 5 times, 'Activity B' happened 3 times and 'Activity C' happened 2 times. First, you need to create a 'Handler' for each of those activities. See sections below on how to create one. The main 'tracker' object will simply ask each of the handlers every 'WorkerInterval' amout of time whether that activity happened or not at that moment. As another example, let's say you want to monitor whether there was any mouse click on your machine and you want to be notified every 5 minutes. What you do is start the 'Activity Tracker' with just the 'mouse click' handler and 'heartbeat' Interval set to 5 minutes. The 'Start' function of the library gives you a channel which receives a 'heartbeat' every 5 minutes, and it has details on whether there was a 'click' in those 5 minutes, and if yes, the times the click happened. - Heartbeat struct It is the data packet sent from the tracker library to the user. 'WasAnyActivity' tells if there was any activity within that time frame If there was, then the 'ActivityMap' will tell you what type of activity it was and what all times it occurred. The 'Time' field is the time of the Heartbeat sent (not to be confused with the activity time, which is the time the activity occurred within the 'heartbeat'). The tracker is the main struct for the library. The fields inside it are: 'HeartbeatInterval' The Interval at which you want the heartbeat (in seconds, default 60s) The 'HeartbeatInterval ' value can be set anywhere between 60 seconds - 300 seconds. Not setting it or setting it to anything other than the allowed range will revert it to default of 60s. 'WorkerInterval' The Interval at which you want the checks to happen within a heartbeat (default 60s). The 'WorkerInterval ' value can be set anywhere between 4 seconds - 60 seconds. It CANNOT be more than 'HeartbeatInterval' for obvious reasons. Not setting it or setting it to anything other than the allowed range will revert it to default of 60s. The 'system.State' struct captures the current state of the tracker, and the whole system in general. It is used by some of the handlers to respond to a certain system state. It is passed to the handlers when performing the Trigger, so that the handlers can take an informed decision on whether to get activated or not at that instance. For example, the 'sleepHandler' changes the state of the system to sleeping, so that the 'mouseCursorHandler' and 'mouseClickHandler' don't need to do any work while the system remains in the sleep state. Note: It also serves as a way of inter-handler communication. There are 2 types of handlers: - Push based - Pull based The 'push' based ones are those that automatically push to the 'tracker' object when an activity happened. Examples are the 'mouseClickHander' and 'machineSleepHandler'. Whenever a mouse-click/machine-sleep happens, it sends the 'activity' to the 'tracker' object. The 'pull' based ones are those that the 'tracker' has to ask the handler to know if there was any activity happening at that moment. Examples are 'mouseCursorHandler' and 'screenChangeHandler'. The 'asking' is done through the 'Trigger' function implemented by handlers. It is up to you to define how to implement the handler. Some make sense to be pull based, since it is going to be memory intensive to make the mouse cursor movement handler push-based. It made sense to make it 'pull' based. Any new type of handler for an activity can be easily added, it just needs to implement the above 'Handler' interface below: It also needs to define what 'type' of activity it is going to track (also add the new 'activity' as well if it's a new activity), that's it! It can be plugged in with the tracker and then the tracker will include those activity checks in its heartbeat. Note: Handlers have a one-to-many relationship with activity, i.e. each Handler can be associated with one or more activity (That becomes the value returned by handler's 'Type') On the other hand, each activity should be tracked by only ONE handler (which makes sense). As a fail-safe, if the tracker is started with more than one handler tracking the same activity, then only 1 handler will get registered for that activity. Currently supported activities are: Corresponding handlers: - Mouse click (whether any mouse click happened during the time frame) - Mouse cursor movement (whether the mouse cursor was moved during the time frame) - Screen change handler (whether the active window was changed) - Machine sleep/wake handler (**this is added by default for fail-safe measures**) Check out the example here : https://github.com/prashantgupta24/activity-tracker/blob/master/example/example.go

v1.0.1 • last year

github.com/opencinemac/vtc-go

Package vtc is inspired by years of scripting workflow solutions in a Hollywood cutting room. It aims to capture all the ways in which timecode is used throughout the industry so users can spend more time on their workflow logic, and less time handling the corner-cases of parsing and calculating timecode. To get an overview of what this package can do, see the example at the bottom. But first: what is timecode? If you're already familiar with timecode, it's history, and it's flavors, feel free to skip this section. Back in the days of film, a running strip of numbers ran along the edge of the film stock to uniquely identify each frame, called keycode (https://en.wikipedia.org/wiki/Keykode) Keycode was essential to the film editing process. The raw negative of a film is irreplaceable: you loose quality each time you make a copy. Editing film is necessarily a destructive process (https://nofilmschool.com/2017/06/editing-on-a-flatbed), and often required multiple iterations. It would be just a tad nerve-wracking to take a pair of scissors and some glue to the one-of-a-kind film reels straight out of the camera on set, then running it over and over through a flatbed. To avoid potential disaster, editors made their cut of the film using copies of the raw negative, called a work print (https://en.wikipedia.org/wiki/Workprint), allowing the editor to work without fear of sinking a project from slicing, dicing, and wearing at the film. When the edit was complete, it was necessary to know *exactly* where the edits had been made, so it could be recreated with the raw negative for finishing. A *cut list* would be written out, with the exact reels and keycodes for every cut, and would be used to make an exact duplicate of the editor's work print with the mint condition raw negative. In video and digital filmmaking, the same approach is used. Massive RAW files from a RED, ARRI, Sony, or other cinema camera are rendered down to more manageable files an Editor's machine won't choke on. Once the edit is complete, the raw files are re-assembled using a digital cutlist on a powerful machine for finishing out the film. In film, we referenced *keycode* to know exactly what frame was being displayed on screen at any given time. In digital video, we reference the *timecode* of a given frame. For a technical deep-dive into the many flavors of timecode, check out Frame.io's excellent blogpost on the subject: https://blog.frame.io/2017/07/17/timecode-and-frame-rates. This package is broken into two subpackages: • rate: framerate types and functions • tc: timecode types and functions See the subdirectories below. See a brief overview of this package by expanding the example below:

v0.1.0 • 3 years ago

github.com/resousse/activity-tracker

It is a library that lets you monitor certain activities on your machine, and then sends a heartbeat (explained later) at a periodic (configurable) time detailing all the activity changes during that time. The activities that you want to track are monitored by pluggable handlers for those activities and can be added or removed according to your needs. An example of an activity is MouseCursorActivity, i.e. whether your mouse cursor was moved or not. The library can be installed using: The usage is as following: The above code created a tracker with all ('Mouse-click', 'Mouse-movement', 'screen-change' and 'machine-sleep') handlers activated. The heartbeat Interval is set to 60 seconds, i.e. every 60 seconds I received a heartbeat which mentioned all activities that were captured. There are 2 primary configs required for the tracker to work: HeartbeatInterval The Interval at which you want the heartbeat (in seconds, default 60s) and WorkerInterval The Interval at which you want the checks to happen within a heartbeat (default 60s). The activity tracker gives you a heartbeat object every 60 seconds, that is based on the 'HeartbeatInterval'. But there is something else to understand here. In order for the tracker to know how many times an activity occurred, like how many times you moved the cursor for example, it needs to query the mouse position every 'x' seconds. That's where the 'WorkerInterval' comes into play. The 'WorkerInterval' tells the tracker how frequently to check for an activity within a heartbeat. It does that by querying the handler associated with that activity. Let's say you want to know how many times the mouse cursor was moved within 60 seconds. You need to constantly ask the 'mouseCursorHandler' every 'x' seconds to see if the cursor moved. What you want to do is to start the tracker with the usual 60s 'HeartbeatInterval ', configured with a 'Mouse-cursor' handler. In this case, you set the 'WorkerInterval' to 5 seconds. The tracker will then keep asking the mouse cursor handler every 5 seconds to see if there was a movement, and keep track each time there was a change. At the end of 'HeartbeatInterval', it will construct the 'heartbeat' with all the changes and send it. For example, in the output that you saw above, it says 'cursor-move times: 12'. That doesn't mean the cursor was moved only 12 times. Since the 'WorkerInterval' was 5 seconds in the example, that means 'cursorHandler' was asked every 5 seconds (i.e. 12 times in 60 seconds) whether the cursor moved. And it replied that the cursor had indeed moved everytime. - If you want to know how many 'times' an activity occurred within a heartbeat, you might want to set the 'WorkerInterval' to a low value, so that it keeps quering the handlers. - If you are just concerned whether any activity happened within a heartbeat or not, you can set 'WorkerInterval' to a high number (something around 10-15 seconds should do the trick). That way, the workers need not be bothered a lot of times within a 'heartbeat'. Note: If the 'WorkerInterval' and the 'HeartbeatInterval' are set the same, then the 'WorkerInterval' always is started a fraction of a second before the 'HeartbeatInterval' kicks in. This is done so that when the 'heartbeat' is going to be generated at the end of 'HeartbeatInterval', the worker should have done its job of querying each of the handlers before that. Suppose you want to track Activities A, B and C on your machine, and you want to know how many times they occurred every minute. You want a report at the end of every minute saying 'Activity A' happened 5 times, 'Activity B' happened 3 times and 'Activity C' happened 2 times. First, you need to create a 'Handler' for each of those activities. See sections below on how to create one. The main 'tracker' object will simply ask each of the handlers every 'WorkerInterval' amout of time whether that activity happened or not at that moment. As another example, let's say you want to monitor whether there was any mouse click on your machine and you want to be notified every 5 minutes. What you do is start the 'Activity Tracker' with just the 'mouse click' handler and 'heartbeat' Interval set to 5 minutes. The 'Start' function of the library gives you a channel which receives a 'heartbeat' every 5 minutes, and it has details on whether there was a 'click' in those 5 minutes, and if yes, the times the click happened. - Heartbeat struct It is the data packet sent from the tracker library to the user. 'WasAnyActivity' tells if there was any activity within that time frame If there was, then the 'ActivityMap' will tell you what type of activity it was and what all times it occurred. The 'Time' field is the time of the Heartbeat sent (not to be confused with the activity time, which is the time the activity occurred within the 'heartbeat'). The tracker is the main struct for the library. The fields inside it are: 'HeartbeatInterval' The Interval at which you want the heartbeat (in seconds, default 60s) The 'HeartbeatInterval ' value can be set anywhere between 60 seconds - 300 seconds. Not setting it or setting it to anything other than the allowed range will revert it to default of 60s. 'WorkerInterval' The Interval at which you want the checks to happen within a heartbeat (default 60s). The 'WorkerInterval ' value can be set anywhere between 4 seconds - 60 seconds. It CANNOT be more than 'HeartbeatInterval' for obvious reasons. Not setting it or setting it to anything other than the allowed range will revert it to default of 60s. The 'system.State' struct captures the current state of the tracker, and the whole system in general. It is used by some of the handlers to respond to a certain system state. It is passed to the handlers when performing the Trigger, so that the handlers can take an informed decision on whether to get activated or not at that instance. For example, the 'sleepHandler' changes the state of the system to sleeping, so that the 'mouseCursorHandler' and 'mouseClickHandler' don't need to do any work while the system remains in the sleep state. Note: It also serves as a way of inter-handler communication. There are 2 types of handlers: - Push based - Pull based The 'push' based ones are those that automatically push to the 'tracker' object when an activity happened. Examples are the 'mouseClickHander' and 'machineSleepHandler'. Whenever a mouse-click/machine-sleep happens, it sends the 'activity' to the 'tracker' object. The 'pull' based ones are those that the 'tracker' has to ask the handler to know if there was any activity happening at that moment. Examples are 'mouseCursorHandler' and 'screenChangeHandler'. The 'asking' is done through the 'Trigger' function implemented by handlers. It is up to you to define how to implement the handler. Some make sense to be pull based, since it is going to be memory intensive to make the mouse cursor movement handler push-based. It made sense to make it 'pull' based. Any new type of handler for an activity can be easily added, it just needs to implement the above 'Handler' interface below: It also needs to define what 'type' of activity it is going to track (also add the new 'activity' as well if it's a new activity), that's it! It can be plugged in with the tracker and then the tracker will include those activity checks in its heartbeat. Note: Handlers have a one-to-many relationship with activity, i.e. each Handler can be associated with one or more activity (That becomes the value returned by handler's 'Type') On the other hand, each activity should be tracked by only ONE handler (which makes sense). As a fail-safe, if the tracker is started with more than one handler tracking the same activity, then only 1 handler will get registered for that activity. Currently supported activities are: Corresponding handlers: - Mouse click (whether any mouse click happened during the time frame) - Mouse cursor movement (whether the mouse cursor was moved during the time frame) - Screen change handler (whether the active window was changed) - Machine sleep/wake handler (**this is added by default for fail-safe measures**) Check out the example here : https://github.com/resousse/activity-tracker/blob/master/example/example.go

v1.0.5 • last year

github.com/shubhindia/activity-tracker

It is a library that lets you monitor certain activities on your machine, and then sends a heartbeat (explained later) at a periodic (configurable) time detailing all the activity changes during that time. The activities that you want to track are monitored by pluggable handlers for those activities and can be added or removed according to your needs. An example of an activity is MouseCursorActivity, i.e. whether your mouse cursor was moved or not. The library can be installed using: The usage is as following: The above code created a tracker with all ('Mouse-click', 'Mouse-movement', 'screen-change' and 'machine-sleep') handlers activated. The heartbeat Interval is set to 60 seconds, i.e. every 60 seconds I received a heartbeat which mentioned all activities that were captured. There are 2 primary configs required for the tracker to work: HeartbeatInterval The Interval at which you want the heartbeat (in seconds, default 60s) and WorkerInterval The Interval at which you want the checks to happen within a heartbeat (default 60s). The activity tracker gives you a heartbeat object every 60 seconds, that is based on the 'HeartbeatInterval'. But there is something else to understand here. In order for the tracker to know how many times an activity occurred, like how many times you moved the cursor for example, it needs to query the mouse position every 'x' seconds. That's where the 'WorkerInterval' comes into play. The 'WorkerInterval' tells the tracker how frequently to check for an activity within a heartbeat. It does that by querying the handler associated with that activity. Let's say you want to know how many times the mouse cursor was moved within 60 seconds. You need to constantly ask the 'mouseCursorHandler' every 'x' seconds to see if the cursor moved. What you want to do is to start the tracker with the usual 60s 'HeartbeatInterval ', configured with a 'Mouse-cursor' handler. In this case, you set the 'WorkerInterval' to 5 seconds. The tracker will then keep asking the mouse cursor handler every 5 seconds to see if there was a movement, and keep track each time there was a change. At the end of 'HeartbeatInterval', it will construct the 'heartbeat' with all the changes and send it. For example, in the output that you saw above, it says 'cursor-move times: 12'. That doesn't mean the cursor was moved only 12 times. Since the 'WorkerInterval' was 5 seconds in the example, that means 'cursorHandler' was asked every 5 seconds (i.e. 12 times in 60 seconds) whether the cursor moved. And it replied that the cursor had indeed moved everytime. - If you want to know how many 'times' an activity occurred within a heartbeat, you might want to set the 'WorkerInterval' to a low value, so that it keeps quering the handlers. - If you are just concerned whether any activity happened within a heartbeat or not, you can set 'WorkerInterval' to a high number (something around 10-15 seconds should do the trick). That way, the workers need not be bothered a lot of times within a 'heartbeat'. Note: If the 'WorkerInterval' and the 'HeartbeatInterval' are set the same, then the 'WorkerInterval' always is started a fraction of a second before the 'HeartbeatInterval' kicks in. This is done so that when the 'heartbeat' is going to be generated at the end of 'HeartbeatInterval', the worker should have done its job of querying each of the handlers before that. Suppose you want to track Activities A, B and C on your machine, and you want to know how many times they occurred every minute. You want a report at the end of every minute saying 'Activity A' happened 5 times, 'Activity B' happened 3 times and 'Activity C' happened 2 times. First, you need to create a 'Handler' for each of those activities. See sections below on how to create one. The main 'tracker' object will simply ask each of the handlers every 'WorkerInterval' amout of time whether that activity happened or not at that moment. As another example, let's say you want to monitor whether there was any mouse click on your machine and you want to be notified every 5 minutes. What you do is start the 'Activity Tracker' with just the 'mouse click' handler and 'heartbeat' Interval set to 5 minutes. The 'Start' function of the library gives you a channel which receives a 'heartbeat' every 5 minutes, and it has details on whether there was a 'click' in those 5 minutes, and if yes, the times the click happened. - Heartbeat struct It is the data packet sent from the tracker library to the user. 'WasAnyActivity' tells if there was any activity within that time frame If there was, then the 'ActivityMap' will tell you what type of activity it was and what all times it occurred. The 'Time' field is the time of the Heartbeat sent (not to be confused with the activity time, which is the time the activity occurred within the 'heartbeat'). The tracker is the main struct for the library. The fields inside it are: 'HeartbeatInterval' The Interval at which you want the heartbeat (in seconds, default 60s) The 'HeartbeatInterval ' value can be set anywhere between 60 seconds - 300 seconds. Not setting it or setting it to anything other than the allowed range will revert it to default of 60s. 'WorkerInterval' The Interval at which you want the checks to happen within a heartbeat (default 60s). The 'WorkerInterval ' value can be set anywhere between 4 seconds - 60 seconds. It CANNOT be more than 'HeartbeatInterval' for obvious reasons. Not setting it or setting it to anything other than the allowed range will revert it to default of 60s. The 'system.State' struct captures the current state of the tracker, and the whole system in general. It is used by some of the handlers to respond to a certain system state. It is passed to the handlers when performing the Trigger, so that the handlers can take an informed decision on whether to get activated or not at that instance. For example, the 'sleepHandler' changes the state of the system to sleeping, so that the 'mouseCursorHandler' and 'mouseClickHandler' don't need to do any work while the system remains in the sleep state. Note: It also serves as a way of inter-handler communication. There are 2 types of handlers: - Push based - Pull based The 'push' based ones are those that automatically push to the 'tracker' object when an activity happened. Examples are the 'mouseClickHander' and 'machineSleepHandler'. Whenever a mouse-click/machine-sleep happens, it sends the 'activity' to the 'tracker' object. The 'pull' based ones are those that the 'tracker' has to ask the handler to know if there was any activity happening at that moment. Examples are 'mouseCursorHandler' and 'screenChangeHandler'. The 'asking' is done through the 'Trigger' function implemented by handlers. It is up to you to define how to implement the handler. Some make sense to be pull based, since it is going to be memory intensive to make the mouse cursor movement handler push-based. It made sense to make it 'pull' based. Any new type of handler for an activity can be easily added, it just needs to implement the above 'Handler' interface below: It also needs to define what 'type' of activity it is going to track (also add the new 'activity' as well if it's a new activity), that's it! It can be plugged in with the tracker and then the tracker will include those activity checks in its heartbeat. Note: Handlers have a one-to-many relationship with activity, i.e. each Handler can be associated with one or more activity (That becomes the value returned by handler's 'Type') On the other hand, each activity should be tracked by only ONE handler (which makes sense). As a fail-safe, if the tracker is started with more than one handler tracking the same activity, then only 1 handler will get registered for that activity. Currently supported activities are: Corresponding handlers: - Mouse click (whether any mouse click happened during the time frame) - Mouse cursor movement (whether the mouse cursor was moved during the time frame) - Screen change handler (whether the active window was changed) - Machine sleep/wake handler (**this is added by default for fail-safe measures**) Check out the example here : https://github.com/shubhindia/activity-tracker/blob/master/example/example.go

v1.0.1 • 2 years ago

github.com/dongs0104/activity-tracker

It is a library that lets you monitor certain activities on your machine, and then sends a heartbeat (explained later) at a periodic (configurable) time detailing all the activity changes during that time. The activities that you want to track are monitored by pluggable handlers for those activities and can be added or removed according to your needs. An example of an activity is MouseCursorActivity, i.e. whether your mouse cursor was moved or not. The library can be installed using: The usage is as following: The above code created a tracker with all ('Mouse-click', 'Mouse-movement', 'screen-change' and 'machine-sleep') handlers activated. The heartbeat Interval is set to 60 seconds, i.e. every 60 seconds I received a heartbeat which mentioned all activities that were captured. There are 2 primary configs required for the tracker to work: HeartbeatInterval The Interval at which you want the heartbeat (in seconds, default 60s) and WorkerInterval The Interval at which you want the checks to happen within a heartbeat (default 60s). The activity tracker gives you a heartbeat object every 60 seconds, that is based on the 'HeartbeatInterval'. But there is something else to understand here. In order for the tracker to know how many times an activity occurred, like how many times you moved the cursor for example, it needs to query the mouse position every 'x' seconds. That's where the 'WorkerInterval' comes into play. The 'WorkerInterval' tells the tracker how frequently to check for an activity within a heartbeat. It does that by querying the handler associated with that activity. Let's say you want to know how many times the mouse cursor was moved within 60 seconds. You need to constantly ask the 'mouseCursorHandler' every 'x' seconds to see if the cursor moved. What you want to do is to start the tracker with the usual 60s 'HeartbeatInterval ', configured with a 'Mouse-cursor' handler. In this case, you set the 'WorkerInterval' to 5 seconds. The tracker will then keep asking the mouse cursor handler every 5 seconds to see if there was a movement, and keep track each time there was a change. At the end of 'HeartbeatInterval', it will construct the 'heartbeat' with all the changes and send it. For example, in the output that you saw above, it says 'cursor-move times: 12'. That doesn't mean the cursor was moved only 12 times. Since the 'WorkerInterval' was 5 seconds in the example, that means 'cursorHandler' was asked every 5 seconds (i.e. 12 times in 60 seconds) whether the cursor moved. And it replied that the cursor had indeed moved everytime. - If you want to know how many 'times' an activity occurred within a heartbeat, you might want to set the 'WorkerInterval' to a low value, so that it keeps quering the handlers. - If you are just concerned whether any activity happened within a heartbeat or not, you can set 'WorkerInterval' to a high number (something around 10-15 seconds should do the trick). That way, the workers need not be bothered a lot of times within a 'heartbeat'. Note: If the 'WorkerInterval' and the 'HeartbeatInterval' are set the same, then the 'WorkerInterval' always is started a fraction of a second before the 'HeartbeatInterval' kicks in. This is done so that when the 'heartbeat' is going to be generated at the end of 'HeartbeatInterval', the worker should have done its job of querying each of the handlers before that. Suppose you want to track Activities A, B and C on your machine, and you want to know how many times they occurred every minute. You want a report at the end of every minute saying 'Activity A' happened 5 times, 'Activity B' happened 3 times and 'Activity C' happened 2 times. First, you need to create a 'Handler' for each of those activities. See sections below on how to create one. The main 'tracker' object will simply ask each of the handlers every 'WorkerInterval' amout of time whether that activity happened or not at that moment. As another example, let's say you want to monitor whether there was any mouse click on your machine and you want to be notified every 5 minutes. What you do is start the 'Activity Tracker' with just the 'mouse click' handler and 'heartbeat' Interval set to 5 minutes. The 'Start' function of the library gives you a channel which receives a 'heartbeat' every 5 minutes, and it has details on whether there was a 'click' in those 5 minutes, and if yes, the times the click happened. - Heartbeat struct It is the data packet sent from the tracker library to the user. 'WasAnyActivity' tells if there was any activity within that time frame If there was, then the 'ActivityMap' will tell you what type of activity it was and what all times it occurred. The 'Time' field is the time of the Heartbeat sent (not to be confused with the activity time, which is the time the activity occurred within the 'heartbeat'). The tracker is the main struct for the library. The fields inside it are: 'HeartbeatInterval' The Interval at which you want the heartbeat (in seconds, default 60s) The 'HeartbeatInterval ' value can be set anywhere between 60 seconds - 300 seconds. Not setting it or setting it to anything other than the allowed range will revert it to default of 60s. 'WorkerInterval' The Interval at which you want the checks to happen within a heartbeat (default 60s). The 'WorkerInterval ' value can be set anywhere between 4 seconds - 60 seconds. It CANNOT be more than 'HeartbeatInterval' for obvious reasons. Not setting it or setting it to anything other than the allowed range will revert it to default of 60s. The 'system.State' struct captures the current state of the tracker, and the whole system in general. It is used by some of the handlers to respond to a certain system state. It is passed to the handlers when performing the Trigger, so that the handlers can take an informed decision on whether to get activated or not at that instance. For example, the 'sleepHandler' changes the state of the system to sleeping, so that the 'mouseCursorHandler' and 'mouseClickHandler' don't need to do any work while the system remains in the sleep state. Note: It also serves as a way of inter-handler communication. There are 2 types of handlers: - Push based - Pull based The 'push' based ones are those that automatically push to the 'tracker' object when an activity happened. Examples are the 'mouseClickHander' and 'machineSleepHandler'. Whenever a mouse-click/machine-sleep happens, it sends the 'activity' to the 'tracker' object. The 'pull' based ones are those that the 'tracker' has to ask the handler to know if there was any activity happening at that moment. Examples are 'mouseCursorHandler' and 'screenChangeHandler'. The 'asking' is done through the 'Trigger' function implemented by handlers. It is up to you to define how to implement the handler. Some make sense to be pull based, since it is going to be memory intensive to make the mouse cursor movement handler push-based. It made sense to make it 'pull' based. Any new type of handler for an activity can be easily added, it just needs to implement the above 'Handler' interface below: It also needs to define what 'type' of activity it is going to track (also add the new 'activity' as well if it's a new activity), that's it! It can be plugged in with the tracker and then the tracker will include those activity checks in its heartbeat. Note: Handlers have a one-to-many relationship with activity, i.e. each Handler can be associated with one or more activity (That becomes the value returned by handler's 'Type') On the other hand, each activity should be tracked by only ONE handler (which makes sense). As a fail-safe, if the tracker is started with more than one handler tracking the same activity, then only 1 handler will get registered for that activity. Currently supported activities are: Corresponding handlers: - Mouse click (whether any mouse click happened during the time frame) - Mouse cursor movement (whether the mouse cursor was moved during the time frame) - Screen change handler (whether the active window was changed) - Machine sleep/wake handler (**this is added by default for fail-safe measures**) Check out the example here : https://github.com/dongs0104/activity-tracker/blob/master/example/example.go

v0.0.0-20230620232352-fe0d4650d43b • last year

github.com/kbinani/screenshot

github.com/rdnt/go-scrap

github.com/prashantgupta24/activity-tracker

github.com/cretz/go-scrap

github.com/Blink-A/screenshot

github.com/sherryxqq9/screencapturekit

github.com/dantheman213/quick-screen-capture

github.com/champ243/screenshot

github.com/kazusapg/go-screen-capture

github.com/xuchengzhi/screenshot

github.com/opencinemac/vtc-go

github.com/LiamHaworth/screenshot

github.com/wawesomeNOGUI/screenshot

github.com/davidsbond/screenshot

github.com/gen2brain/screenshot

github.com/ksg97031/screenshot

github.com/loadcloud/gosiege

github.com/prozedure/screenshot

github.com/efunn/go-scrap

github.com/a702169588/screenshot

github.com/beetekau/screenshot

github.com/DanielPels/screenshot

github.com/lukegb/screenshot

github.com/liamhaworth/screenshot

github.com/audiolion/screenshot

github.com/capnspacehook/screenshot

github.com/sccxx/screenshot

github.com/ghp3000/screenshot

github.com/hhh0pe/screenshot

github.com/liconglei/screenshot

github.com/bo-er/screenshot

github.com/hansmissenheim/go-theft-auto

github.com/hhh0pE/screenshot

github.com/gastfreund/screenshot

github.com/4ra1n/screenshot

github.com/4nte/screenshot

github.com/AnomalRoil/screenshot

github.com/LightningDev1/go-screenshot

github.com/l3aalteshuva/screenshot

github.com/resousse/activity-tracker

github.com/shubhindia/activity-tracker

github.com/dongs0104/activity-tracker

github.com/NublyBR/screenshot