Move support for desktop notifications into Drush Core

Looking good.

I would expect to find pm-download specific code in pm/download.drush.inc. I think that would be a good model for other commands that want to implement custom handling.

Greg.1.Anderson had mentioned a --notify-auto= option which one could set in a drushrc and user would automatically be notified for any long running commands. I haven't considered if thats the best implementation, but it is a neat feature.

Anyone have a clue how to notify on windows?

The patch in #1 supports --notify=60 (notify on completion for commands that execute for more than 60 seconds), which I think is as good as if not better than --notify --notify-auto=60. You can specify default --notify timeouts in drushrc.php files, or command-specific options, and --notify on the cli will override the default value as usual. Works for me.

In 'drush_notify_command_allowed', the $command record is not needed any longer.

notify_drush_help_alter works, but since this is in Drush core now, we could just move these items into drush_get_global_options in drush.inc.

Finally, as an optional enhancement, something that would make this really cool would be to introduce a way to indicate that drush_log should also appear in the notification message after the command completes. This facility could be used in place of notify_drush_pm_post_download in the patch above. I think if we simply defined that all log messages of type 'success' should become notification messages, that things would pretty much just work out the way most users would expect. We might have to review existing log messages and switch some 'success' logs to 'ok', and visa-versa, but a casual review of existing 'success' messages leads me to believe that we're already pretty much on the right track if we go this route.

Any progress, Grayside?

Committed to 6.x with minor cleanups. Thanks Grayside. A few thoughts:

1. I made it so that if you pass notify-audio alone, you get both text and audio alert. Should they work independantly or will you almost always want both?
2. I didn't improve the success or error messages. I think that would be great. The only downside is that verbose messages are tedious with audio but I think audio is always tedious so maybe thats just me.
3. I'm interested in cleanups that move the code to where it belongs (e..g global options, no special case for pm-download, no more register_shutdown, ...)

Lets open new issues for those as needed.

There was 1 failure:
1) completeCase::testComplete
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'--n: (l) --nocolor'
+'--n: (l) --notify-audio'
/home/travis/build/helmo/drush/tests/completeTest.php:189
/home/travis/build/helmo/drush/tests/completeTest.php:97

Suggested fix: https://github.com/helmo/drush/commit/fc797ea022aff71f1cc962f04802c1b4fb...

Committed that suggested fix. Thanks.

There is a follow-up bug report at #2035993: Fatal error: Call to undefined function drush_notify_allowed() in drush/commands/pm/download.pm.inc on line 224