This bug is Reason parameter to SystemSound API functions. It was filed on 2006-05-05 at 00:23 PDT.
Summary:
SystemSound API should have functions that take a reason (expressed as a CFString
) for the beep.
Steps to Reproduce:
- Open .
Expected Results:
One or more functions exist that take a CFString
parameter called inReason
.
Actual Results:
No such functions exist.
Regression:
None.
Notes:
One of the most annoying things that can happen in the Mac environment is when a beep occurs, with no explanation. Sometimes this is the result of a processing delay, with the application beeping multiple seconds after the event that triggered the beep (by which time the user has moved on to some parallel task). Other times, the app is just broken, only beeping when it should also display a dialog or when it should use a Growl notification instead (some apps beep at the completion of a task, optionally or otherwise).
This can be solved by adding new functions to SystemSound (and, for convenience, AppKit — NSBeepWithReason
, say) that take a reason for the beep. This reason would be logged to the Console (example format: “Beeped (Reason: ^0)”), and if the user so desires, displayed to the user in a bezel (or, better yet, a Growl notification). Existing functions, or the new functions with reason=NULL
, would use a localized “No reason was supplied” message.
Example Console.log line:
2006-05-04 22:52:15.974 Safari[252] Beeped (Reason: Quit playing online games and get back to work!).
2006-05-04 22:52:16.974 AppThatDoesNotSupplyAReason[253] Beeped (no reason supplied).
Even if no reason is supplied, the log message is still useful, because it at least says which app beeped.
A Growl notification could have “APPNAME beeped” as the title and the reason as the description. Separate notifications should exist for reason and no reason, with the with-reason notification turned on by default, and the no-reason notification turned off by default.
Technorati tags: Apple Bug Friday, applebugfriday