This change covers a niche use case, and should not functionally alter the program in any way. It is a change to how the log file is written to, and how the operations interact with macOS system APIs.
The purpose is to generate FSEvents for each log write, so that writes can trigger a launchd agent that uses WatchPaths to run a program when the TomatoBar.log file is written to. I made this change so I could set up an agent to set the wallpaper color based on the state of TomatoBar, by monitoring the log file and reading the last line when it changes.
Currently, TomatoBar opens a FileHandle and maintains it for the duration of the program, using FileHandle.synchronize() to write to disk. However, this does not generate an FSEvent, and does not trigger the launchd agent. For that, the FileHandle needs to be closed, either with an explicit FileHandle.close(), or by the FileHandle object being deallocated.
I removed the logHandle property of TBLogger, since we will be initializing and deallocating the FileHandle on each write, we don't need to hold onto it. I moved the code for creating a FileHandle out of TBLogger's init() into a separate function, openFileHandle(), which returns the created FileHandle. append() calls openFileHandle(), does the append, and then when the function exits the FileHandle is deallocated, an FSEvent is generated, and the launchd agent (if the user has created one) will trigger. This process repeats each time the log is appended to.
I believe the performance impact of this change is negligible due to the infrequency of logging. I understand if you don't want to merge this change to cover this usage.
This change covers a niche use case, and should not functionally alter the program in any way. It is a change to how the log file is written to, and how the operations interact with macOS system APIs.
The purpose is to generate FSEvents for each log write, so that writes can trigger a launchd agent that uses WatchPaths to run a program when the TomatoBar.log file is written to. I made this change so I could set up an agent to set the wallpaper color based on the state of TomatoBar, by monitoring the log file and reading the last line when it changes.
Currently, TomatoBar opens a FileHandle and maintains it for the duration of the program, using FileHandle.synchronize() to write to disk. However, this does not generate an FSEvent, and does not trigger the launchd agent. For that, the FileHandle needs to be closed, either with an explicit FileHandle.close(), or by the FileHandle object being deallocated.
I removed the logHandle property of TBLogger, since we will be initializing and deallocating the FileHandle on each write, we don't need to hold onto it. I moved the code for creating a FileHandle out of TBLogger's init() into a separate function, openFileHandle(), which returns the created FileHandle. append() calls openFileHandle(), does the append, and then when the function exits the FileHandle is deallocated, an FSEvent is generated, and the launchd agent (if the user has created one) will trigger. This process repeats each time the log is appended to.
I believe the performance impact of this change is negligible due to the infrequency of logging. I understand if you don't want to merge this change to cover this usage.