Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.