Hmm, I think I have some leads on the double chat rooms issue. First, see bug 619874 "backlog in chat rooms seems broken".

I just noticed that the first instances of "room@server" in the list only include messages that have "room@server" as the sender. IOW that log looks like this:

room@server: nearly home, g'night all
room@server: night ross
room@server: hot shit
room@server: i've got some really crappy g-i for libebook
room@server: but now, i think swim and hometime


The second instance of each chat room in the list on the left contains only messages from "real people".

Thanks Jussi for this very detailed report. You're right the log viewer doesn't currently offer a great user experience. It came from the old Gossip time and we should probably redesign it.

As your report contains interesting feedback I propose to use this bug to track discussion about the new design.

Nick: any chance you could find some time to propose a new UI? :)

When redesigning we should keep in mind the following bugs:

Bug #573652 - Display current username beside the id in the log viewer
Bug #578125 - No way to list recent chats
Bug #596737 - No obvious way to view all the history
Bug #598904 - Log viewer should show an account-independent calendar
Bug #599188 - Add a timeline to display/search logs 
Bug #612446 - Log Viewer: search bars are not coherent

Guillaume: I'm trying to find some time to think of a new UI - but it's currently behind trying to make video chat better in my free time. I might get lucky though. Thanks for the helpful list of bugs to bear in mind, I'll give them a mull through.

