Click feedback in growlnotify

[GoogleCodeExporter]

What feature or enhancement do you propose?
growlnotify should use its exit status to report whether a notification was 
clicked or closed or timed 
out.

What problem does it solve/What benefit does it provide?
Programs that currently use growlnotify to send notifications currently cannot 
determine whether 
the user clicked the notification, the user closed it, or it faded out on its 
own.

This would be much more useful in conjunction with the -w/--wait (sticky) 
option.

Original issue reported on code.google.com by prhgr...@gmail.com on 3 May 2010 at 1:43

[GoogleCodeExporter]

We'd need to be able to provide a way for growlnotify to do something with the 
clickback notification from Growl.

Original comment by chrisf.g...@gmail.com on 3 May 2010 at 4:51

[GoogleCodeExporter]

I think this could be very useful even without that. Please see the thread

http://groups.google.com/group/growldiscuss/browse_thread/thread/486fc7fe089f9ed
8/87504a7a822e14a9?show_docid=87504a7a822e14a9

Original comment by lennart....@gmail.com on 3 May 2010 at 7:54

[GoogleCodeExporter]

Making growlnotify to accept a callback command could also do,
but making it provide an exit code with --wait seems enough for me.

I thought I could use growlnotify with just a few lines of shell script,
to show up a bubble, "Break Time!" regularly and start the screensaver (for my 
health :)
but there's no way I can determine whether the bubble was timed out or 
dismissed.
Maybe I should use --wait --stick and do something if I actually click the 
bubble, until this issue is resolved. 
(--identifier seems useful for this kind of workaround)

Original comment by jaeho.shin on 17 May 2010 at 5:53

[GoogleCodeExporter]

I've looked into growlnotify's code myself and figured out how to distinguish 
between clicks and time-
out/closing actions.  See the attached file holding my hg export tip's output.  
(I'm not used to Mercurial, but 
seems it contains all my changes anyway :)

Remaining Issues:
1. I'm not sure whether introducing a new option argument would be better 
rather than changing the previous 
behavior of --wait.
2. I don't know whether Growl can tell us the difference between user actually 
closing the message (with the X 
button), and timing out.  If it can, then we should use different exit codes 
for those two results.  For the 
moment, I just wanted to minimize the number of lines I had to change or add.

Original comment by jaeho.shin on 24 May 2010 at 4:59

Attachments:

• growlnotify-wait-exitcode.hgexport.txt

[GoogleCodeExporter]

If this gets fixed I would glad to be notified, but I do not know how to get a 
notification of it. Is there anyone who knows that?

Original comment by lennart....@gmail.com on 9 Jul 2010 at 12:33

[GoogleCodeExporter]

Eh, sorry. I have to "star" the issue to get notifications. (And I have already 
done that.)

Original comment by lennart....@gmail.com on 9 Jul 2010 at 12:37

[GoogleCodeExporter]

This has a patch, sort of. First, let's get a proper patch, and then let's 
review the patch.

Original comment by chrisf.g...@gmail.com on 15 Mar 2011 at 5:43

• Added labels: Milestone-1.3

[GoogleCodeExporter]

My patch was a fast hack aiming minimal change to the code, so it's ugly. (uses 
global variable!)
However, considering growlnotify's small size, the ugliness might not be a big 
problem.
Well, I'm not sure. The code owner should decide whether he/she wants to do it 
in a more clean fashion :)

FYI I've been enjoying my patch for about a year now. It works fine.

Original comment by jaeho.shin on 19 Mar 2011 at 10:59

[GoogleCodeExporter]

I've confirmed Jaeho's change. It works great!

Original comment by jjan...@gmail.com on 27 May 2011 at 2:53

[GoogleCodeExporter]

Original comment by chrisf.g...@gmail.com on 9 Jul 2011 at 6:19

[GoogleCodeExporter]

I'm not sure that I have the same problem.  I'm trying to extend the 
user-interface of a ksh shell script to another user on macOs, and using 
growlnotify -sw -H localhost.

Growlnotify -sw is sticky and waits as expected.  With -H, it is still sticky, 
but doesn't wait.

growl 1.2.2; macOs 10.6.8

Original comment by james.fr...@gmail.com on 16 Jul 2011 at 3:08

[GoogleCodeExporter]

james (#11): That has nothing to do with this request.

Original comment by p...@growl.info on 16 Jul 2011 at 3:11

[GoogleCodeExporter]

p...(#12): Ok.  Is there a different issue, that you know of, that covers my 
symptoms?

Original comment by james.fr...@gmail.com on 17 Jul 2011 at 1:34

[GoogleCodeExporter]

james: Nope. You should email the discussion group.

Original comment by p...@growl.info on 17 Jul 2011 at 2:54

[GoogleCodeExporter]

Changing the owner on these to get them out of Peter's queue.

Original comment by chrisf.g...@gmail.com on 15 Aug 2011 at 6:49

[GoogleCodeExporter]

Original comment by chrisf.g...@gmail.com on 22 Aug 2011 at 3:45

• Added labels: Milestone-1.4
• Removed labels: Milestone-1.3

[GoogleCodeExporter]

So what ever happened to this?  Is it in growl 1.4 and I'm just missing the cli 
flag to send, or has it not been implemented yet?  

Original comment by iNinjas....@gmail.com on 2 Sep 2011 at 9:05

[GoogleCodeExporter]

1.4 has not been started on. Until this ticket is marked as "fixedinsource" 
instead of "new" in the status, then growlnotify does not have this implemented.

Original comment by chrisf.g...@gmail.com on 3 Sep 2011 at 12:38

[GoogleCodeExporter]

The switch to GNTP for GrowlNotify in issue #245 came with the added benefit of 
doing this.  We now return 2 on clicked, and 0 on close or timeout with -w.  
There is a timeout on read (10 seconds) presently, but this is done in source.  

Original comment by dan...@growl.info on 14 Sep 2011 at 8:53

• Changed state: FixedInSource