switch from terminal-notifier to alerter#76
Open
mkozjak wants to merge 1 commit into
Open
Conversation
Author
|
@gen2brain - any thoughts on this approach? |
Owner
|
Did not have much time to test; I have some VMs I am using for that. I do not like all that additional code and am not convinced it is needed, so I have to check for myself when I find the time. |
Author
|
Yes, I totally agree. I guess it's best for vjeantet/alerter#70 to get resolved first. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 PR aims on switching from terminal-notifier to Alerter with the change being fully transparent to users.
While there are not many changes in program arguments on
alerter(aside from the single to double dash change) there's a distinct change in Alerter that makes the process hang until the notification quits. This renders ourc.Run()golang call toWaitindefinitely and makes the command change to not be transparent to library users. Hence whyalerteris now launched withStart()instead ofRun(), so the library returns to the caller without blocking for the lifetime of the notification.The main issue with letting the process launch on its own without any checkups is the existing app icon cleanup procedure, that erases the photo before the
alerterprocess settles and starts idling with its notification drawn on the screen.With the aid from AI there's two new private functions,
pidTaskInfoandwaitUntilIdle, that use low-level C functions to determine thealerterprocess is actually ready before returning.More background on this here.
Resolves #75.
We can also consider this PR just as a PoC. I can convert it to draft if needed.
This PR builds and runs successfully on my macOS Tahoe 26.5 setup.
My testing code: