R2.4 Beta 4
The [Appearance & Layout] sub page has been split into two separate [Appearance] and [Layout] sub pages and the controls organised appropriately.
A new [Presence] page has been inserted between the [General] and [Apps] pages and the presence management controls have been moved into it.
Controls that allow the user to pick a particular style to use when always forwarding notifications have been added.
MIME-encoded icon data can now be included in a notify request using the new icon-base64 argument. The data should be encoded as Base64 but any trailing '#' characters should be replaced with '%' symbols before passing to Snarl.
notify?title=Hello, world&text=Some text&icon-base64=h7656m54mrRe4...tGGR4%%&priority=1
A modified version of the helper executable which does not display a console is now included.
Functionality has been added to allow unmanaged styles to pass a notification back to Snarl for on-screen display.
R2.4 Beta 3
Presence management has been significantly improved. A user may now be away or busy (or both). If the user is away, they are not at their computer and may want notifications sent elsewhere; if the user is busy, they are at their computer and do not want to be disturbed. If both conditions are true, busy takes precedence.
The two modes are similar but the differences are significant. While the user is away, low priority notifications are discarded by Snarl and high priority notifications are added to the missed list; while the user is busy, low priority notifications are discarded, and high priority notifications are still displayed. The user can choose from a number of options as to how to deal with normal priority notifications, as follows:
- Log as Missed - adds the notification to the missed list
- Make Sticky - displays the notification on-screen with an infinite timeout
- Discard - the notification is discarded by Snarl without being displayed
- Make Priority - the notification's priority is bumped to high
- Display - the notification is displayed with no alterations
- Forward - the notification is sent to a user-selectable unmanaged style for processing
Bug fixes and cosmetic tweaks.
No longer included as its functionality has now been subsumed into Snarl.
Bug fixes and cosmetic tweaks.
A single instance style which displays the notification icon at the centre of the screen, very similar to the built-in OS X on screen display.
Snarl now supports GNTP natively. Not all functionality is available at present, the following is supported:
- Application registration
- Application unregistration (via a Snarl-specific feature)
- Notification types creation
- Notification creation
- Static callbacks
Support for the following will follow:
- Notification coalescing
DR7 includes both a GrowlNet (UDP) and GNTP sample. The former requires .net to be installed; the latter requires the Java Runtime Environment 1.6 (or later) to be installed.
Basic conditional forwarding has been implemented. This can be accessed from with the new Forwarding tab within the class configuration side panel. Notifications may now be forwarded to zero or more windowless styles based on any of the following conditions being true:
- User is away (sticky notifications are on)
- User is busy (Do Not Disturb mode is on)
- Any other time
There is also a new Run File style which can be used to run a script or batch file. Snarl includes the notification content in three arguments as follows:
- Arg 1 - Notification Title
- Arg 2 - Notification Text
- Arg 3 - Application
There is an example batch file and instructions for how to configure it to test this functionality in the samples folder.
The V42 Windows API has been further refined to the extent that snDoRequest() is now the only officially documented API function. There are a number of official helper functions which can be used to determine if Snarl is running, and to obtain the path to the Snarl executable which are also documented. The VB6 include file also contains a number of unofficial helper functions. See the API guide for more details on this.
Applications can now be managed via their signature as well as via the token returned by the Register action. This is of particular use to environments which cannot receive (or find it difficult to parse) return codes (HTTP communication being one such example). Notifications can also be created in the same way. See the SNP/HTTP example included with DR7 for more details.
Notifications can now be assigned a unique identifier by the application creating them. These identifiers are unique within the application so there is no require to create a GUID or other globally unique content. The UID can be of any length and may contain any characters which can be UTF-8 encoded.
Notifications can be managed using either their globally unique token (returned by the Notify action) or by using a UID/App-Sig pair. If the application was registered using a password, the password must also be supplied (irrespective of which method is used).
Snarl/HTTP has been re-developed to utilise the new V42 API. On the surface there should be little, if any, difference.
AudioMon should now support Vista and Windows 7 systems through the use of the snarl-audiomon daemon developed by Jonus Conrad. Please post details of your experience with this on the development forum, flagging your post with "AudioMon".
Notifications may now have one or more actions assigned to them. This can be achieved via the SNARL42_ADD_ACTION (Win32) or addaction (SNP) commands. A star emblem is displayed in the bottom right corner of any notification which has actions assigned to it (future releases of Snarl may make this optional). Each action may have a static or dynamic callback assigned.
Aside: A static callback is a URL, filesystem path or !bang command which is executed by Snarl when the user selects the appropriate action. A dynamic callback is one where the action does not have a static callback and thus Snarl will send a callback message to the reply-to window provided by the application when it registered. Static callbacks were previously known as 'default acknowledge' within Snarl.
See this blog post for more information (and a picture).
Styles can include a new flag - S_STYLE_V42_CONTENT - which will cause Snarl to send the original, unabridged notification data it received. This allows for more advanced application/style interaction. See this blog post for more information (and more pictures).
Notification content may now be merged, and the body text can be limited to a set number of discrete lines. To merge notification content, the new notification and merge candidate must share the same notification class and title (they must also be from the same application) and both notifications must have been created with the NOTIFICATION_ALLOWS_MERGE flag.
Handling of missed notifications has been improved. The Snarl tray icon now changes to indicate that one or more notifications have been missed and double-clicking the icon when it is in this state will open the missed notifications panel rather than Snarl's preferences. Once the missed panel has been opened the icon (and double-click action) will revert to normal.
If Do Not Disturb mode is enabled, normal priority notifications will be added to the missed list as before, however the sending application will now receive a token to the notification and LastError will be set to ERROR_DO_NOT_DISTURB. This allows the application to change or remove the notification from the missed notifications list if deemed appropriate.
Low priority notifications
Only one low-priority notification may be visible on screen at any one time. When a new low priority notification is to be displayed, any existing low priority notification is first removed. Low-priority notifications are no longer recorded in the missed notifications panel; they are simply discarded if they cannot be displayed.
Screen space handling
If a notification cannot be displayed due to a lack of screen space it will be added to the missed list, a valid token will be returned and LastError will be set to ERROR_COULD_NOT_DISPLAY. Once again, this only applies to high and normal priority notifications; low priority notifications are discarded and no token is returned.
Note: future releases of Snarl may enhance this functionality to remove normal priority notifications from the screen to allow a high priority notification to be displayed.
When registering themselves with Snarl, applications can now supply a password. The password can be a string of any (reasonable) length and may include ASCII and non-ASCII characters. If a password is supplied, the password must be supplied whenever any alteration to the application is made, and when notifications are created. Password-protected applications are identified by a padlock emblem which is displayed in the "Application Registered" notification.
The password is not stored by Snarl and, because an application can supply the password each time it registers, a dynamically generated password can be used to improve security.
R2.4 DR6 has now finally unified the Win32, SNP 2.0/http and SNP 2.0/tcp APIs although the packet formats remain slightly different between the various protocols, as follows:
These differences are managed by Snarl and, as such, are completely transparent to the user or developer. All arguments are now URL-encoded to ensure clashes with '&' and '=' symbols are avoided. A new function - sn42Send() - has been introduced which accepts two parameters: Action, which is the same as the SNP <action> argument; and Args, which is a string of arguments in SNP format.
This blog post includes screenshots of the above functionality.
SNP 2.0 enhancements
SNP 2.0 enhances the ability for the sending application to receive callbacks from Snarl. If a notification has no static callback URL, the sender will receive a NOTIFY_CLICK at its TCP port - assuming it has left it open. At present, because Snarl requires the sending port to remain open, only SNP/tcp supports callbacks.
SNP 2.0 now allows for icons to be included within the request, however it is still experimental at this time.
Snarl's built-in notification forwarder now uses SNP 2.0 to pass the notification on to the destination computer. At this time, backwards compatibility with systems running earlier versions of Snarl is not implemented.
R2.4 DR6 now includes native support for Growl notifications sent via UDP. Application registration and notification generation is supported, however passwords and MD5 checksums are not parsed by Snarl at this time. Due to limitations with the Growl UDP specification it is not possible for Growl applications to unregister with Snarl.
Note: A future Snarl release will offer the user the ability to manually unregister Growl applications from with the Snarl preferences panel.
Hourly Chime is now created as a low priority notification.
This extension has been completely redesigned and now features a new settings panel. It also includes functionality previously provided by the SnarlPower and KeyLock extensions.
This extension now uses the new sn42Send() win32 API function to pass the received URL directly to Snarl.
KeyLock and SnarlPower
These extensions are now obsolete and are not included in the R2.4 DR6 release.
Note: if you have updated to R2.4 DR6 from a previous Snarl release, you should ensure KeyLock and SnarlPower are disabled to avoid receiving duplicate notifications.