(In reply to comment #3)
> Guillaume: I'm trying to find some time to think of a new UI - but it's
> currently behind trying to make video chat better in my free time.

Oh great! Please open a VoIP bug to discuss your design ideas or ask any question. Hopefully, Empathy should gain support for > 2 users audio/video code soonish, that's probably something to keep in mind while redesigning the audio/video UI.

As suggested in bug #635259, it could be handy to be able to initiate chats from the log viewer.

Created attachment 176598 [details]
History sketch

I'm back with horrible designs! Well hopefully not that horrible...

This sketch shows how I think the new event viewer could be. I've got rid of the calendar since I don't find it very useful and an ordered list sounds better to me. The new window has three parts:

* A search bar at the top, where you can search for anything (when the combobox is at "All", which would be the default"), for all the events of a particular contacts (if the combobox is at Contacts), or for other things I haven't thought off (maybe specific event types, like SMS/Calls/Voicemail/Chats) just by selecting them. It would be a live search (search as you type), so no need for a search button. There's a "clean" button on the right, as it's usual in search bars.

* A list view in the middle, with all the events ordered by date. If you haven't searched for anything, then all the events are displayed. Each row shows the event type, the participants (not counting yourself) and the date. I'm not sure we can currently show all the participants for chat rooms though, since I think they have names like "private-chat-730830202". If it's not possible we should fix it to display it nicely. The displayed names are the contact aliases, and if you hover the mouse over them, we show the id in a tooltip (see bug 573652).

* The selected event on the bottom. If it's a chat/room/sms, it shows the conversation/text. For a (video)call/voicemail, it should show the information we have (like when it happened, with whom, the duration... And if we have the recording (see bug 593605) or if we can retrieve it (for voicemails), it would allow to replay it.


The dialog is account-independent and doesn't have an account selector, which is IMHO a good idea (see also bug 598904). Perhaps we should add "Account" to the search combobox, since some people may want to search only in their Jabber/MSN/Whatever account.


Thoughts?

Created attachment 176604 [details]
Allow multiple search criterias for complex searches

(In reply to comment #6)
> The dialog is account-independent and doesn't have an account selector, which
> is IMHO a good idea (see also bug 598904). Perhaps we should add "Account" to
> the search combobox, since some people may want to search only in their
> Jabber/MSN/Whatever account.

I've thought a little about this, and whether it would be useful to allow complex searches. For example, "show me all SMS from Joe", you would select Type in the combobox, then SMS in the combobox that would appear instead of the search bar, then click on "+" to get another search bar, select Contact on the combobox, and select "Joe" in the contact combobox. You can mix any kind of searches. This would be somewhat similar to Liferea's advanced search.

I'm not convinced this is a good idea, I'm just writing it here in case people think it is, with ir without modifications...

Created attachment 176605 [details]
Liferea Advanced Search dialog

(In reply to comment #6)
> * The selected event on the bottom. If it's a chat/room/sms, it shows the
> conversation/text. For a (video)call/voicemail, it should show the information
> we have (like when it happened, with whom, the duration... And if we have the
> recording (see bug 593605) or if we can retrieve it (for voicemails), it would
> allow to replay it.

There was a suggestion that the meta-contacts stuff in Empathy could support automatically continuing a conversation with a different persona in a meta-contact when the persona a conversation is currently being held with goes offline (e.g. you're talking to Bob on his desktop Jabber account; he then leaves his house, and you continue the conversation over SMS). It would be nice if the log viewer handled this nicely, or was at least designed for the possibility of it happening in future.

I think the gist of this would be to present the history as a series of conversations with different people, ordered in time, rather than as a series of messages sent over a specific protocol. e.g. Instead of showing a Chat with Bob at 16:00–17:00, then a series of SMSes with Bob from 17:00–17:30, it would be better to show a conversation with Bob from 16:00–17:30.

This is probably making no sense, and in any case is a wild fantasy. However, I hope it might give you some ideas. :-)

> The dialog is account-independent and doesn't have an account selector, which
> is IMHO a good idea (see also bug 598904). Perhaps we should add "Account" to
> the search combobox, since some people may want to search only in their
> Jabber/MSN/Whatever account.

I don't think “Account” needs to be added to the search combo box; since the meta-contacts stuff has landed, less emphasis has been placed on selecting which protocol to use to talk to people, and I think that most people won't remember or care. They'll be looking for a subject and person.

(In reply to comment #9)
> (In reply to comment #6)
> > * The selected event on the bottom. If it's a chat/room/sms, it shows the
> > conversation/text. For a (video)call/voicemail, it should show the information
> > we have (like when it happened, with whom, the duration... And if we have the
> > recording (see bug 593605) or if we can retrieve it (for voicemails), it would
> > allow to replay it.
> 
> There was a suggestion that the meta-contacts stuff in Empathy could support
> automatically continuing a conversation with a different persona in a
> meta-contact when the persona a conversation is currently being held with goes
> offline (e.g. you're talking to Bob on his desktop Jabber account; he then
> leaves his house, and you continue the conversation over SMS). It would be nice
> if the log viewer handled this nicely, or was at least designed for the
> possibility of it happening in future.
> 
> I think the gist of this would be to present the history as a series of
> conversations with different people, ordered in time, rather than as a series
> of messages sent over a specific protocol. e.g. Instead of showing a Chat with
> Bob at 16:00–17:00, then a series of SMSes with Bob from 17:00–17:30, it would
> be better to show a conversation with Bob from 16:00–17:30.
> 
> This is probably making no sense, and in any case is a wild fantasy. However, I
> hope it might give you some ideas. :-)

It sounds like a great idea, though it's a bit hard to know where to draw the line. We could merge all the comunications in one day together (so they appear in one single row in the list). Displaying all the different events in the bottom part might be a bit tricky though.

> > The dialog is account-independent and doesn't have an account selector, which
> > is IMHO a good idea (see also bug 598904). Perhaps we should add "Account" to
> > the search combobox, since some people may want to search only in their
> > Jabber/MSN/Whatever account.
> 
> I don't think “Account” needs to be added to the search combo box; since the
> meta-contacts stuff has landed, less emphasis has been placed on selecting
> which protocol to use to talk to people, and I think that most people won't
> remember or care. They'll be looking for a subject and person.

Yeah, that's my opinion too, we should move towards meta contacts and forget about different accounts. Having a way to select a meta-contact could be quite useful though.

Perhaps having just the search bar and a meta-contact selector would do the job, so you can select a contact and type some text to filter only in that contact's event. That way we can forget about the complex searches I was talking in a previous comment.

(In reply to comment #11)
> Perhaps having just the search bar and a meta-contact selector would do the
> job, so you can select a contact and type some text to filter only in that
> contact's event. That way we can forget about the complex searches I was
> talking in a previous comment.

That sounds reasonable to me.

(In reply to comment #6)
> I've got rid of
> the calendar since I don't find it very useful and an ordered list sounds
> better to me.

Canonnical's usability study showed that lot of users really love this calendar. They found it very nice and useful.

I'm not saying we SHOULD keep it, but at least we should think a bit more before getting rid of it. I'm ready to be convinced that this calendar is not useful with the new design or that's gnome-journal's job now though.


> The dialog is account-independent and doesn't have an account selector, which
> is IMHO a good idea (see also bug 598904). Perhaps we should add "Account" to
> the search combobox, since some people may want to search only in their
> Jabber/MSN/Whatever account.

I agree that making it as account-independant as possible is a good thing. But isn't there a risk to "spam" the log viewer with, say IRC? May be should have a more advanced option to filter by account if needed?

(In reply to comment #13)
> (In reply to comment #6)
> > I've got rid of
> > the calendar since I don't find it very useful and an ordered list sounds
> > better to me.
> 
> Canonnical's usability study showed that lot of users really love this
> calendar. They found it very nice and useful.
> 
> I'm not saying we SHOULD keep it, but at least we should think a bit more
> before getting rid of it. I'm ready to be convinced that this calendar is not
> useful with the new design or that's gnome-journal's job now though.

If we keep it, we should fix it so that it's not contact-specific unless you select a contact in the contact selector, i.e. it should show conversations for everybody by default.

I'm not sure about keeping it though, I'll think a bit about it.

> > The dialog is account-independent and doesn't have an account selector, which
> > is IMHO a good idea (see also bug 598904). Perhaps we should add "Account" to
> > the search combobox, since some people may want to search only in their
> > Jabber/MSN/Whatever account.
> 
> I agree that making it as account-independant as possible is a good thing. But
> isn't there a risk to "spam" the log viewer with, say IRC? May be should have a
> more advanced option to filter by account if needed?

You would have one conversation per channel per day on the log viewer, so it wouldn't be too bad I guess.

(In reply to comment #13)
> Canonnical's usability study showed that lot of users really love this
> calendar. They found it very nice and useful.
> 
> I'm not saying we SHOULD keep it, but at least we should think a bit more
> before getting rid of it. I'm ready to be convinced that this calendar is not
> useful with the new design or that's gnome-journal's job now though.

I see a big usability problem with the calendar, which is how do we display all the history and not just that of a particular day. That's IMHO an important thing to support. The problem is that there's no way to "unselect" a day from the calendar, so we would need extra UI elements (e.g. a checkbox "Filter by date") to support that. And still we wouldn't support filtering by month instead by day, or any other time frame.

Also if we were to keep it, I'm undecided where it should go on the UI. I'd probably place it on the left of the events list, taking some of its space, so it's somewhat obvious that the calendar and the list are related (i.e. that if you change the day, the list changes accordingly).

Still I don't like the idea too much... do you have a link to that usability study?

See also http://live.gnome.org/Empathy/History

Created attachment 179839 [details]
Four-pane design

This design has a toolbar with a search field, "Who" "What" and "When" filter panes (which each default to showing everything), a transcript pane to show the various events matching the filter, and toolbar buttons for chatting with or calling the contact(s) in the selected history entry.

I think it resolves most of the issues mentioned in this bug report:
- no longer has multiple tabs [Jussi Kukkonen]
- at any time, shows only those conversations, and contacts who have conversations, matching the search text [JK]
- lists eventful dates explicitly instead of hiding them in pages of a calendar [JK]
- shows most recent chats (and other events) by default [bug 578125]
- lists only those days when something happened [bug 596737]
- doesn't split event dates by account [bug 598904]
- simplifies the two search fields into one [bug 612446]
- allows chatting or calling from the log [bug 635259]
- allows searching for events of particular types [Emilio Pozuelo Monfort]
- allows searching on multiple criteria [EPM]
- can interleave events of different types for the same person [Philip Withnall]

It does not:
- show ID next to the full name [bug 573652] - maybe use tooltips instead
- show dates in a timeline [bug 599188]
- allow easy selection of a whole month [EPM] - requires Shift+click

(In reply to comment #0)
> I'm not sure if what I'm seeing is user error, bug or just a design decision
> that doesn't work with my logic. I'm writing it all down here (except for
> issues that are clearly separate bugs), please let me know if there are actual
> bugs here that I should file separately.
> 
> 
> Situation: I'm trying to find a short discussion on "ABC" I remember having in
> a chatroom that has a lot of chatter ever day -- "ABC" was mentioned several
> times in the last days so it's not a trivial task.
> 
> 
> #1: "Previous conversations" has two tabs that both have a search entry, not
> sure which I should use. Can't these tabs be merged? It seems to me that the
> only advantage of "Search" tab is searching in all accounts, otherwise it's not
> very useful -- integrating that into "Conversations" tab should be possible.

That refers to the current implementation, which we know is not very good. Please refer the the draft mokup presented through this link http://live.gnome.org/Empathy/History

> 
> 
> #2: "Conversations" tab seems to list all conversations, not the ones that
> match my search terms. I expected to see only conversations that include a
> match with my search term. This may well be a design decision, but the layout
> still made me assume that both my choice of account and search term would
> affect the list below

This is a bug in Telepathy Logger, sadly you'll get same effect with searches like "message", ">", "xml", etc. As we are speaking Telepathy Logger is also being redesigned, but I keep in mind this bug should be fixed in 0.1.X branch.

> 
> 
> #3: "Conversations" tab: finding conversations is quite difficult. I've been
> playing with UI for quite a while and I still do not understand it:
> * what are the things in the list on the left? They can't be people/chat rooms
> as I have two with same name. They can't be separate conversations or days as I
> only have a maximum of two with the same name...

Two with same name ? Never seen that. They should be a list of people/chatroom for which you have had conversation in the past. Maybe this is due to a bug while reading both .local/share/Empathy/logs and .local/share/TpLogger/logs. Please file a separate bug for that with appropriate log data to reproduce.

> * how does the calendar below relate to the list? I cannot make the connection
> between the highlighted days and conversations. As an example, what I currently
> see is this:
> - two items called "chatroom@server" (server is an XMPP server) in the list.
>   Why are there two items?
> - when I select the first "chatroom@server", calendar highlights 24, 25, 26 and
>   27 (last one is selected). The texview shows a log dated 26th (?)
> - If I then select 26 in the calendar, textview shows me a log dated 25th and
> one from 26th (?)
> - If I then select 25 in the calendar, textview shows me a log dated 21st (?)
> - When I select the second "chatroom@server" in the list, calendar highlights
>   24, 25 and 27 (last one is selected). The textview shows a log of 27th
> - If I then select 26 in the calendar, textview shows messages from 25th 
>   and 26th (?)
> - If It then select 25 in the calendar, textview shows messages from 25th
> 
> This is quite confusing and does not help me find the conversation I'm looking
> for. The second "chatroom@server" had mostly correct info so maybe the bug is
> the that the first one shouldn't be in the list at all?

I'm skipping this one since we know the calendar thing is confusing, and the bug you met is not related.

> 
> 
> I originally found this behaviour on Debian Testing with Empathy 2.28.2-3. I
> have since tried version from git master: This fixed several issues that made
> this experience far more confusing, but the above issues are still present -- 
> the data in .local/share/Empathy/ is of course still the same. I will have to
> try with clean logs but that will take a bit of time...

As said, file bugs against 0.1.X as needed, this bug should be discussion on the new UI proposal, thanks.

Created attachment 179902 [details]
Four-pane design (v2)

Tidies up the timestamp layout.

Created attachment 183091 [details]
Four-pane design (v3)

Tweaks button order, adds an account filter, and shows how chat rooms and their participants would be presented as selectable filters.

Matthew, that certainly looks like a UI I can understand at first glance (unlike the version I filed this bug on), and it looks like it would allow me to do any searches I've ever wanted to do.


However, I wonder about the complexity... There are a lot of UI elements on screen from the moment the UI is opened. 

I think the default case for "search in chats" should be as simple as searching  in modern email clients: input text, done. The design does make that possible, but the three treeviews make the UI a bit daunting, IMO. Would it make sense to make the "search-refining" parts more clearly optional -- hide them a little?

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

A major issue with this design is that it considers chat as conversation, which is a myth in IM in general. A chat is just a series of message with a person or a group that may or may not be linked overtime. The life time of a chat window has nothing to do with a conversation in real life use cases.

Based on this, the expendable conversation cannot be implemented in a way that it will always work the expected way. User need a way to dive in the full chat log, with ability to scroll as long as there is more stuff, or navigate previous/next journey where logs exists.

I personally think that the UI should only care about when was the last message sent/received from a person or a group. This would represent a finite amount of information that will always take a descent time to obtain. Associated with the search, it's pretty much the same but instead if when was last message that matched the conversation.

Then instead of some expender, I think a new view where you can navigate the full log (with the latest matching item, plus infinit scroll capabilities and prev/new search match) is more likely to give user a complete ability to look into text message logs.

Eventually, we are going to introduce some more details about a call, such as user states changing, people joining, leaving, getting kicked that could be shown in such a separate view.

For the view manipulation, I think Gnome 3.0 configuration panel have create a precedence in Gnome (which is from OS X) that would perfectly fit the log viewer navigation.

http://cgit.collabora.co.uk/git/user/pochu/empathy.git/log/?h=log-window-619866

Given it's a complete rewrite, it may be easier to just review the new libempathy-gtk/empathy-log-window.c instead of its diff.

There are a few things that could be improved, but the current branch already works fine so a review would be nice. My todo list is:

∙ Spinner when retrieving logs
∙ Insensitive Call / Chat / ... buttons when contact doesn't support something / contact is blocked...
∙ Infinite scrollback! (as in, fetch logs on demand when scrolling)
∙ /me messages not shown properly
∙ contacts with very long aliases make logs get cut
∙ MUC not grouped properly

I'll look at that stuff in the next few days, but a review now would be nice.

(In reply to comment #24)
> ∙ /me messages not shown properly
> ∙ MUC not grouped properly

Fixed, branch updated.

Straight up, why isn't this new class a GObject inheriting from GtkWindow or GtkDialog?

Initial review follows:

  tp_clear_object (&ctx->entity);
  if (ctx->date != NULL)
    g_date_free (ctx->date);

Why not use tp_clear_pointer?

  g_return_if_fail (type == COL_TYPE_NORMAL);

Leaks @account and @target!

      if (ABS (tpl_event_get_timestamp (event) - timestamp) < 1800)

Magic numbers are bad. Make it "30 * 60 /* 30 minutes */" or #define some meaningful value name,

  gint64 timestamp;

 things in the scope they are used.

  is_toplevel = !gtk_tree_model_iter_parent (model, &parent, iter);

  gtk_tree_model_get (model, iter,
      COL_EVENTS_ACCOUNT, &account,

Am I right in understanding that if is_toplevel is not true, we don't have to lookup the model?

  parent_found = FALSE;

Declaring things in the global scope makes me sad. Either create a structure to pass both @event and @parent_found, or do the iterate the model yourself:

for (valid = gtk_tree_model_iter_first (...);
     valid && !parent_found;
     valid = gtk_tree_model_iter_next (...))
{
  /* foreach func or code */
}

  if (parent_found)
    *parent = model_parent;
  else
    {

Braces around one block requires braces around others.


          C_("First is a contact, second is what he said", "%s: %s"),

Contact may not be a man.

  if (accounts)
    *accounts = NULL;
  if (entities)
    *entities = NULL;

Be explicit in your comparisons.

      paths = gtk_tree_selection_get_selected_rows (selection, NULL);
      for (l = paths; l != NULL; l = l->next)

Fails to free @paths

  gtk_tree_model_get (model, iter,
      COL_WHO_TARGET, &e,
      COL_WHO_ACCOUNT, &a,
      -1);

Does not release references.

  if (!gtk_tree_model_get_iter_first (model, &iter))
    return;

Leaks the stuff at the bottom of the function? Consider using the for-pattern above.

  return (type == -1);

Magic number. Use an enum/define for type.

I didn't look at the code but did some testing of the branch.

Shouldn't we select "all acounts" by default ? Or maybe the accounts having
the most logs?

I think we should expand a bit more the upper part of the window. By default,
the 3 top columns are almost not visible.

I tried to click on the "Profile" button and got this (same with the 3 other buttons).
(empathy:12695): Gtk-CRITICAL **: IA__gtk_tree_selection_get_selected: assertion `selection->type != GTK_SELECTION_MULTIPLE' failed

** (empathy:12695): CRITICAL **: toolbutton_profile_clicked: assertion `type == COL_TYPE_NORMAL' failed

Use empathy-gemotry to save the size and position of the window?

The "Show" and "Search" labels look a bit weird to me.

Clicking on "Chat with..." should expand the conversation.

Shouldn't we display the hour as well in the treeview?

If available, it would be nice to display the avatar of the contact in the
"Who" treeview.

Add a "Clear" icon inside the search entry.

(In reply to comment #26)
> Straight up, why isn't this new class a GObject inheriting from GtkWindow or
> GtkDialog?

It was like that in the old window and I didn't change that. I've added that to my TODO.

>   tp_clear_object (&ctx->entity);
>   if (ctx->date != NULL)
>     g_date_free (ctx->date);
> 
> Why not use tp_clear_pointer?

Done

>   g_return_if_fail (type == COL_TYPE_NORMAL);
> 
> Leaks @account and @target!

Actually it doesn't because only COL_TYPE_NORMAL rows have an account and target. In any case that assertion shouldn't be triggered as the button is only sensitive if there is one normal row selected. I could remove that check, but I thought I'd put it as a sanity check.

>       if (ABS (tpl_event_get_timestamp (event) - timestamp) < 1800)
> 
> Magic numbers are bad. Make it "30 * 60 /* 30 minutes */" or #define some
> meaningful value name,

Done

>   gint64 timestamp;
> 
>  things in the scope they are used.

Done

>   is_toplevel = !gtk_tree_model_iter_parent (model, &parent, iter);
> 
>   gtk_tree_model_get (model, iter,
>       COL_EVENTS_ACCOUNT, &account,
> 
> Am I right in understanding that if is_toplevel is not true, we don't have to
> lookup the model?

You're right, fixed.

>   parent_found = FALSE;
> 
> Declaring things in the global scope makes me sad. Either create a structure to
> pass both @event and @parent_found, or do the iterate the model yourself:
> 
> for (valid = gtk_tree_model_iter_first (...);
>      valid && !parent_found;
>      valid = gtk_tree_model_iter_next (...))
> {
>   /* foreach func or code */
> }

Done

>   if (parent_found)
>     *parent = model_parent;
>   else
>     {
> 
> Braces around one block requires braces around others.

Done

>           C_("First is a contact, second is what he said", "%s: %s"),
> 
> Contact may not be a man.

Done

>   if (accounts)
>     *accounts = NULL;
>   if (entities)
>     *entities = NULL;
> 
> Be explicit in your comparisons.

Done

>       paths = gtk_tree_selection_get_selected_rows (selection, NULL);
>       for (l = paths; l != NULL; l = l->next)
> 
> Fails to free @paths

Fixed

>   gtk_tree_model_get (model, iter,
>       COL_WHO_TARGET, &e,
>       COL_WHO_ACCOUNT, &a,
>       -1);
> 
> Does not release references.

Fixed

>   if (!gtk_tree_model_get_iter_first (model, &iter))
>     return;
> 
> Leaks the stuff at the bottom of the function? Consider using the for-pattern
> above.

Done

>   return (type == -1);
> 
> Magic number. Use an enum/define for type.

Done

(In reply to comment #27)
> I didn't look at the code but did some testing of the branch.
> 
> Shouldn't we select "all acounts" by default ? Or maybe the accounts having
> the most logs?

Yeah, I'd go for 'All accounts'. I Haven't done that yet as retriving all logs for all contacts in all accounts isn't that fast ATM.

> I think we should expand a bit more the upper part of the window. By default,
> the 3 top columns are almost not visible.

Fixed

> I tried to click on the "Profile" button and got this (same with the 3 other
> buttons).
> (empathy:12695): Gtk-CRITICAL **: IA__gtk_tree_selection_get_selected:
> assertion `selection->type != GTK_SELECTION_MULTIPLE' failed
> 
> ** (empathy:12695): CRITICAL **: toolbutton_profile_clicked: assertion `type ==
> COL_TYPE_NORMAL' failed

Fixed, I forgot to update those when doing multiselection.

> Use empathy-gemotry to save the size and position of the window?

Added to my TODO

> The "Show" and "Search" labels look a bit weird to me.

I added them because they were in the mockup. I don't mind removing them. Matthew, opinions?

> Clicking on "Chat with..." should expand the conversation.

Single or double click?

> Shouldn't we display the hour as well in the treeview?

Definitely, fixed.

> If available, it would be nice to display the avatar of the contact in the
> "Who" treeview.

Not sure about that, but we could do it.

> Add a "Clear" icon inside the search entry.

Done

The Chat and call buttons should be unsensitive:
- If the account is disconnected (or maybe we should ask to connect first?)
- If the contact doesn't have the capability
- If a room is selected

The "Profile" dialog isn't very useful: no avatar, no contact info, no location, etc.

Maybe we should use the chat bubble icon instead of the 3 lines one to stay
coherent with the rest of the UI.

(In reply to comment #29)
> (In reply to comment #27)
> > Clicking on "Chat with..." should expand the conversation.
> 
> Single or double click?

Not sure; single? I just find it weird than clicking doesn't do anything.

(In reply to comment #30)
> The Chat and call buttons should be unsensitive:
> - If the account is disconnected (or maybe we should ask to connect first?)
> - If the contact doesn't have the capability
> - If a room is selected

The capabilities aren't set when the EmpathyContact is constructed with empathy_contact_from_tpl_contact(). Do you know of a way around this? The other two would be easy to implement, though for some rooms we shouldn't do it I guess (e.g. irc rooms, well-named xmpp rooms...).

> The "Profile" dialog isn't very useful: no avatar, no contact info, no
> location, etc.

Seems like a consequence of empathy_contact_from_tpl_contact() too.

I can probably get the TpContact with tp_connection_get_contacts_by_id() and then get the EmpathyContact with empathy_contact_dup_from_tp_contact().

(In reply to comment #32)
> I can probably get the TpContact with tp_connection_get_contacts_by_id() and
> then get the EmpathyContact with empathy_contact_dup_from_tp_contact().

In the case where contact still exist in your contact list, you should use the TpContact, but replace certain information with the one in TplEntity (I think it's only avatar-token and alias). If you don't do that replacement, the avatar-token and the alias may not reflect some conversations. This should be done transparently in empathy_contact_from_tpl_contact().

I finally had time to port this to master:

http://cgit.collabora.com/git/user/pochu/empathy.git/log/?h=new-log-window

The unreviewed commits are:
- The last four
- Handle unknown event types gracefully

This adds a dependency on telepathy-logger built with --enable-call, which may or may not be desired.

Nicolas says TplCallEvent is going to be experimental for as long as Call is a draft, so I'll #ifdef it in Empathy.

Done. Same branch. What needs review:
- Handle unknown event types gracefully
- And everything after "Remove unused variables" (including that one)

(In reply to comment #36)
> Done. Same branch. What needs review:
> - Handle unknown event types gracefully

++

> - And everything after "Remove unused variables" (including that one)

+   AC_MSG_ERROR([Call logs support requested but telepathy-logger wasnt
wasn't

Did you try building with and without HAVE_CALL_LOGS?

(In reply to comment #37)
> Did you try building with and without HAVE_CALL_LOGS?

Yep, and I tested both.

merged \o/