On Sat, 8 Nov 2008, Stu Tomlinson wrote:
> > I've CC:ed the fedora list, though you gave me a private reply, because I
> > thought the large list of bugs might be useful to someone. Hope that's okay.
> Fine, but I think bugzilla is a better place for bugs to be reported.
Did you mean fedora bugzilla or a pidgin one?
> > - It is the 2nd largest memory consuming application running (after firefox)
> > using up 10% of my total memory:
> > 6698 paul 20 0 843m 96m 15m S 0.0 9.6 16:43.17 pidgin
> > And I am not a super consumer, only 25 friends and 5 irc channels online now.
> That's certainly unacceptable. There have been some reports of high
> memory utilization but I have been unable to reproduce such high numbers
> or track down any significant leaks recently. It is possible this is
> caused by 3rd party plugins, I'd ask you to try disabling OTR to see if
> it improves things but I suspect you don't want to do that
> plugins do you use?
Whatever comes with a stock install, and otr. Is there anyway pidgin can track
memory usage of its modules?
> > - It is prone to crashes and freezes (once every couple of days)
> Have you reported bugs with backtraces for these?
No, I will see about getting pidgin to core dump and get backtraces for you.
> > - Somewhere it lost "reconnect all accounts", and I need to click reconnect per
> > account.
> This should not be necessary, as accounts should automatically reconnect
> without user intervention, unless they disconnected for reasons Pidgin
> determines are not automatically resolvable (such as incorrect
> password). What sort of disconnection results in the accounts being in
> this state?
I don't know. At times it just appears at the bottom of the buddy list window.
> > - Somewhere it lost the ability to be clever and allow typing when the 'focus'
> > was on the receiving part of a conversation window. Now that typing is lost
> > until you click on the small input box.
> I can't reproduce that here.
I just tried to do it again, and could not reprpduce it either. I'll keep track
of it and see if I run into it again.
> That is indeed annoying - unfortunately it is not something that changed
> in Pidgin, but something that changed in the DE or WM or something else.
> I'll try to dig into what it is and see if we can work around it in
> > - Leaves a mess in /tmp/
> What sort of mess? I am not aware of anything Pidgin puts in /tmp - Gaim
> used to a long time ago before we switched to using DBUS for remote
Seems related to getting notifications about new mail on MSN accounts,
for example /tmp/purpleL3Q6HU contains:
temp files contain:
<meta http-equiv="Refresh" content="0; url=http://www.hotmail.com">
<body onload="document.pform.submit(); ">
<form name="pform" action="https://login.live.com/ppsecure/md5auth.srf?lc=1033"
<input type="hidden" name="mode" value="ttl">
<input type="hidden" name="login" value="firstname.lastname@example.org">
<input type="hidden" name="username" value="email@example.com">
> > - Combined user accounts lead to strange things due to pidgin seemingly picking
> > randomly whch user account to use, which causes problems with OTR.
> Pidgin picks the most 'available' buddy within a contact to send an IM,
> if buddies are determined to be equally available, the 1st one listed in
> the expanded contact is used. Drag and drop can be used to re-arrange
That would lead to a lot of ping-ponging between accounts, if one person is
talking on two different protocols at once with two people.....
It is definately not ideal OTR. Not only because of the crypto, but also because
the Opportunistic Encryption reply cannot be "exempted" from the user input,
leading to accounts which are actually idle (and perhaps on a different physical
location) to appear as not-idle.
> > - The file transfer function is completely unreliable and often fails silently,
> > eg the other end does not even see you're trying to send them a file.
> File transfer functionality varies by protocol, and also depends on what
> client the other end is using. I agree it is not perfect. Can you be
> more specific about what protocol(s) you see this on?
That's hard to say, as I don't always know which account pidgin has chosen
while talking to someone. Most of my buddies have multiple protocols, so these
are all grouped by me in the buddy list.
> > - Buddylist window icon at the bottom turns blue ("attention") grabbing when
> > some event has fixed itself, leaving me to wonder what requires my attention.
> This sounds like a bug - did you file a bug?
No. I do try to file bugs regularly for things (and with my own software, try to
respond to them quickly), but I don't always have the time to do so.
> > - When i have more tabs open then fit in the window, and I'm at the right most
> > tab, and I got a new mesage in a tab that's scrolled off screen at the left,
> > I can only go there by going through the tabs, causing them to lose the 'unread'
> > state.
> You can right click on any tab to see a list of all tabs and jump direct
> to the one you want.
Okay. I didn't know about that one.
> > - Once every couple of months, some accounts turns to "unvisible" (might be an
> > MSN/AIM protocol thing, not something pidgin can help)
> I haven't heard of this happening - did you file a bug?
See above. It's vague and more likely to be a MSN interop issue when they change
something. I wouldn't be able to do more then file a very vague bug report.
> > - irc handling of nicknames when briefly bouncing is bad. You'll fight with your
> > own old nick, and with freenode you then lose the ability to privmsg.
> > (not sure if that is fixiable in a client, not really pidgin's fault probably)
> There is a plugin in the purple plugin pack called 'IRC Helper' that can
> manage ghosting of nicks and authenticating to Nickserv
> (yum install purple-plugin_pack)
Thanks, I just installed it.
fedora-devel-list mailing list