so the fact that they were disappearing at all before was a bug.

the current behavior is that they remain in the tray until you click them to remove them. should they disappear automatically after a while instead?

Created attachment 160882 [details] [review]
Add basic conversation timeout

I'm not entirely sure this is working correctly, and the messagebar seems to stick around after conversations go away.  I think I should probably add postponing the timeout if the notification is shown when the timeout wants to delete it.

Review of attachment 160882 [details] [review]:

The commit message will need to have more detail. See http://lists.cairographics.org/archives/cairo/2008-September/015092.html for explanation.

We need to extend the timeout every time in _messageReceived() and in respond().

We also need to not remove the icon for as long as the Empathy window is open and hold off removing it for the timeout period after it was closed. Both are tricky.

1) Don't remove the icon for as long as the Empathy window is open

It appears that we won't know if the user opened an Empathy window on their own to start the conversation. We'll only know if we got it to open in clicked(). At the very least, we can not close the window in that case.

2) Hold off removing the icon for the timeout period after the Empathy window was closed

We get the 'Closed' signal for the channel in this case, so it's not hard to actually set the timeout in _channelClosed() and not call this.destroy() there. The tricky part is that we need to disconnect/set to null everything that related to the old channel and then re-create it if the user tries to send a new message (i.e. when we get into respond()). I suppose it's fine to assume that connPath and channelPath will be the same and keep them around, but it seems that we need to call EnsureChannel() and Proceed() like we do in clicked()/_gotChannelRequest() in order to be able to recreate this._channelText that we can use to send the message. Of course making these calls pops up an Empathy chat window that we don't want, but we can't just create a channel ourselves because we only implement an observer. There is also a possible issue of queueing multiple messages because of the asynchronous calls.

I think it's ok to wait on this part before we move to telepathy-glib, which will possibly happen next week, and then we'll figure out the best behavior we can implement.

::: js/ui/telepathyClient.js
@@ +21,3 @@
 const SCROLLBACK_IDLE_LENGTH = 5;
 
+const CONVERSATION_IDLE_TIME = 1 * 60;

This should be 5 minutes. (Of course it's ok to use shorter time for testing.)

@@ +424,3 @@
+        if (this._conversationIdleTimeout != 0)
+            Mainloop.source_remove(this._conversationIdleTimeout);
+        this.emit('destroy');

It's better to call MessageTray.Source.prototype.destroy.call(this); here rather than emitting 'destroy' ourselves.

there's a flip side of this too, mentioned in bug 611613, which is handling "So and so has logged in" messages from people. In that case, we want to create a new source for the user, but have it disappear after a while if you don't try to talk to them. So basically, we need to be able to have sources that are separate from channels

The message tray is no more, design for notifications changed a lot. Closing this as obsolete, feel free to reopen if you can explain how that's still needed.