Improved event notification

[jas8522]

This ticket is to cover better handling of events notification. Currently many events are able to be configured by the events preferences pane to speak, show a growl notification, pop up a dialog, etc. Sometimes these events are not specific enough and some events have a tendency to pop up dialogs no matter how they are configured in the events preferences, with no option to disable this in favor of growl (for example).

The objectives are as follows:

1. Subject every dialog notification to the events preferences to allow the option for dialog or growl or spoken, etc. or any combination of them. This assumes that there are no stray event dialogs that cannot be re-configured via the preferences.
2. Ensure that dialogs do not pop up in front of the message window (in case it is accidentally dismissed). If it appears below the message window, or above it, but not active, then the user can always still configure a growl notification to ensure they see it. In some cases a sticky growl notification and/or a dialog should perhaps be default configuration.
3. Events that could have multiple notifications should be handled with a single notification mechanism. For example, many emails should not result in many dialogs or many growl notifications, but one proclaiming the number of notifications of the type. This should tie in with another ticket that will soon be referenced here.
4. Error messages that present as dialog boxes should either be changed to a Pidgin/Skype style - where it appears in the contact list - or use Growl (or both) with customization from events pane in prefs yet again.

Refs: #7363 #6748 #6450 #80 #6059 #5531 #4964 #4265 #3977 #7834 #7747 #6148 #2779

Showing events in contact list refs: #9767 #6858 #3051 #1722 #208

[cbarrett]

This sounds like it's going to add quite a lot to the events preferences. We should figure out a way to streamline it -- perhaps we shouldn't show all of the events we support in a list? It's pretty intimidating. The UI for the "+" button doesn't have to be the same as the "edit" UI, either. Perhaps the add UI can make it a bit easier to find the event you want, and the edit UI can be streamlined to be more about editing an event.

It's been quite a while since the events prefs got some UI love.

[jas8522]

I've got no complaints for a redesign of the events pane, especially if it helps push this along considering how many people have requested these updates (particularly in the first point above). The tickets I references are only the remaining open ones - there were many others closed as dupes of those.

Last time I read about a redesign of the events pane it drew quite the argument though ;)

[jas8522]

Perhaps a simple method of cleaning it up would be to have event groups - wherein you would have a collapsable master type like "Errors" and "Communication", etc. (a way to prevent a complete rewrite at least). But then we run into the problem of having three levels of expansion making it possibly more confusing than it needs to be.

[DarTar]

It would be nice to have the ability to configure notifications on a per-account basis. I use an IM account for work, others just to talk with friends and it would be great to be able to activate growl notifications, say, for work conversations only.

[zacw]

(In [21566]) Separate events for "Message Received (Group Chat)" and "Message Received (Background Group Chat)". Refs #7923. Fixes #2260.

[zacw]

(In [21567]) Add a "Invites you to a group chat" event. Jabber chat invites don't work at the moment, and MSN crashes on connect, so I could only double-check the AIM invite string. :/ Also a small code cleanup for group chat events ala CFM. Refs #7923. Fixes #80.

[zacw]

I've checked most occurrences of -makeKeyAndOrderFront: (where focus-stealing occurs) -- I've nearly eliminated it from non-user-driven events.

[jpollock]

I wanted to stay abreast of this ticket and I know the approved way is to add one's username or email address to the cc: field, but that field doesn't appear editable. I know that adding a comment will cause me to stay in the loop, though. Just glad to see that the issue with duplicate notifications for new email (Adium dialog plus growl) is being addressed, although I wish the milestone were v1.3! :)

[almacrae]

I'm not sure a redesign of the events pane is necessary - standard behaviour for Growl-enabled apps is for the Growl notification to replace the "native" one - so I was surprised that after enabling Growl for email notification that the Adium dialog box was still appearing. I cant' see why anyone would want this redundancy.

[jas8522]

This ticket isn't about redesigning the events pane (which is covered with #35) so much as it is about:

1. Ensuring that all events are configurable entirely through the events prefpane (like you said, some events you cannot remove the dialog box for - if it were done properly, you would be able to)
2. Ensuring that the default set of actions attached to each event are appropriate at getting the users' attention. I believe that these are likely different depending on the event.
3. An enhancement request to add a sort of 'events bar' like what Pidgin has so as to place events like authorization requests, and email notifications in the bar (which would be a drop down of events - the top of which is the latest received event - or something similar). This would be so that events that have been dismissed can still be retrieved or something similar.

[Robby]

All the events tickets can be "handpicked" from "Good idea for 'later'".

[overhacked]

If you could just disable the annoying "must click to close it" new mail dialog, Adium would be a good drop-in replacement for the mail part of Google Notifier.

[zacw]

(In [26462]) Instead of creating a window for every authorization requests, create a central "Authorization Requests" window. This has a few toolbar items: Authorize, Authorize & Add, and Deny. Their icons are currently the SSL image, because I suck at art and I needed a placeholder. Another commit is going to add get info buttons, deny and block, and a few other things.

This basically behaves the same, except you can mass-select and right-click/toolbar things away, right-click and get info on a person who is doing a request, and several nice features. This uses the dict stored in the array as the UI handle for libpurple, which may or may not be a terrible idea. In my super limited testing this works really well.

Fixes #11454. Fixes #9104. Fixes #6716 (there's a maximum height per row for the requests). Refs #9250. Refs #9767. Refs #7923.

[gvlx]

Present status of this issue?

Does anyone knows if this is beeing worked and for which version?

Thank You.

[Robby]

This ticket is on the "Good idea for "later"" milestone because nobody is working on it.

[woodenbrain]

Yes please, especially for new mail notifications.

[jaynna]

The problem of multiple new mail notifications remaining open is becoming annoying enough that I am considering to stop using Adium. I often can have 10s of emails when I log in and I don't want to click a button for each one. There a way to configure Adium to only send one notification saying there are new emails and this notification does not necessary need to require a button click to close. And when a new mail comes in when I'm already logged in, I would prefer to only be able to get a notification that goes away automatically, not one that I have to click a button to go away. Basically, let me use Growl to configure these things :) and not be forced to deal with these default notifications.

This problem has been open for years. It is ridiculous for you guys to not have fixed it by now. You could give a simple quick fix of moving the default notification to the event page to allow it to be configurable and then address the bigger issues of "redoing" the events page. Rolling multiple issues into one bigger ticket slows down progress. This is not how software development is suppose to be done.

[woodenbrain]

Well put jaynna. While I got nothing but love for this effort, I finally had to switch back to iChat for this reason alone. Will be watching release notes.

[woodenbrain]

On a more constructive note, now that this is still open with 1.4b10 released, how bout at _least_ allow a new ticket for _specifically_ the new mail notification having a simple setting to use growl rather than a dialog? as jayna suggested, lumping it into one major project that nobody is even considering tackling is less than helpful. The specific issue of the new mail notification could be handled in about 15 minutes of coding.

[wixardy]

Replying to woodenbrain:

On a more constructive note, now that this is still open with 1.4b10 released, how bout at _least_ allow a new ticket for _specifically_ the new mail notification having a simple setting to use growl rather than a dialog? as jayna suggested, lumping it into one major project that nobody is even considering tackling is less than helpful. The specific issue of the new mail notification could be handled in about 15 minutes of coding.

1. That's not very constructive.
2. #13140 was created 3 days ago.
3. Spend the 15 minutes.

[woodenbrain]

Sorry, but I beg to differ. Every single ticket opened in the last 2 years related to this has been marked as a duplicate of this ticket (or possibly similar ones in the past), so suggesting it _not_ be marked as a duplicate is constructive. I'm sorry I didn't spend the 15 minutes to search for ticket #13140, but I didn't because I've spent more than that searching for such tickets in the past and they all refer to this one, so had rational reason not to do it again. Thank you for pointing out ticket #13140 and for not marking that as a duplicate.

[jas8522]

Replying to woodenbrain:

On a more constructive note, now that this is still open with 1.4b10 released, how bout at _least_ allow a new ticket for _specifically_ the new mail notification having a simple setting to use growl rather than a dialog? as jayna suggested, lumping it into one major project that nobody is even considering tackling is less than helpful. The specific issue of the new mail notification could be handled in about 15 minutes of coding.

As soon as someone decides to take on specific portions of this ticket, we can create a new ticket for that particular bug/feature for their development purposes. In the meantime, doing so would simply create a large number of disconnected tickets that are very difficult to track in a system filled with over 13000 tickets.

[woodenbrain]

jas... perhaps that logic is sound on one level. but i believe on another level it just isn't working. you end up creating one massive re-design project in order to address existing minor, easily fixed bugs? It's like not patching a leak in a roof for years because someday you'll replace the whole roof.

[Robby]

woodenbrain, by now you have spent at least the "15 minutes" you mentioned. Why don't you just submit a patch instead of beating a dead horse?

The major re-design was planned at one point, it has just been postponed. In the meantime, others things seem to be more important to the developers.

[zacw]

Adium has had, at maximum, a development force of about 2 developers at any given time for the past year or two. It would be nice to address something as annoying as the dialog+growl situation, but realistically it is a much more complicated fix than you're thinking (how would Adium know when not to display the dialog box? An option for the event?—Well, the event generating it doesn't actually inspect the event, it just fires, etc). Other things have higher priority.

[woodenbrain]

