I wanted this for my use case, thought it may be useful to others. #29

Merged
merged 2 commits into from Feb 6, 2012

Projects

None yet

2 participants

@HenrikJoreteg
Contributor

If you don't want it, or wanna do it differently, no worries.

@tj
Member
tj commented Feb 6, 2012

we have .closable() which emits an event

@HenrikJoreteg
Contributor

Ok, so how would you suggest handling the case where a user is trying
to take action on a notification, not close it?

For example when you click a normal desktop Growl notification it
usually takes you to that app and whatever is relevant to the
notification.

On Feb 6, 2012, at 8:23, TJ Holowaychuk
reply@reply.github.com
wrote:

we have .closable() which emits an event


Reply to this email directly or view it on GitHub:
#29 (comment)

@tj
Member
tj commented Feb 6, 2012

ah I see, I've never clicked a growl notification before. I guess we could just have .on('click' though even from a UX point of view that's not obvious IMO, a link in the notification or something would be better

@HenrikJoreteg
Contributor

Well, I agree from a UX perspective that it may not be obvious, but part of that depends on how the notifications are styled. I've got a web app that use Growl if available (if running as a Fluid app or desktop-wrapped app) and I'm planning on using UI kit notifications as a fallback for that. So for me, it's be great if I could supply similar options.

I agree with what you're saying using the .on('click') api. I updated the pull request.

Anyway, I can just do what I've already done, but I think it'd be cool if this behavior (in some form) existed in the lib itself. Cheers!

@tj
Member
tj commented Feb 6, 2012

cool thanks I'll take the updated version

@tj tj merged commit 8358a21 into visionmedia:master Feb 6, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment