Bug 159267

If you folks are upset about tabs changing when the window is not focused,
here's two more options:

A) Display the most recent in Taskbar, but revert back when window is focused. 
This option I really dislike because the name in the taskbar does not match the
window if the window is on-screen but not focused, and the name is still
unexpected when you do focus the window.
B) Switch the active tab after an incoming message only if the window is not
focused for the last 5 or 10 seconds.  This may seem arbitrary, but this may
actually be a good compromise that works in the majority of cases.  If you're
quickly switching back & forth between apps with ALT-TAB, the active tab wont
suddenly change on you unexpectedly.  It only changes if the window was not
focused for a while.

So I propose either the original fix, or option B.

The only problem with option B is the brief period of time where the taskbar
name doesn't match the incoming buddy IM.  This slight confusion can be avoided
by displaying the Most Recent buddy name in the window name without changing the
active tab during that brief period of time.  Then the tab switches only after
the  timer elapses.

I like your initial idea.  I've definitely noticed this when using Gaim in
Windows, and it IS pretty confusing.  Even now I have to consciously think, "Why
would Jim be IMing me, I thought he was away...?  Oh, I bet it's someone in
another tab."

This has been fixed in upstream, and will be in the next release of Gaim
(probably 1.3.1).  Thanks for the insightful suggestion, and may the conquest of
Earth begin!

The diff should be at
http://cvs.sourceforge.net/viewcvs.py/gaim/gaim/src/gtkconv.c?r1=1.555&r2=1.556
after the anonymous CVS server catches up.

as discussed in #gaim and now on gaim-devel, that patch'll break for messages on
more than 1 tab while inactive 

Created attachment 115126 [details]
The revised patch that went into CVS

This should be fixed for real now in the oldstatus branch of CVS.  I like this
change.

Two problems with that patch:
1) When it switches tab, it interferes with the Message Notification plugin's
ability to set urgency.  It fails to set urgency and add a count.
2) IMHO it should not react to non-chat events, like log out or login.

You can test the urgency codepath by doing this:
1) Enable "Messsage Notification Plugin"
2) Enable "Insert count of new messages into window title
3) Unfocus your IM window
4) Someone messages you, a count begins at [1] and increments with every
additional message until you focus the window.

Step #4 fails with the current patch in Comment #6 when the tab switch happens.
 If the tab is already active, then it begins counting and sets urgent.

Alright, the two issues you described in comments 8 and 9 should now be fixed in
the oldstatus branch of CVS.

The change for #1 is at
http://cvs.sourceforge.net/viewcvs.py/gaim/gaim/plugins/notify.c?r1=1.61&r2=1.62

The change for #2 is at
http://cvs.sourceforge.net/viewcvs.py/gaim/gaim/src/conversation.c?r1=1.630.2.7&r2=1.630.2.8

Thanks!  Much better now, although this seems to do something unintended.

1) Chat with Bob and Mary.
2) Active tab is Bob.
3) Unfocus.
4) Mary messages.
5) Mary logs out.

It cancels Urgency and removes the count.  It should ignore non-chat events, but
not reset upon non-chat events.

Another problem...

1) Chat with Bob and Mary.
2) Active tab is Bob.
3) KEEP FOCUS on the window
4) Mary messages.

It behaves in a confusing way by setting urgent on the window despite the window
already having focus, and it does not remove notification until you do another
event like send a message.

I think the key problem here is that it shouldn't set urgency or count at all if
the IM window is focused.  That is how it successfully behaved before the two
patches in Comment #10.

I'm testing more...

Comment #11 was slightly wrong, it seems to remove urgency but not the count. 
There are several different things going on here, order and timing dependent so
it is a little confusing to understand.  I am trying to understand the relevant
code now...

It is incrementing and setting urgent even if the window has focus.  This seems
to make it behave the way I expect, but I didn't test the other two notification
prefs.

