Bug 244433 - Cannot get to buddy list
Cannot get to buddy list
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: gaim (Show other bugs)
7
All Linux
low Severity low
: ---
: ---
Assigned To: Warren Togami
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-15 12:40 EDT by Christopher Aillon
Modified: 2008-06-16 21:36 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-16 21:36:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Christopher Aillon 2007-06-15 12:40:37 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):
pidgin-2.0.1-1.fc7

How reproducible:
Always

Steps to Reproduce:
1.Preferences>Interface>Show system tray icon on: Unread Messages
2.Click X in buddy list
3.
  
Actual results:
Buddy list hides and it is impossible to get back until someone sends you a message

Expected results:
The buddy list should not hide in this situation.
Comment 1 Mark Doliner 2007-06-15 12:47:17 EDT
What SHOULD happen in that situation?  Should Pidgin exit?  Or should the buddy
list hide and the system tray icon appear?
Comment 2 Luke Schierer 2007-06-15 12:51:11 EDT
I would expect pidgin to exit in such a situation.
Comment 3 Christopher Aillon 2007-06-15 12:59:34 EDT
That would be just as acceptable to me.
Comment 4 Casey Harkins 2007-06-15 13:26:42 EDT
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).
Comment 5 Christopher Aillon 2007-06-15 13:36:08 EDT
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
exit out.
Comment 6 Mark Doliner 2007-06-15 15:06:13 EDT
caillon: Can you explain what you mean when you say, "should only appear by
default when there is a status"?  What kind of status?
Comment 7 Christopher Aillon 2007-06-15 15:46:41 EDT
Something that demands attention.  A new message, typically.
Comment 8 Mark Doliner 2007-06-15 18:17:13 EDT
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?
Comment 9 Christopher Aillon 2007-06-15 18:19:09 EDT
I don't mind if you keep the preferences to always show it.  It just should not
be the default.
Comment 10 Stu Tomlinson 2007-06-15 20:19:39 EDT
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.

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?
Comment 11 Christopher Aillon 2007-06-15 21:47:22 EDT
(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
like:
http://f3.yahoofs.com/ymg/null/null-379675926-1175186415.jpg?ymw_XQ9CInpx4BW9
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.
Comment 12 Luke Schierer 2007-06-15 23:35:29 EDT
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. 
Comment 13 Christopher Aillon 2007-06-15 23:59:32 EDT
(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.

Agreed.

> 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.
Comment 14 Mark Doliner 2007-06-16 03:17:05 EDT
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.
Comment 15 Casey Harkins 2007-06-16 16:59:01 EDT
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
#414 situation).

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?
  
Comment 16 Mark Doliner 2007-07-02 01:58:13 EDT
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.
Comment 17 Christopher Aillon 2007-07-02 10:52:47 EDT
> 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.
Comment 18 Bug Zapper 2008-05-14 09:07:01 EDT
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:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 19 Bug Zapper 2008-06-16 21:36:27 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.