growlnotify --url doesn't seem to work
73 views
Skip to first unread message
Eugene Burmako
Nov 17, 2012, 4:26:47 AM11/17/12
to Growl Discuss
Similar problems with click callbacks not working have been discussed
on this message board, and some of those problems have fixes, but I
didn't have any luck with this particular one.
The problem is as simple as the title of the message says. Every time
I call growlnotify with an --url argument, clicking on the
notification does nothing. It doesn't matter whether I use native
growl notifications or notification center forwarding - clicks won't
work either way. Versions: Mountain Lion 10.8.2, Growl 2.0 from the
App Store, growlnotify 2.0.
I'd imagine that growlnotify 2.0 wouldn't be incompatible with growl
2.0, but I still tried opening Growl Version Detective as suggested in
neighboring threads. Apparently the detective doesn't show growlnotify
in the list of apps, so it looks like it's not going to help here.
on this message board, and some of those problems have fixes, but I
didn't have any luck with this particular one.
The problem is as simple as the title of the message says. Every time
I call growlnotify with an --url argument, clicking on the
notification does nothing. It doesn't matter whether I use native
growl notifications or notification center forwarding - clicks won't
work either way. Versions: Mountain Lion 10.8.2, Growl 2.0 from the
App Store, growlnotify 2.0.
I'd imagine that growlnotify 2.0 wouldn't be incompatible with growl
2.0, but I still tried opening Growl Version Detective as suggested in
neighboring threads. Apparently the detective doesn't show growlnotify
in the list of apps, so it looks like it's not going to help here.
Daniel Siemer
Nov 17, 2012, 3:31:35 PM11/17/12
to Growl Discuss
Hello, so first GrowlNotify doesn't use the framework since its a
single file command line utility, so it wont show in GVD.
My simple local tests show it as working fine using http://growl.info
opens in the default browser, file:///Applications shows in finder,
and specific files get opened with their default apps. Further
testing shows that we have a couple scenarios where it might fail,
both with workarounds. First are relative URL's (either user relative
or environment relative), passing absolute URL's will be more
reliable, especially since the URL is opened in Growl's environment,
not GrowlNotify's. Second is spaces (and other special characters),
we don't put in % escapes before trying to make the URL to open, and
the workaround make sure your URL's are % escaped for UTF8 before
sending them to GrowlNotify.
This is a very different issue from click feedback timing out, and I
have created a ticket on the % escape issue http://code.google.com/p/growl/issues/detail?id=555
for the purpose of making sure this doesn't slip through the cracks.
Both growl (on attempt to use a URL from that gntp header) and
GrowlNotify (before sending it out) should be working to ensure that
the URL we try to create/open is valid.
single file command line utility, so it wont show in GVD.
My simple local tests show it as working fine using http://growl.info
opens in the default browser, file:///Applications shows in finder,
and specific files get opened with their default apps. Further
testing shows that we have a couple scenarios where it might fail,
both with workarounds. First are relative URL's (either user relative
or environment relative), passing absolute URL's will be more
reliable, especially since the URL is opened in Growl's environment,
not GrowlNotify's. Second is spaces (and other special characters),
we don't put in % escapes before trying to make the URL to open, and
the workaround make sure your URL's are % escaped for UTF8 before
sending them to GrowlNotify.
This is a very different issue from click feedback timing out, and I
have created a ticket on the % escape issue http://code.google.com/p/growl/issues/detail?id=555
for the purpose of making sure this doesn't slip through the cracks.
Both growl (on attempt to use a URL from that gntp header) and
GrowlNotify (before sending it out) should be working to ensure that
the URL we try to create/open is valid.
Eugene Burmako
Nov 18, 2012, 3:00:39 AM11/18/12
to Growl Discuss
Thanks for a swift response!
I can confirm that --url works as you described, though there's a
peculiarity (or a bug, don't know how to classify it), which led me
thinking that it doesn't.
growlnotify -m foo --url www.google.com => Nothing happens on click
growlnotify -m foo --url http://www.google.com => Correct behavior
On Nov 17, 9:31 pm, Daniel Siemer <dan...@growl.info> wrote:
> Hello, so first GrowlNotify doesn't use the framework since its a
> single file command line utility, so it wont show in GVD.
>
> My simple local tests show it as working fine usinghttp://growl.info
I can confirm that --url works as you described, though there's a
peculiarity (or a bug, don't know how to classify it), which led me
thinking that it doesn't.
growlnotify -m foo --url www.google.com => Nothing happens on click
growlnotify -m foo --url http://www.google.com => Correct behavior
On Nov 17, 9:31 pm, Daniel Siemer <dan...@growl.info> wrote:
> Hello, so first GrowlNotify doesn't use the framework since its a
> single file command line utility, so it wont show in GVD.
>
> opens in the default browser, file:///Applications shows in finder,
> and specific files get opened with their default apps. Further
> testing shows that we have a couple scenarios where it might fail,
> both with workarounds. First are relative URL's (either user relative
> or environment relative), passing absolute URL's will be more
> reliable, especially since the URL is opened in Growl's environment,
> not GrowlNotify's. Second is spaces (and other special characters),
> we don't put in % escapes before trying to make the URL to open, and
> the workaround make sure your URL's are % escaped for UTF8 before
> sending them to GrowlNotify.
>
> This is a very different issue from click feedback timing out, and I
> have created a ticket on the % escape issuehttp://code.google.com/p/growl/issues/detail?id=555
> and specific files get opened with their default apps. Further
> testing shows that we have a couple scenarios where it might fail,
> both with workarounds. First are relative URL's (either user relative
> or environment relative), passing absolute URL's will be more
> reliable, especially since the URL is opened in Growl's environment,
> not GrowlNotify's. Second is spaces (and other special characters),
> we don't put in % escapes before trying to make the URL to open, and
> the workaround make sure your URL's are % escaped for UTF8 before
> sending them to GrowlNotify.
>
> This is a very different issue from click feedback timing out, and I
Daniel Siemer
Nov 18, 2012, 1:04:08 PM11/18/12
to Growl Discuss
http:// is technically part of a valid URL, whether your browser
requires it be entered or not. We don't presently make any
assumptions about what scheme a URL should be if it doesn't have one,
and doing so might be problematic.
On Nov 18, 2:00 am, Eugene Burmako <xeno...@gmail.com> wrote:
> Thanks for a swift response!
>
> I can confirm that --url works as you described, though there's a
> peculiarity (or a bug, don't know how to classify it), which led me
> thinking that it doesn't.
>
> growlnotify -m foo --urlwww.google.com=> Nothing happens on click
> growlnotify -m foo --urlhttp://www.google.com=> Correct behavior
requires it be entered or not. We don't presently make any
assumptions about what scheme a URL should be if it doesn't have one,
and doing so might be problematic.
On Nov 18, 2:00 am, Eugene Burmako <xeno...@gmail.com> wrote:
> Thanks for a swift response!
>
> I can confirm that --url works as you described, though there's a
> peculiarity (or a bug, don't know how to classify it), which led me
> thinking that it doesn't.
>
> growlnotify -m foo --urlhttp://www.google.com=> Correct behavior
Reply all
Reply to author
Forward
0 new messages