Red Hat Bugzilla – Bug 244433
Cannot get to buddy list
Last modified: 2008-06-16 21:36:28 EDT
Description of problem:
If pidgin is set to only show the notification icon only when there is a new
status to report (new message), it is impossible to get to the buddy list if the
window is "hidden" (closed via the X button)
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Preferences>Interface>Show system tray icon on: Unread Messages
2.Click X in buddy list
Buddy list hides and it is impossible to get back until someone sends you a message
The buddy list should not hide in this situation.
What SHOULD happen in that situation? Should Pidgin exit? Or should the buddy
list hide and the system tray icon appear?
I would expect pidgin to exit in such a situation.
That would be just as acceptable to me.
Are you sure the buddy list is hiding and pidgin isn't exiting? I'm testing with
pidgin-2.0.1-1.fc7 and cannot reproduce this. Setting the preference to show on
unread messages then clicking X in the buddy list exits pidgin as was intended.
As for what *should* happen, I think the icon should appear, otherwise the
behavior changes depending on there being unread messages. (If show tray icon is
set to never, it should and does exit pidin, not hide to tray).
So, the icon is already being abused. That icon should only appear by default
when there is a status. The area is a notification area, not a "stick your
icons here" area. I realize some people like this, but I'm going through and
noticing an awful lot of things abuse this. We can get rid of the icon area and
just have more window lists if that is what we are using things for. It should
caillon: Can you explain what you mean when you say, "should only appear by
default when there is a status"? What kind of status?
Something that demands attention. A new message, typically.
Ok, I understand. Right now we have a preference "show system tray icon: never,
always, or only on unread messages." When the preference is set to "always" and
someone attempts to close the buddylist via the window manager close button, we
hide the buddylist.
You're saying we should never do this, and we should instead exit? And we
should get rid of the "always" preference and only show something in the system
tray when there is a new message (or an authorization request, or whatever)?
I think I agree with you--that is the most logical solution. But I DON'T think
it is the expected behavior for an IM client for people coming from MS Windows,
and I wonder if it would alienate people. Maybe we should bring this up on the
Pidgin devel mailing list?
I don't mind if you keep the preferences to always show it. It just should not
be the default.
It was off by default in earlier Gaim versions (and isolated to a plugin), but
we added the ability for distros to provide different defaults to allow for
loading this specific plugin and enabling it by default at the specific request
Do you believe this should be off by default purely because it's an "abuse" of
the notification area, or because that's what the majority of users actually want?
(In reply to comment #10)
> It was off by default in earlier Gaim versions (and isolated to a plugin), but
> we added the ability for distros to provide different defaults to allow for
> loading this specific plugin and enabling it by default at the specific request
> of Fedora.
Sigh. Sorry for throwing things in circles. That's not what the notification
spec was designed to do, nor what my team, the desktop team, would have
recommended if asked.
> Do you believe this should be off by default purely because it's an "abuse" of
> the notification area, or because that's what the majority of users actually want?
Both, actually. It is an abuse of the notification area, for sure. But I've
been involved with several usability studies when I was working at AOL/Netscape
that show users are better served by tray applet type things when they aren't
there all the time. I also remember discussing this with someone from IBM or
Sun or Novell or something about a year or so ago. They have done similar
studies here with the same results: If an icon is there constantly, users WILL
ignore it. When an icon changes, and especially so when they are as small as
they are in by default in Fedora (22px I believe), they are not that noticeable
in their new state. Users _do_ however notice new icons showing up. I'm sure
things like this were taken into consideration when designing the notification
spec, which is why it's for notifications, not for "minimizing" apps. Besides,
we already have a place that minimized apps go to, the gnome window list.
If every app did the whole minimizing thing, we'd eventually get into a state
which is just unusable and diminishes the value of the icon. I'm working on
trying to get the apps that do abuse this (such as NetworkManager and
gnome-power-manager) to also fix their (ab-)usages.
I also realize that you will probably take some heat for making the change, as
some users are used to it by now, and might think it weird to flip flop, which I
admit sucks. I think it's the right choice in the long run though.
I think we'd take a lot of heat from it, particularly from the windows crowd,
but not only from them.
The long and short of it is that while you are absolutely right about the
notification area, users seem to consistently dislike having everything show up
in the task bar, and want some way to minimize that doesn't "take up so much space."
I have no opinion whatsoever about what the default value of the preference
should be, but I am not in favor of removing the "always" option at this time.
(In reply to comment #12)
> I think we'd take a lot of heat from it, particularly from the windows crowd,
> but not only from them.
> I have no opinion whatsoever about what the default value of the preference
> should be, but I am not in favor of removing the "always" option at this time.
See comment #9. :-) All I'm arguing for is the default behavior.
We should see what Sean thinks, but I agree with caillon, I think we should make
the default "Show system tray icon on unread messages," and Pidgin should exit
when the X is clicked.
I have no problems with pidgin exiting when X is clicked, but this should happen
when there is unread messages then too (instead of hiding). I also have no
problem with setting the default behavior to only show on unread messages (I've
been using it that way since Sean added it).
If the pref is set to always show the icon, should the buddy list get hidden
when X is clicked? (I've never been a fan of the inconsistent behavior). I'd
suggest having pidgin always exit with the X is clicked on the buddy list. We
could provide a separate pref or plugin to "hide the buddy list to tray" when
minimized (again, this will still lead to "abuse" of the notification area, but
would give certain users what they want and potentially avoid another ticket
The original bug description states that the buddy list is being hidden and
pidgin is not exiting when the pref is set to show icon on unread messages only.
That particular problem I cannot reproduce. As I asked in comment #4, are you
sure pidgin isn't exiting in this case?
I just made a change to upstream Pidgin so that the default value for that
preference is "Show only on unread messages." I don't think we're going to
change any other aspects of the Pidgin system tray icon.
> The original bug description states that the buddy list is being hidden and
> pidgin is not exiting when the pref is set to show icon on unread messages only.
> That particular problem I cannot reproduce. As I asked in comment #4, are you
> sure pidgin isn't exiting in this case?
Yes, it was not exiting in that case as I was still able to send and receive
messages from the people I had initiated conversations with. Although a recent
update has seemed to fix that for me. It does exit now.
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.
Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.
Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008.
Fedora 7 is no longer maintained, which means that it will not
receive any further security or bug fix updates. As a result we
are closing this bug.
If you can reproduce this bug against a currently maintained version
of Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.