(In reply to comment #0)
>     - Need to be able to activate specific chat windows/tabs on demand

This should be done by calling EnsureChannel on the ChannelDispatcher. The channel will be re-dispatched and Empathy should present it.

(In reply to comment #0)
>     - shared chat logs (probably fixed by bug 518414)

I thought this was fixed in Fedora 13 at first, but it seems not to be. I think the problem is that telepathy-logger is its own package, and so we need to package and install that?

Created attachment 158208 [details] [review]
telepathyClient: activate Empathy on source icon click

Use the ChannelDispatcher to open a conversation in Empathy when the
user clicks on that conversation's icon in the message tray summary
area.

(In reply to comment #2)
> (In reply to comment #0)
> >     - shared chat logs (probably fixed by bug 518414)
> 
> I thought this was fixed in Fedora 13 at first, but it seems not to be. I think
> the problem is that telepathy-logger is its own package, and so we need to
> package and install that?

Ah, telepathy-logger was intended for 2.32 and is not yet stable. So this doesn't work right in GNOME 2.30 either :-/

Review of attachment 158208 [details] [review]:

The code seems to make sense, but it doesn't always work as expected for me. While it sometimes brings the chat window up, other times it doesn't, but instead shows a notification saying '<The nick of the person chatting with me> is ready'. It brings the chat window up if I click on the icon in that notification. I'm going to attach a screenshot that shows this notification.

Also, as you can see in the screenshot, it has '-Disconnected' and '-Connected' text in the Empathy window each time I click on the notification icon. I think that happens because we call this._channel.CloseRemote() on our end in _gotChannelRequest().

Do all these problems need to be solved in the Empathy code? I wanted to see if passing true for 'org.freedesktop.Telepathy.Channel.Requested' as a channel property in ChannelDispatcher::EnsureChannel() to signal that the request was made locally made any difference, but it seemed to just make the clicking not work at all. Not sure if this was the right use-case for this property.

Created attachment 158775 [details]
Screenshot of what happens when I click on the icon in chat notification

Sometimes I get the notification about the sender being ready to chat instead of the chat window being brought forward. It is brought forward if I click on the icon in that notification.

You can also see '-Disconnected' and '-Connected' text in the Empathy window that shows up when the chat notification icon is clicked.

(In reply to comment #5)
> While it sometimes brings the chat window up, other times it doesn't, but
> instead shows a notification saying '<The nick of the person chatting with me>
> is ready'.

Yeah, that's focus-stealing prevention, which shouldn't be happening, since we're passing a correct timestamp...

> Also, as you can see in the screenshot, it has '-Disconnected' and '-Connected'
> text in the Empathy window each time I click on the notification icon. I think
> that happens because we call this._channel.CloseRemote() on our end in
> _gotChannelRequest().

Yes. If we remove the Approver (or change it to dispatch channels to empathy rather than claiming them itself) then this problem and the empathy-doesn't-log-conversations problem both go away, but then you have the empathy-annoying-you-with-its-icon problem. But we're probably going to have to do this way and figure out some other way to deal with the icon.

filed bug 615976 about empathy not using the timestamp from the D-Bus call, and thus getting focus-stealing-prevented

Created attachment 158913 [details] [review]
telepathyClient: improve Empathy interaction

Activate empathy when clicking on a chat icon by asking the
ChannelDispatcher to open the conversation in the default handler.

Also, don't Claim channels in the Aprover for now, since until
telepathy-logger is stable, this means Empathy won't see (and log)
those conversations. This means that empathy's blinky status icon is
back; we'll have to do something else about that.

Review of attachment 158913 [details] [review]:

The code looks good, except should all the handler related stuff be removed? There are several places:

1) The comment above the Client class.
2) Telepathy.CLIENT_HANDLER_NAME in Interfaces()
3) HandlerChannelFilter() and HandleChannels()
4) DBus.conformExport(Client.prototype, Telepathy.ClientHandlerIface);

The clicking doesn't work for me with this patch (even if I remove the handler code bits and add CHAT_APPLICATION_NAME for the Preferred_Handler in EnsureChannelRemote()). It gets into _gotChannelRequest(), but the chat window is not raised. Adding back ClaimRemote() and CloseRemote() along with CHAT_APPLICATION_NAME for the Preferred_Handler makes the clicking work again (so that's what the original patch had).

The Empathy icon does in fact blink with the new patch.

I can upgrade to F13 next week and see if that changes the behavior of this patch.

I've got some problems with gnome-shell/empathy. When someone contacts me i can chat from gnome-shell, and this is right, but if I close the box and try to open a conversation in empathy with that very contact nothing happens. I can click and open a conversation with everybody else in the contact list but not if someone contacted me first, i'm stuck with gnome-shell bottom box (which, btw, lacks of a counter for unread messages)

Attachment 158913 [details] pushed as 2bd64b6 - telepathyClient: improve Empathy interaction

(In reply to comment #10)
> The code looks good, except should all the handler related stuff be removed?

yup, did that before pushing.

*** Bug 617688 has been marked as a duplicate of this bug. ***

Hi everybody,

I checked out the last git changes and now Empathy shows notification for new messages, however in order to see them in the shell I have to give a shell restart in the run command (more details in the bug 617688, which is marked as a duplicate).

At least now I can see the new messages, however it would be better if they showed up in the message area. Note that this problem happens on Arch Liux, while the Ricotz PPA on Lucid seems to work fine.

Tell me if it's needed how can I provide more information.

Cheers,
Alessandro