New Log Viewer GUI

Description

I have rewritten the log viewer GUI as a plugin to be more user-friendly and intuitive, based on ​this GSOC project of 2010. The code is a rough hack, and needs lots of modifications. I have shown all the buddies of specific accounts in same window, enabling logs of all buddies to be seen together. I used a GtkCalendar? for better access to all logs on a day. Currently all logs on same day show up in a single GtkImhtml?. This is impairing the ability to delete logs individually, so that needs to be changed.
Also added a search tab where we can search text amongst all available logs.

Change History (11)

currently this is using the blocking purple log API. So it kind of hangs the first time it searches for logs. Need to make some changes in the Purple API too to make it non-blocking.
These are some related projects that have tried to implement non-blocking logs.
​RemoteLogging​Nonblocking Log Search

The first thing that jumps out at me is that, in my opinion, you place too much emphasis on the protocol/account. The protocol is shown on the search tab and the account is the main selector on the conversations tab. Pidgin really tries to hide that sort of information from the user when it isn't strictly necessary. I shouldn't have to care if I'm talking to Joe on MSN or AIM.

I like the idea of a global log search. It covers the use case of, "I was discussing this with someone at work, but I can't remember if it was Joe or Bob."

As a random data point, a friend showed me an IRC client that allows you to just keep scrolling up. As you pass the end of the current conversation, it uses the logs to fill in before that. I'm not sure if that's something that could be done easily in Pidgin or not, or even if it's a good idea.

I also like the idea of a calendar picker. I'm not sure how to best design a UI that uses it, though.

It might be a good idea to build some use cases. I use the existing log viewer in the following ways:

I know I discussed something with Joe recently, but I don't have a good search term. (This usually means I sent him a link to a website that I want to grab to send to someone else.) I look at the last few conversations, in order, until I find it. Since they're recent conversations, seeing the first bit of the conversation generally allows me to skip reading the whole text of it before moving on.

I know what I discussed, but it may have been a while ago. I use the search for this.

Obviously, in both cases, I have to know who I had the conversation with, because that's how the current log viewer works. Lifting that restriction might be helpful, as noted above.

It's very important to my uses cases that I not have to know which protocol was used, because I simply won't. Pidgin decides which protocol to use automatically. This is exactly why I wrote the code that makes Pidgin's log viewer aggregate logs by contact.

The first thing that jumps out at me is that, in my opinion, you place too much emphasis on the protocol/account. The protocol is shown on the search tab and the account is the main selector on the conversations tab. Pidgin really tries to hide that sort of information from the user when it isn't strictly necessary. I shouldn't have to care if I'm talking to Joe on MSN or AIM.

I agree that there has been too much emphasis on the protocol. In fact, I read Sean's blog on protocol abstraction just after I filed the ticket. I'll make it contact oriented, and abstract the protocol data.

I like the idea of a global log search. It covers the use case of, "I was discussing this with someone at work, but I can't remember if it was Joe or Bob."

As a random data point, a friend showed me an IRC client that allows you to just keep scrolling up. As you pass the end of the current conversation, it uses the logs to fill in before that. I'm not sure if that's something that could be done easily in Pidgin or not, or even if it's a good idea.

It could be implemented, but it must not be the only way to view logs. Because most of the times I turn off my offline buddies, and wouldn't open conversation windows with them. It suits the use case of an IRC well, but I am not sure about Pidgin.

I also like the idea of a calendar picker. I'm not sure how to best design a UI that uses it, though.

It might be a good idea to build some use cases. I use the existing log viewer in the following ways:

I know I discussed something with Joe recently, but I don't have a good search term. (This usually means I sent him a link to a website that I want to grab to send to someone else.) I look at the last few conversations, in order, until I find it. Since they're recent conversations, seeing the first bit of the conversation generally allows me to skip reading the whole text of it before moving on.

I know what I discussed, but it may have been a while ago. I use the search for this.

Obviously, in both cases, I have to know who I had the conversation with, because that's how the current log viewer works. Lifting that restriction might be helpful, as noted above.

The searching and calendar will serve both these use cases, as you have noted.

It's very important to my uses cases that I not have to know which protocol was used, because I simply won't. Pidgin decides which protocol to use automatically. This is exactly why I wrote the code that makes Pidgin's log viewer aggregate logs by contact.

While I like the idea behind this plugin, I'm not sure the implementation is 100% there yet.

"For:" is not a very good description for the first entry on the Search tab.

It's not totally discoverable what those entries mean on the Conversations tab.

The Find image on the right of the entry doesn't mean anything to me, plus it doesn't even seem to be a button.

The Delete button is in a not-too-obvious place.

Would be nice to have a 'skip-to-next/previous-conversation' button somewhere, especially if you've not chatted in more than a month or two.

There are warnings printed in the debug window when you open the log window (and maybe some other times).

The code is indented haphazardly. This is a symptom of mixing tabs and spaces for indent. Please use only tabs for indent. Spaces are fine for alignment (of continued lines or enums or similar).

uint is not a standard type.

There are several times you do something like this:

for buddy in contact:
all_logs += buddy->logs;
for log in all_logs:
<do something>

That's inefficient since you need to traverse all_logs several times. It'd be better to do:

for buddy in contact:
for log in buddy->logs:
<do something>

Of course, that won't work when you need to sort things.

There are a lot of calls to localtime in ternary operators. Surely this calls for a temporary variable there instead. Or maybe a function.

g_strup is deprecated. It's not UTF-8 compatible. I'm sure we have a better buddy matching function used in the New Instant Message dialog (and View User Log).

FYI, you don't need to put braces around an #if block. It's not the same as if.

Also, if we want to get this working in 3.0.0 (which would be a good idea), you'd need to replace the imhtml with a webview. The upside is that you are free to set up the async logging stuff if you feel like it.

Download in other formats:

All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!