Add rules for applescript

[GoogleCodeExporter]

Let's add in rules for applescript to make that portion work in a more unique 
way.

Requires extremely good documentation and examples.

Original issue reported on code.google.com by ch...@growl.info on 5 Oct 2012 at 4:43

[GoogleCodeExporter]

So to give some more info on what the status of what this is, where its going, 
how it works and all that, I thought I'd write something up.  

Rules have been something that power users have requested for a long time.  
Several factors stood in the way of this, first, the UI, figuring a flexible, 
easy to understand UI which still provided powerful options.  Second, the 
backend, how to store the stuff the UI held, and evaluate new notifications 
based on them.  Third, time vs reward, the amount of time spent developing all 
this for a subset (of unknown, but likely not large size) of our users seemed 
inadvisable.  

Enter NSUserAppleScriptTask, new to 10.8, it provides an asynchronous, sandbox 
friendly way of running AppleScript's, and handling the responses from them.  
This has made it possible, and very easy to leverage the power of AppleScript 
to provide users with a rules system where they can make any arbitrary rule 
they want, and we don't have to figure out how to display it, how to handle its 
backend, etc.  

The basic idea is that we will call an event handler in an AppleScript (in say, 
a file named Rules.scpt in our Application Scripts folder), passing it 
information about the Notification, and Growl's current state.  The user's 
script will then return to us a list of various things they wish to be done, a 
display type, action configs, networking forwarding and subscription, logging 
(and possibly other things), and if they don't return some, or any of those 
values, we will simply handle it using the defaults in the main/classic UI.  

This is already wired up and working (not fully tested though) in the 
Future-2.1 branch,  if there is a Rules.scpt, we try to call it, if at any 
point up to getting a result we fail, we call the classic/default system.  

We can take this further, we can allow modification of some of the data in the 
notification for display.  Certain things, like app name, and note type will 
have to remain immutable, but notification title, notification description, and 
icon are all good candidates to allow modification of.  

Some background info on NSUserAppleScriptTask (and its parent/cousins).  The 
scripts the user wishes a sandboxed app to use must go in the blessed folder, 
~/Library/Application Scripts/<code signing id>/  The sandboxed app may not 
write to this folder, but it may read from it.  These scripts are executed by a 
system helper process, outside of a sandbox, and the return value comes back to 
growl asynchronously.  The scripts can block if the user needs them to without 
affecting other notifications, as each rule evaluation is handled separately.  

Things that need testing/dealing with: Load testing, it is unknown the 
performance of this system.  Obviously applescript would not be as fast as a 
native system, but it does need checking, since the scripts are run by the 
system, they won't directly show as being caused by growl, but we would still 
be responsible.
Plugin config names (as of now) can be identical, this will need to change, as 
the backend relies on config id's to handle everything, but those aren't and 
shouldn't be exposed.
Documentation, documentation, documentation.  Chris couldn't be more right on 
this, this system, while optional, will provide users with lots of power, and 
they will want to tap into it, and we need to be ready to help them do that.

Some things to note vs the original concerns, UI, there isn't much UI that we 
have to implement, since we can't write to that file, we can't display a script 
editor to edit it, but we can possibly have it open the script in AppleScript 
Editor.app, a button to open the user to the scripts folder, and some 
indication that there is a Rules.scpt present and active, as well as possibly 
error dialog when it goes wrong.
Backend, the backend changes took me all of the afternoon for initial work, 
mostly it was a bunch of refactoring, and restructuring of the 
dispatchNotificationWithDictionary into two distinct paths, with a bunch of it 
factored out to lower code duplication
Time vs Reward this system is much more flexible in far less time than anything 
else we could do for a rules system.  Rather than having to implement a ton of 
different comparisons, search and other features, the user can come up with 
their own, from our (soon to exist) generous examples.  

Original comment by dan...@growl.info on 5 Oct 2012 at 8:50

• Changed state: Started

[GoogleCodeExporter]

Wall o text likely crits most people pretty hard, so here is a quick screenshot 
of my Rules.scpt I was using for basic testing.
http://t.co/6BIjJ96M

Original comment by dan...@growl.info on 5 Oct 2012 at 9:48

[GoogleCodeExporter]

So, progress update, as of [2a99b1e2a447] the following is working:
setting action(s) to use
setting display to use
changing notification starting position
changing sticky
changing the note's title, description, and image
setting whether to send via network or not, to subscribers or not.

What still needs work
History log has an on/off, but it still hit's the history database's internal 
logic at this point, which can still bounce a note out, and that will need some 
thought on how/whether to modify that.
Networking (at least forwarding) could gain one more level of control, which 
hosts to send to, but this will involve reworking some of the code in 
networking, although it shouldn't be too bad
UI, we need something that indicates we are using Rules, and possibly provide 
more information in the UI elsewhere (such as the raw note type in the app's 
list, which is the note type we pass to the script)
Presently we only allow "default" for the type of default to use, which is the 
default for that note, possibly should include option to use global default
Possibly should switch to having the option of an enumerated type for using 
default, so that users don't get confused about having to type in "default" or 
"none" (could include global default in this enumerated type)

And of course, documentation, documentation, documentation

Original comment by dan...@growl.info on 9 Oct 2012 at 4:19

[GoogleCodeExporter]

Another update
Networking gained its second level of control, you can now send it a list of 
ID's and it will send to them.
Added priority and changing priority.  
Added a logging default for verbose logging of what was done with a 
notification as a result of the rules return.
Switched to an enum for the various default responses, options are none, 
default, or global default option so you can skip that note ticket's parents 
straight up to the global defaults.
Many improvements to the sdef.

Still to do, UI hints/awareness of using rules
More documentation

History logging at this point I feel should be left alone unless someone 
complains about it.  The history database is rather annoyingly laid out in how 
it does logging, so it would require restructuring the logging method pretty 
heavily.  

Original comment by dan...@growl.info on 24 Oct 2012 at 3:59

[GoogleCodeExporter]

Still working on this, mostly done now
Fixed several minor bugs in parsing of boolean types
UI Hints added for note types, and network entry id's/subscriber id's
Documentation is progressing.
Added a warning we are using rules on first use, and a global use rules 
checkbox on the general tab.

Flagging as fixed in source, although documentation efforts will be continuing. 
 Individual bugs with rules should be filed separately.  

Original comment by dan...@growl.info on 4 Dec 2012 at 3:34

• Changed state: FixedInSource