-- plugins/notify.c.orig       2005-06-07 12:39:09.000000000 -1000
+++ plugins/notify.c    2005-06-07 12:39:43.000000000 -1000
@@ -152,8 +152,7 @@
                     "has-toplevel-focus", &has_focus, NULL);

        if (gaim_prefs_get_bool("/plugins/gtk/X11/notify/type_focused") ||
-           !has_focus ||
-           gaim_conv_window_get_active_conversation(gaimwin) != conv) {
+           !has_focus) {
                if (increment) {
                        count = GPOINTER_TO_INT(gaim_conversation_get_data(conv,
"notify-message-count"));
                        count++;

(Auto-Tab has been reverted from the 1.3.1 release due to usptream concerns. 
Further discussion about implementation will happen on gaim-devel for 1.3.2.)

Argument: Some users want the most recent message to be displayed in an
unfocused window when they switch to it.  The current taskbar behavior is
unhappy because it confuses the user into thinking someone messaged when it
really was someone else.

Counter-Argument: Other people objected to the tab switching while the window is
visible but unfocused purposefully.  There was also concern about the tab
changing during quick switching back-and-forth of apps.

Potential Workarounds:
1) Stop displaying buddy names entirely in the title of the conversation window.
 IMHO this idea is far worse than the current behavior.
2) Use Comment #1 option B and Comment #2, which avoids switching the tab until
a timer has elapsed, but avoid lying to the user by displaying the most recent
user in the title.  This would only partially address both counter-arguments,
while reducing the efficacy of the fix to the original problem.  Some people
really disliked the idea of displaying a title that differed from the active tab
user, and saw no value in the timer.
3) Ethan suggested that a cycling method displaying buddy names in the title
might work.  I'm skeptical that this would be effective but this is worth testing.
4) Make auto-tab behavior an option in the notify plugin for the people who like
this behavior, while everyone else can happily avoid it.

http://sourceforge.net/mailarchive/forum.php?thread_id=7478054&forum_id=33079
None of the discussed methods of fixing this were simple or satisfied everyone,
so for the 1.3.1 release auto-tab was disabled in this checkin.

1. I agree, let's throw this idea out the winder.
2. This is reasonable, but I don't like it.  I think it's unpredictable.
3. I think this is also unpredictable, and reduces the usefulness of the window
title.
4. Bleh, I don't like this either.  I could see it being something that breaks
frequently, and I don't think many people would realize the option exists.

2.)  I don't like this, it's even *more* unpredictable than simply always
stealing my context when an incoming IM arrives.  I continue to maintain that
stealing my context is Not Cool.  (Consider pasting, for example ... whoops, I
just pasted  a URL to mysecretdocument.pdf to the wrong person, because my IM
window changed when I was off fetching the URL, and I didn't notice...)

3.) Warren's description is poor, as I described it it does not reduce the
usefulness of the window title.  My biggest problem with it is that 1) it causes
RTTs to the X server regardless of whether or not the window is mapped, and 2)
it is likely to not be clear to clueless users (the ones who are too dumb to
figure out that there's an IM waiting from someone other than the blinking name
in a tabbed window).  The plan would be that, in a conversation with SeanEgn, if
there are waiting unread messages in tabs from LSchiere2 and LBDash, the title
would cycle "SeanEgn (LSchiere2)" and "SeanEgn (LBDash)".

I wouldn't worry about causing extra traffic to the X server with the cycling
names, because supporting Urgency itself causes even more constant X traffic
because it requires animation.  We should test Ethan's plan and see how
intuitive it is.

Actually, urgency requires a one-time exchange between Gaim and the X server. 
If your _environment_ then chooses to do something like an animation, it
requires repeated traffic between your environment and the server.  That's a
completely different situation.

However, I'm not too torn up about the overhead of cycling titles.  It
definitely beats unrequested tab changes.

I didn't like cycling titles because it's slow.  In iTunes for example, if
you're streaming a radio station, it slowly cycles between station name, then
maybe some additional details about the station, then maybe the song name.  If
you're just looking for the song name then you have to sit there and wait for
the stupid thing to scroll through.

Or RDS FM receivers that slowly scroll the text across the display, forcing you
to stare at it for it to be useful.

"Why not make it faster?"  Because some people read slowly.  It's not possible
to please everyone.

I don't think people should be relegated to monitoring the title of their
conversation window just to see who IMed them.  It's easier to just look at the
blasted conversation window.

Re: Slow ... I completely agree.  However, I think that for some reason you're
discounting how truly HORRIBLE it is for a program to jerk context the _user has
chosen_ out from under him/her.  Context is extremely valuable for efficiency. 
I could name little irritations (and big irritations, although some might
disagree on magnitude) caused by automatic tab switching all day long.  In my
opinion, any one of them trumps "the blinking taskbar doesn't tell me which user
in the window messaged me."

So ... let's back up and look at this again from first principles.  The problem
isn't that the tab is on the wrong conversation; the problem isn't that the
title isn't correct.  The real problem here is that we have an extra bit of
information (the buddy(ies) from whom we have unread messages) which we wish to
communicate with the user.  What do we need to accomplish the communication of
this information?  How related is the gnome taskbar?  Can we solve it within
gaim?  (I'm not sure we can; consider: all gaim windows minimized, gaim is on a
different desktop, etc.)  What about using another mechanism?  Guifications
comes to mind...  or popping up one of those little speech bubbles by the docklet.

