Feature request, url's

[aequitas]

Would it be possible to add a option to pass an url to a growl message?

The url would then be called when the growl notify is clicked.

This way is it is possible to bind any action to a growl notify.

Image url's like: applescript://path_to_AS, shellscript://path_to_script, app://applicationname. etc besides the normal http://, ftp://,smb://, etc url's.

These url's could be bound to any handler. For example a simple application which runs the script givin in the url.

With this mechanisch it would be possible to do every kind of action when clicking a growl notify.

Later this feature could be expanded with clickable buttons inside the notify window or url's inside the notify window that could be clickable.

[bgannin]

You can specify a click handler for a notification, and the click handler itself should handle the URL behavior. Adding specific behavior such as this for the notification is overkill because the action of clicking should be defined by the notification-posting agent, not Growl overall.

[bgannin]

If you are referencing passing messages to growlnotify, then the possibility would exist for adding a URL-handling capacity and method signature extension for this. As to a button added to notifications, that part's still a no-go.

[aequitas]

You can specify a click handler for a notification, and the click handler itself should handle the URL behavior.

The application that gives the notification should always have a handler installed. Suppose i want a shell script to notify me and attach a click action to the notify. Or if i have a network server which sends notify's of uploaded files and i could pass the (nfs) url of the containing folder. If you could just pass a url that would be executed by the system it possible to let it do just anything.

As to a button added to notifications, that part's still a no-go.

Could i ask why this is not possible? It would be ideal to add some default default icons (like a close, reload, open, open folder), not any kind of button, just a few common.
These could get a action (url) assigned (else they are not shown.
Your could then click on a button to open or remove mail instantly or press a retry button to restart something that send a notify it failed.
Using this combined with url's would make growl a ideal frontend for a lot of task which normale requery other applications to run constantly.

For example mail. If you don't want mail to constant using memory just sitting there and waiting for new mail, you could build a little script which checks for mail. Then would notify for the new message and give the option to delete it right away (spam), open it in mail, or dismiss the notify.

[bgannin]

Notifications are meant for informational purposes, not complex workflows. Such a modification would require every display style to be modified, or would require a custom display style, not to mention the other necessary mechanism changes throughout Growl.

[The_Tick]

We want to keep Growl notifications as simple as possible. As such, no buttons.

Growl is designed to let the application know there was a clickback, nothing more. We're not changing that design.

[bgannin]

The application that gives the notification should always have a handler installed. Suppose i want a shell script to notify me and attach a click action to the notify. Or if i have a network server which sends notify's of uploaded files and i could pass the (nfs) url of the containing folder. If you could just pass a url that would be executed by the system it possible to let it do just anything.

Allowing auto-execution of something is a possible security hole, and opening up avenues for execution outside strictly defined terms isn't good. Example: Safari's auto-processing of downloaded files can open a maliciously crafted DMG to exploit the recently published vulnerability. Your proposition would effectively do the same.

[aequitas]

Growl is designed to let the application know there was a clickback, nothing more. We're not changing that design.

To bad, i think it would be a feature to make growl usefull for many things other than just notification.

Allowing auto-execution of something is a possible security hole, and opening up avenues for execution outside strictly defined terms isn't good. Example: Safari's auto-processing of downloaded files can open a maliciously crafted DMG to exploit the recently published vulnerability. Your proposition would effectively do the same.

I am not referring to auto execution. The user still has to click the notify to execute the url. So the risk would be the same in the safari case.
Also it is easy to put a yes/no dialog in before url execution. This could optionaly be turned of for known safe application's.

I just think a url methode is easier to implement and more flexeble than a handler system.


I don't have enought experience on mac programming so i am not able to implement it myself. But a easy way to execute the url would be to use the build in 'open' call to launch the url. The system will figure out what to do with it.

[bgannin]

The path of execution still exists whether you add a prompt, safe list, or any other pseudo-mechanism for 'safety'. The method of exposure, URL handling, is still being presented and still opens more of a can of worms than it provides a handy solution.

As to how to implement it, it's not that coding it is hard - I could have such a setup done in under a half hour for Growl or growlnotify, it's a matter of the already noted issues by myself and Tick.