search

trikon / growl

Automatically exported from code.google.com/p/growl
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

Disable notification forwarding #284

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
What feature or enhancement do you propose?

Ability to disable forwarding per Application/Notification

What problem does it solve/What benefit does it provide?

There are likely use cases where you would always want to keep a notification 
only on the local machine, and not blast it out to other machines. For example, 
a library that growls the results of running unit tests.

Original issue reported on code.google.com by kungfudi...@gmail.com on 23 Sep 2011 at 4:18

GoogleCodeExporter commented 8 years ago 
That gives me an idea: It might be as good, if not better, to have *en*abling 
forwarding be a per-application setting. Have a tri-state switch for main 
forwarding (fully off, off except for specific apps, on except for specific 
apps) and for each app (respect the main forwarding switch, always forward 
[unless fully off], or never forward).

I leave it to the Growl developers to think of better wording for each of the 
switches' states.

Original comment by boredzo on 23 Sep 2011 at 4:28

GoogleCodeExporter commented 8 years ago 
This would have to wait until at least 1.4, maybe later than that with the 
forwarding changes planned. Not a bad idea though.

Original comment by ch...@growl.info on 23 Sep 2011 at 4:56

GoogleCodeExporter commented 8 years ago

Original comment by ch...@growl.info on 19 Jan 2012 at 10:11

GoogleCodeExporter commented 8 years ago 
Growl 2.0 will be adding an action API.  While network forwarding has largely 
been segregated out from GAC even in 1.4, it is not entirely ready to be turned 
into a plugin just yet.  We need to resolve what to do about global forwarding 
vs ticket specific forwarding.  We could easily eliminate the forwarding 
section in networking entirely, and move it all into the plugin, this would 
make resolution of which computers to send to easier, but still not entirely 
trouble free.  Action's allow multiple configurations, and there is the option 
to do a ticket's parent's actions in addition to a tickets own actions.  While 
action set resolution means we won't do the same action configuration twice, 
network forwarding configurations could have overlapping selected hosts.

Original comment by dan...@growl.info on 22 Mar 2012 at 3:21

GoogleCodeExporter commented 8 years ago 
I would also think that our subscription solution introduced in 1.4 would be 
better than straight forwarding on this. What do you think kfdm?

Original comment by ch...@growl.info on 21 Jun 2012 at 3:55

GoogleCodeExporter commented 8 years ago 
I think there's still a valid case for being able to disable forwarding for 
notifications on the "host" system.

I typically work on my main "host" system but sometimes work on a laptop which 
has subscribed to notifications. However there may be certain notifications 
that I know I never want sent to my laptop. While I could disable these 
notifications from the laptop, this is something that I would need to set on 
every subscribed computer. Prior to disabling them, I may temporarily fill up 
my history with messages I'm not interested in forwarding (usually when running 
through the automated tests of the python gntp library I generate a lot of 
messages)

Since there is a workaround, I think it's fine to leave this ticket as a low 
priority item, though I think being able to disable forwarding of certain 
messages from the host side should be implemented to consider the various usage 
scenarios complete.

Original comment by kungfudi...@gmail.com on 21 Jun 2012 at 9:44

GoogleCodeExporter commented 8 years ago

Original comment by ch...@growl.info on 18 Jul 2012 at 5:07

GoogleCodeExporter commented 8 years ago

Original comment by ch...@growl.info on 2 Oct 2012 at 8:43

GoogleCodeExporter commented 8 years ago 
Rules based scripting coming in 2.1 will improve this, as it will have per 
individual note ability to disable sending to network, or subscribers, although 
it won't provide any direct UI for doing so.

Original comment by dan...@growl.info on 9 Oct 2012 at 4:48

GoogleCodeExporter commented 8 years ago 
I feel rules based scripting ultimately provides a good (if not the best) 
solution to this, without requiring a rethink of how to prevent duplicates in 
the global vs action, or one action config vs another situations.  Rules 
provides enable/disable, but also the ability to send to specific hosts and not 
others (based on a list of entry ID's).  Flagging as fixed in source, while it 
doesn't provide a UI for it, likely most users who want this extra level of 
customization can write a little applescript.

Original comment by dan...@growl.info on 4 Dec 2012 at 3:44