API change request: updating on-screen notifications

[roddi]

Hello,

I have telephony application, where an incoming call is notified with growl. When the telephone is signalling the number of the calling party I do a look-up in address book and notify the name of the calling person if found. Fine thing!

Now, if the address book does not resolve the telephone number, I do an asynchronous LDAP-lookup. This can take 1-2 seconds. I don't want to delay the growl notification of the number, so I notify the number as "unknown" and when/if the LDAP lookup calls back I sent another notification with the calling persons name.

My own notification window changes its content at this time (because it's the same call)

What I like to have is this:

The growl client chooses (i.e.: I choose) an id under which to send a notification. For each subsequent notification the client chooses a new id. If there's an update to an existing notification the client reuses the id and growl can exchange the content of the notification if it's still on screen.

Is that feasible?

Roddi

[evands]

We call this "coalescing notifications" and it's already been implemented for the next major release of Growl, 0.8, which is in development. That release is probably some time off, but when it happens, you'll be able to do this. If you're so inclined, you could potentially backport the improvement to the Growl 0.7.x branch so it would be available to you and others in a closer timeframe - I'd be willing to review a patch doing so.

[roddi]

I guess I can wait till then (no user had a complaint yet).

To which Milestone in the GrowlTrac does 0.8 map? To Milestone 1.0?

[The_Tick]

We call this "coalescing notifications" and it's already been implemented for the next major release of Growl, 0.8, which is in development. That release is probably some time off, but when it happens, you'll be able to do this. If you're so inclined, you could potentially backport the improvement to the Growl 0.7.x branch so it would be available to you and others in a closer timeframe - I'd be willing to review a patch doing so.

Actually, I think we have it in .7.x but it's just not documented. It requires the cocoa (maybe the carbon) api, I know applescripting won't work.

I'd have to dig around headers to find out how to call it exactly though. I think Mac-arena knows how to do it offhand, and I'm pretty sure some of the Extras are using it already.

[evands]

Oh, wow, Chris, you're right. It's just so shiny and I'd never used it I assumed it was just the new code It is, in fact, documented, at least on the Cocoa side.

roddi, from the application bridge header:

Code: Select all

/*!
 *	@method notifyWithTitle:description:notificationName:iconData:priority:isSticky:clickContext:identifier:
 *	@abstract Send a Growl notification.
 *	@discussion This is the preferred means for sending a Growl notification.
 *	 The notification name and at least one of the title and description are
 *	 required (all three are preferred).  All other parameters may be
 *	 <code>nil</code> (or 0 or NO as appropriate) to accept default values.
 *
 *	 If using the Growl-WithInstaller framework, if Growl is not installed the
 *	 user will be prompted to install Growl. If the user cancels, this method
 *	 will have no effect until the next application session, at which time when
 *	 it is called the user will be prompted again. The user is also given the
 *	 option to not be prompted again.  If the user does choose to install Growl,
 *	 the requested notification will be displayed once Growl is installed and
 *	 running.
 *
 *	@param title		The title of the notification displayed to the user.
 *	@param description	The full description of the notification displayed to the user.
 *	@param notifName	The internal name of the notification. Should be human-readable, as it will be displayed in the Growl preference pane.
 *	@param iconData		<code>NSData</code> object to show with the notification as its icon. If <code>nil</code>, the application's icon will be used instead.
 *	@param priority		The priority of the notification. The default value is 0; positive values are higher priority and negative values are lower priority. Not all Growl displays support priority.
 *	@param isSticky		If YES, the notification will remain on screen until clicked. Not all Growl displays support sticky notifications.
 *	@param clickContext	A context passed back to the Growl delegate if it implements -(void)growlNotificationWasClicked: and the notification is clicked. Not all display plugins support clicking. The clickContext must be plist-encodable (completely of <code>NSString</code>, <code>NSArray</code>, <code>NSNumber</code>, <code>NSDictionary</code>, and <code>NSData</code> types).
 *	@param identifier	An identifier for this notification. Notifications with equal identifiers are coalesced.
 */
+ (void) notifyWithTitle:(NSString *)title
			 description:(NSString *)description
		notificationName:(NSString *)notifName
				iconData:(NSData *)iconData
				priority:(signed int)priority
				isSticky:(BOOL)isSticky
			clickContext:(id)clickContext
			  identifier:(NSString *)identifier;

and yes, 0.8 is going to be 1.0 - I forget we'd made that future versioning change.

[roddi]

Works like a charm with 0.7.4. I use this to test if coalescing is there:

Code: Select all

	if ([[GrowlApplicationBridge class] respondsToSelector:@selector(notifyWithTitle:description:notificationName:iconData:priority:isSticky:clickContext:identifier:)])

Only problem is that when new info is available the notification usually gets bigger. It grows upwards and parts of it are off-screen sometimes (standard style).

[roddi]

Only problem is that when new info is available the notification usually gets bigger. It grows upwards and parts of it are off-screen sometimes (standard style).

Haven't seen http://trac.growl.info/changeset/3012

sorry
Roddi

[evands]

Timestamp: 09/01/05 09:23:15 (1 year ago)

*sigh* We've gotta get Growl trunk releasable.