Ideas?

I am slowly coming to Ethan's opinion here, because while the moving tabs
*happen* to closely match my own work-flow since college, there have been times
when I've needed a reference in an unfocused window.  (you'd be surprised how
much calculus *can* be represented within the limits of im for example, and
getting help on some thing you don't understand).  at such times the tab moving
would cost more time to that user than the current behavior costs to users who
would like this functionality.

Changing the title would be sufficient to convey the additional information that
generated this request.  The time-saver of switching tabs that Mark thought up
was simply an added benifit of the particular solution he chose.

That being said, anyone who has a task bar has at least on some of their
desktops hit the problem that plagues windows: too many windows causes too
little room for each on the task bar.  a number of environments are started to
try to address this problem, for example gnome limits it to one entry per
application as space becomes limited.  Thus with several conversation windows
open, or even just the buddy list and one conversation window in the same
desktop, chances are that events in one window will cause the flashing in
another to be obscured anyway.  This lends itself STRONGLY (in my eyes) to a
guifications or gaim-osd type solution for this problem.  From a
common-practices standpoint, though the official clients *certainly* make more
than their fair share of mistakes, this is a solution that both msn and aim have
toyed with.  This suggests that even if it is an imperfect solution, it would be
one that users would be familiar with. 

This is particularly significant as this *is* the rh bug tracker, and it would
be a reasonable decision for warren to make to package guifications, and use the
/etc/gaim support to cause it to be loaded by default (for new users, existing
ones would have /etc/gaim overridden by their local .gaim)

I was requested not to ship guificiations because it is not done, and it will be
deprecated in favor of grim's perfect generalized dbus-using program that may
never be written.  This is stupid.  Simple guifications functionality belongs IN
GAIM CORE.

As for the taskbar, if the core problem is displaying the wrong buddy name in
the title, why not change the title to the "Most Recent" buddy but only when the
window is unfocused?  Does this actually hurt anyone?  No.

lol. of course guifications doesn't belong in core.  no ui does ;-)

but perhaps it does belong in the gtk-ui (the only current one).


as for the taskbar, yes that can, but no perhaps no worse than ony showing one
name to begin with does.  Personally I'd probly just call them all "Gaim -
Conversations" or perhaps label them differently with placement preferences so
that the group placement could name the window for the group.  Something
representative of the window instead of one tab therein.  but you'll hate that
idea ;-) 

Can we seriously agree on putting simple guifications functionality into the
gaim tarball as a plugin?  We cannot wait forever for the perfect generalized
implementation and everyone agrees that it would be very beneficial to users.

Showing one buddy in the taskbar is a *good* thing to me.  And it makes perfect
sense to change that shown buddy if the window is unfocused.  It does not effect
the case of reading an unfocused window at all, as only the title is changed.

1. Using a plugin to work around bad UI design is just... bad.
2. Who's going to fork guifications and maintain the fork? Forking a plugin and
maintaining it in gaim is bad mojo, particularly when the plugin author has
comitted to a complete re-write of the system. How would you maintain forwards
compatibility, etc. etc. etc.
3. Re-write the /etc/gaim/prefs.xml routines to abstract out to the
/etc/gaim/plugins/guifications.xml level of preferences, then add guifications
to FC. This way, installing a guifications RPM for FC won't violate the 'thou
shalt not modify other rpm's files' mantra.

Erm, I'm sure there's something else which was mentioned last time this came up.
It can't be that important as I've forgotten it now.

The problem, to me, seems to stem from the fact that I can have a multi-tabbed
conversation window open with, for eg, MaryB and JohnD, and the window title
says 'MaryB', when clearly this is only half the story. Just because JohnD and 
haven't exchanged words since MaryB and I last exchanged doesn't mean I'm not in
a conversation with him.

I'm all for Luke's suggestion of having a serious re-think of the window's
title. My only immediate suggestion is very poor. "MaryB, [*]JohnD" where the *
indicates new unread message|s.

If there's insufficient space on the taskbar to display all of this, the tooltip
for the taskbar entry would be giving it away, much like any other sane app out
there at the moment.

Looking forward to flames,
Pete.