zacw, i completely understand that adium development is understaffed, and please don't get me wrong in this thread. I'm not expecting this issue to be fixed "before its time", only that its time would come faster if it weren't part of a much more massive project that no one is likely to tackle for a long time, and recognized as a bug not a new enhancement. if i personally had the time to learn how to contribute patches etc and delve into the source code, i would. i may still eventually but can't for some time. that said, it's hard to understand why this dialog+growl issue could be so complicated. In Preferences -> Accounts -> Options for hotmail there is already an option for "check new email". In Preferences -> events there are already multiple configurable options for "new email notification" including "display an alert" and "display a growl notification". So the fix would be to move the "display a dialog box" to the event notification options. otherwise never display the dialog box for mail. frankly i think many would be quite happy if Adium didn't even do that -- if Adium simply just never displayed a dialog box and let the event notification options handle it, even _sans_ dialog box. in short, the provisional fix is just don't show the dialog ever.

[jas8522]

Replying to woodenbrain:

zacw, i completely understand that adium development is understaffed, and please don't get me wrong in this thread. I'm not expecting this issue to be fixed "before its time", only that its time would come faster if it weren't part of a much more massive project that no one is likely to tackle for a long time, and recognized as a bug not a new enhancement. if i personally had the time to learn how to contribute patches etc and delve into the source code, i would. i may still eventually but can't for some time. that said, it's hard to understand why this dialog+growl issue could be so complicated. In Preferences -> Accounts -> Options for hotmail there is already an option for "check new email". In Preferences -> events there are already multiple configurable options for "new email notification" including "display an alert" and "display a growl notification". So the fix would be to move the "display a dialog box" to the event notification options. otherwise never display the dialog box for mail. frankly i think many would be quite happy if Adium didn't even do that -- if Adium simply just never displayed a dialog box and let the event notification options handle it, even _sans_ dialog box. in short, the provisional fix is just don't show the dialog ever.

You have now heard from one of the two lead developers on this project that the solution to your supposedly simply problem is not so simple, and yet you continue to argue. Please, either learn Cocoa so that you can take in the huge Adium codebase and create your own patch, or sit back and let our developers do their work without your whining.

If you really want to use the roof analogy, then no contractor would have a single item on the to-do list for each 5 foot section of roof, when the entire thing is one job to be done of a list of repairs for the entire house. They would have the roof as one job, the kitchen as another, the bathroom, etc. At the time each is tackled, those doing the work would then break it up into their respective elements. That is exactly what we're doing here.

When you (or another developer) have an initial patch to submit for that particular bug, go ahead and create that new ticket and we'll scratch it off the list here. Until then, the conversation on the matter is not up for debate.

[Zachary West <zacw@…>]

(In  46addf808752) Add a hidden default "AINoNewMailWindow" which prevents the "new mail" dialog from opening. Refs #7923.

To disable new mail window:

defaults write com.adiumx.adiumx AINoNewMailWindow -BOOL yes

To re-enable new mail window:

defaults delete com.adiumx.adiumx AINoNewMailWindow

[Zachary West <zacw@…>]

(In  a79db9a3f818) Add a hidden default "AINoNewMailWindow" which prevents the "new mail" dialog from opening. Refs #7923.

To disable new mail window:

defaults write com.adiumx.adiumx AINoNewMailWindow -BOOL yes

To re-enable new mail window:

defaults delete com.adiumx.adiumx AINoNewMailWindow

[zacw]

That's the best you're going to see on the dialog front until we can address it better. Sorry.

[woodenbrain]

Replying to zacw:

That's the best you're going to see on the dialog front until we can address it better. Sorry.

thank you kindly. no need to apologize at all. in fact, this is pretty much exactly the simple fix I was talking about, and the ideal provisional solution until the ambitious events notification revamp project is someday tackled. thanks for listening. look forward to it in a coming beta, and to finally being able to use Adium instead of iChat. Cheers.

[jaynna]

Woodbrain - I second your comment. It's great to see something going in!

Zach - I actually tried to add in the default now just for kicks and the "-bool yes" is not valid. I got "-bool true" to work though. Maybe there something else I need to configure but thought I'd give you a heads. :)

Again...can't wait to get the update with this fix in it!

Replying to Zachary West <zacw@…>:

(In  a79db9a3f818) Add a hidden default "AINoNewMailWindow" which prevents the "new mail" dialog from opening. Refs #7923. To disable new mail window: defaults write com.adiumx.adiumx AINoNewMailWindow -BOOL yes

[zacw]

Sorry, it needs to be "-bool YES" — I swapped the capitalization when I wrote the commit message.

[jaynna]

The default write worked when I tried with the "-bool YES"...

THANKS for getting this in!!!!

[assetburned]

it looks like that these tickets could be also related to this one:
 http://trac.adium.im/ticket/8771 Customise Growl notifications
 http://trac.adium.im/ticket/9920 Timestamp on Growl notifications