Guifications is going nowhere currently, the planned ideal functionality just
will not happen, and even if that does happen it is highly unlikely to go into
Core unless it becomes a freedesktop.org standard and other apps find a good use
for it.  No effort is being put into any of this actually happening, and now
that I think about it further I don't think it is likely to be ever agreed upon
as an upstream standard.  Meanwhile the functionality that we all agree would be
great is sitting on the sidelines with a vague notion of planned obsolescence
and unmaintainability scaring away users.  This situation is broken and stupid.

It belongs in gaim, as a simple built-by-default plugin.  This can be done with
a minimal amount of effort for 1.3.2 and all of our users can benefit
immediately.  It is highly unlikely that a separate guifications would be
allowed in Core anytime soon since it remains vaporware, but if this fantasy
ever does happen it can be removed from gaim and abstracted easily.  I don't
predict this ever happening so I wouldn't worry about it.

Removing buddy names entirely from the title is far worse than the current
behavior.  I really don't see any real problem with the behavior described at
the bottom of Comment #26.

Warren:

For one, you keep saying "we all agree" about things which we do not all agree
on.  For example, I do not agree that the current situation w.r.t. notifications
is unacceptable.  I do understand that you, specifically, find it unacceptable,
and I even understand your point of view and I am willing to work with you on
this.  What I am not willing to do is listen to you demand a particular
functionality which some subset of the Gaim developers feels is broken, or
listen to your spew meaningless invectives at guifications for no real reason I
can understand at all.  If you would like to read comment #22 and help us
resolve this situation, I would appreciate that.

Ethan

I don't want this turn into a flame war, but since I'm being attacked here, I
see it necessary to defend myself.  So the majority of this will be directed at
Warren.

First off, please, do not give an opinion on something in which you have just
about zero insight on.  Guifications is going somewhere, albeit my lack of time
to work on it lately.  There are many reasons I have yet to take any steps to
draft a standard.  Mainly because I have a lot planned but am still not sure how
exactly I'm going to implement it.  This alone, makes it pointless to draft a
standard since things could change at any given time, and I don't want to lock
myself into something that could be fatally flawed.

When it comes to adding it to Gaim proper.  I have thought of writting a striped
down version for Gaim proper when 3.0 is released.  But right now, it's fine
where it is, and always has been.  Also, the majority of the Gaim developer are
not familiar with the Guifications code base making it more difficult to
maintain.  On top of that, I would prefer to not have to support a version that
is only engineered for Gaim, as well as the stand alone version (3.0).  Also,
Sean has expressed that he doesn't want the current Guifications in Gaim proper
for quite a few reasons, but most notably the ammount of preferences.  I
personally don't really see any preferences that can get removed right now,
since they all have very legitimate reasons for sticking around.

As I have stated before, what is the point of being modular if everything is
going to be distributed with the main application?  And let's not forget that
the main reason why Guifications isn't in Fedora is because Warren wants to be
able to turn it on by default.  Which from the users perspective could be rather
annoying.  Not to add more flames to the fire, but with all of discussion about
trying to not program around window managers/desktop environments, why should we
program around a stupid policy in a distrobution as well.

As far as Guifications 3.0 being vaporware, I suggest you check the subversion
repository that current holds it.  The current sloccount on the main library is
over 7,000 lines, hardly vaporware.  Although there is a lack of functionality,
that only does not make it vaporware.

Now if you want a behavior similar to Guifications in Gaim proper, why isn't
there any talk about adding GaimOSD as well?  Some people do prefer the GaimOSD
behavior over Guifications, so if we're going to cater to the Guifications
users, why not the GaimOSD users.

Warren, if you desire Guifications to be enabled by default, why not ship it 
as an RPM (which you could install at the same time as Gaim, set as a 
dependency of Gaim, whatever) and then patch the Gaim RPM to enable 
Guifications when it builds  the prefs.xml file? That would enable it by 
default for new users. If you want to enable it for existing users of Gaim, 
just do something like this:  
 
if (check_pref('forcibly_enabled_guifications') == 0) {  
    enable_guifications();  
    set_pref('forcibly_enabled_guifications', 1);  
}  
 
That way, you'll force Guifications on once for existing users. I'm not saying 
this is or is not a good idea, but if it's what you want to do, it's quite 
possible without changes from upstream. 
 

The current behavior is not "unacceptable."  It is however far less than ideal.
 I  do agree that using the tab title for the window title leads to unintuitive
results.  I disagree on the solution.  When Mark introduced the tab switching,
it took me somewhat less than a day to get used to it.  I can live with it, and
if a true majority chose to go that way, I'd go along.  But I find Ethan and
Bleeter's concerns persuasive and I am reverting to the opinion I held before
tab switching was introduced:  we shouldn't be labeling the window, with many
tabs, after a signle buddy at all.  Back when I first objected to this, I was
labeled as merely resisting change.  Now we are seeing other people objecting to
it, and proposing work arounds (tab switching in this case).  As it stands
however, I only really note two people in favor of the tab switching, Mark and
Warren.  That is hardly universal agreement.

As for guificications, I know I've seen quite a bit of progress in grim's work
with it.  To say that he'll never get it where he wants it to be is something
likely true of EVERY open source project. that's why we still see releases of
the linux kernel.  That's why fvwm releases every now and then.  No program is
ever perfect.  To streatch that into saying he'll never have it at a point where
he'd be willing for it to be more shipped is equally ludicrous.  It is the same
sort of comments people make about gaim & the core/ui split, and yet, low and
behold, once we release 2.0.0 all that will be left will be the build targets. 
of course people said the same sorts of things about 0.60 also, that we'd never
get it out the door.  We did.  It took us ages, but we did, we will get 2.0.0
out, grim will get guificiations 3.0 out.  it just doesn't conform to any nice
calendar-year based release schedule.

Where did I use the word "unacceptable"?

I can agree that Comment #22 sums up the problem exactly:
The Title is not correct

Solutions?
==========
1) Stop using the buddy name in title
I really think this is absolutely horrible.
2) popping up one of those little speech bubbles by the docklet
This may be a good idea, depending on the look and feel.  What event causes it
to disappear?  Is this part of the systray plugin?
I can see how this would be effective, but possibly annoying to some users.
3) Comment #22, nobody has yet explained how exactly changing the title (but not
the tab) if the window is unfocused hurts anyone.  It would be effective in
fixing this specific problem and would not be annoying like #2.

Guifications is mentioned there, but it is really orthogonal to this problem.  I
was wrong and further confusing the issue by suggesting that in this bug.  This
should be discussed elsewhere.

In response to comment #32, there is an incredibly high bar against adding
anything to Core.  There is little chance in hell of what you suggest being
approved.  It makes no sense to have an add-on that is a mandatory dependency. 
The "planned obsolescence" part also further seals the deal.

To be further clear about guifications:
==========
<warren> grim, I was wrong to attack guifications, it is really unrelated to the
specific problem.
<grim> warren: yeah, and by trying to use guifications for the notification of a
new message is only a band-aid over the real problem.

Solution #2 above is really similar to guifications in effect, so it is only yet
another band-aid.  The pop-up nature (even tiny and focusless) may even be
considered annoying by users.  I really would appreciate substantive discussion
about the pros and cons of Solution #3.

having them differ is bad primarily because we've trained users to think they
will match.  Expecting them to match is also, I think, the intuitive responce,
but I have no solid proof of that.  So you'll upgrade, open a couple tabs, say
Luke and Ethan, and go on to do something else.  A situation can arise, will
arise often, when the active tab is Ethan and the window title says Luke.  You'd
have to notice, warned only by the changelog (which many don't read), that the
active tab is still Ethan, even though you just clicked on the Luke window, and
in the previous versions of gaim since we changed to this from "Gaim -
Conversations" (ages ago) this never would have arisen.

How do people feel about only auto-changing the tab when the conversation window
is iconified?

Mark:  Auto-changing the tab when the window is iconified (or simply unmapped,
even) does not bother me.

Does ALT-TAB away iconify?  If so, then it might be bad because it surprises
someone if the tab changes while quickly switching between two windows.  If it
doesn't, then this might be the best we can do, however does not totally fix the
problem.

Can we also experiment with changing the title?  How about a slightly modified
version of Ethan's original proposal, title when unfocused would say
"CurrentBuddy (RecentBuddy)" without cycling.

I'm not aware of any window manager where alt-tab iconifies.  If the window
doesn't disappear from your screen, it wasn't iconified...

Ethan

Hey folks, has Mark's suggestion from Comment #37 been tried for next release?

Unfortunately, no.  I took a short stab at it tonight and it's going to be a bit
more work than I'd hoped.  We don't have an easy way to determine if a window is
minimized, and I'm not really interested in adding one to oldstatus right now
because it would need to change a lot as we update the conversation code in HEAD.

People have had extremely mixed feelings about this, and I'm not even that
stoked about it.  I'd probably accept a patch that make the appropriate changes,
but I doubt I'll spend the time needed to get it working any time soon.

ping

Hey folks, any further thoughts about this issue?

Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Old bug.  It still bothers me...

This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  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 '11'.

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 11'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 11 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 to the applicable version.  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.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 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.