Buddy List taskbar icon shows on all virtual desktops

Looking at this on the 29th here, with the latest updates, the issue does not appear to be happening anymore. I've tested leaving the buddy list open and navigating between desktops; the taskbar button stays on the desktop that it's open on.

I'm duplicating on 340366 because I think that the cause is patch 11_buddy_list_really_show.patch. See Martin's comment https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/340366/comments/7

i just upgraded ibex to jackalope beta and noticed this bug
before filling a new bug-report i searched for already reported bugs on pidgin and found this one
the description fits perfectly what i wanted to report, thus i think the bug the author of this one reported is still present

please, fix this one; it's annoying to see the pidgin's buddy list 'button' on the taskbar present on all workspaces even if it's only, really, present on one of them

thanks

First off, this is not a duplicate of #340366; that is about the redundancy caused by the persistent messaging interface icon, whereas this bug is about incorrect behavior *introduced* in 11_buddy_list_really_show.patch:

http://bazaar.launchpad.net/~ted-gould/pidgin/11_buddy_list_really_show.patch/revision/19?remember=20

This behavior is present in Jaunty final upon upgrading from 8.10.

Ted's comment[0] from the 15th seems to indicate that the thinks this is acceptable behavior. I don't care about "arms races"; if it's idiocy on the part of WMs that keeps pidgin from getting focus, don't respond with idiocy by forcing the window to show up on all workspaces. Incorrect is forgivable, but annoying is not, and this is *very* annoying behavior. If that means I have a pulsing pidgin in my taskbar instead of pidgin having focus - and I should note that the pulsing taskbar was the previous behavior, much better behavior, and was what I thought to be the intended behavior - then so be it.

[0]: https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/340366/comments/13

I just disabled visual effects and the buddy list reverted to normal behavior. Upon setting Perferences->Appearance->Visual Effects to Normal the buddy list still worked. The only other thing I had set was the Wallpaper plugin in CompizConfig Settings Manager. Not sure how the bug was resolved, but it is something worth trying if you are having issues.

Bug reappears after logging into another user and then relogging in.

Still in official release

i have the same problem, this is really annoying.

Ted, could you look at that, that's a minor side effect of your change but seems to confuse some users

I also have this problem.

Duplication: bug occurs after minimizing to notification.tray icon and then opening it again with Compiz running.

When bug is present right clicking on the task icon has "Only on this workspace" selected, and reselecting does nothing. After disabling or restarting Compiz, this switches to "Always on visible workspace" and you can simply click "only on this workspace". Assigning a keyboard shortcut to "compiz --replace" is a temporary solution.

Nope, compiz --replace is of no help. The buddy list is still on every window list

I have this problem too, and it is very annoying indeed.

I have the same problem...
Using Jaunty final release installed using Wubi, and full desktop effects...

I have this problem too. I'm using Jaunty with an upgrade from intrepid.

Reinstalling pidgin doesn't change anything.

No fix ?

Btw, why is this "declined for jaunty", as mentioned in the description? It's really an unintuitive behavior that can often confuse docks and launchers (does not focus the right window).

Hi,

I have this problem too, any solution would be appreciated. Many thanks for your time.

I have this problem too

Same here

I consider this a bug in Pidgin's goals, not the WMs. I don't understand how preventing focus stealing is "admirable" for any application other than Pidgin, which simply must be allowed to "effectively steal focus".

I also don't see how the Pidgin tray icon is now redundant, at least it shows me when I have new messages, unlike indicator-applet, which is just taking up space and not telling me anything.

A workaround for Compiz users is to add "title=Buddy List" to the Skip Taskbar section of the Window Rules plugin, although you will lose the ability to Alt-Tab to the buddy list.

Is this why nobody works on the bug? Because pidgin rejects it as a bug in pidgin? Should we file it again compiz?

Any update? I've been using Docky because of this annoyance.

I can confirm this bug, however it doesn't show up if compiz isn't used. That is, when compiz is enabled selecting "Only on this workspace" in Pidgin doesn't have any effect, it does when compiz is disabled.

For a default installed ubuntu application such as pidgin, I would expect that this bug would get more attention...

For the record, I am also experiencing this bug... and no other application suffers from this problem, so why is Pidgin the unlucky bird?

I am also experiencing this bug. I guess I understand Pidgin's point, if the user wants the behaviour of Pidgin stealing the focus, then you gotta work around bugs in other components of the system to do it.

I, on the other hand, and apparently a slew of others, DO NOT WANT THIS BEHAVIOUR, nor do we want the additional annoying behaviour required for a feature we don't want.

As another mentioned above, the old behaviour of Pidgin appearing pulsing on the taskbar was fine. I never let IMs pop up into my workflow, but merely let the Pidgin icon change to let me know I have an unread IM. So having an additional "window" that doesn't exist appear on every workspace is annoying AND useless.

At least let us choose the old behaviour via a preference.

Oops. Also, is there a workaround? Some way to make Pidgin taskbar icon only appear on the workspace where it really resides? Or not at all?

You can add (class=Pidgin & role=buddy_list) to the Skip Taskbar section of the Window Rules plugin.

Personally I use gnome-do, with the new Docky theme I don't need a taskbar anymore.

Something weird is going on. Now it's back to the sane behaviour. I will describe what I've done on this system in hopes that someone will figure it out.

I had installed UbuntuStudio 9.04 and Pidgin. Got annoying behaviour described in this bug. However UbuntuStudio's built-in realtime kernel is crashy, so I installed updates (this seems the most likely thing that fixed it) and PAE kernel and rebooted my system.

Now Pidgin acts like everyone in this bug wants it to act. No more application "button" on the taskbar on desktops where it doesn't exist.

It seems the most likely explanation is the most recent version of Pidgin in the 9.04 UbuntuStudio distro was built without this bug's behaviour. I'm glad it's fixed, but I'm frustrated that I don't know how I fixed it.

confirmed on up to date Ubuntu 9.04 Jaunty running Pidgin & Compiz (shows the same in both awn and gnome-panel)
Haven't tried without compiz tough...

Updating to Pidgin 2.5.6 resolved the bug.

Unfortunately, this update will not reach most users because "Ubuntu ships Pidgin but does not update it after a release (except for security issues). For those users who desire new releases of Pidgin, we have packaged Pidgin in a PPA."

Instructions for setting up the PPA to allow Pidgin updates in Jaunty: http://pidgin.im/download/ubuntu/

Well. Just to add confusion to the whole mess, now Pidgin (which is 2.5.5 on my system) has gone back to its annoying behaviour.

My solution was a radical rethinking of what I use the taskbar for. I mostly just use it so I'll know if gmail has a new email for me. I never select applications with it using mouse. I always use Alt-Tab. So like Jerry above, I just removed it from the GNOME panel and stopped using it entirely. If it's going to be a battleground for applications to insist on giving me information I don't want or need, then why should I subject myself to it?

Incidentally, the "fix" Jerry suggests, adding skip taskbar settings for Pidgin has a nasty side-effect (in Compiz, at least): You can no longer Alt-Tab to the buddy list, therefore can no longer use the arrow keys to select a buddy, then "enter" to start an IM conversation with that buddy.

Not a usable workaround if you're a keyboard-oriented user.

@philovivero:

try gnome-do and activate the pidgin plugin, you can then start an IM to a buddy simply by pressing Super-Space and typing their name ;)

gnome-do is a must for keyboard-oriented users.

Thanks, Jamie. The PPA works perfectly.

Is there a "fixed upstream" status?

Hi,

I am also affected by this bug and I have found a simple workaround that “fixes“ the bug until you close the buddy list:
on any workspace having at least one window open (excluding the buddy list), try to swap pidgin's taskbar icon with another one by drag-and-drop.

Then the bugging taskbar icon will magically disappear from all workspaces where it should not be (until you close and re-open the buddy list)

I just looked at 11_buddy_list_really_show.patch--yikes. It does things that are very heavy-handed. The application really should not do all this stuff just to show the buddy list:

gtk_widget_show(GTK_WIDGET(gtkblist->window));
gtk_window_deiconify(GTK_WINDOW(gtkblist->window));
gtk_window_present(GTK_WINDOW(gtkblist->window));
gtk_window_set_keep_above(GTK_WINDOW(gtkblist->window), TRUE);
gtk_window_stick(GTK_WINDOW(gtkblist->window));

It's... kind of ridiculous. Without this patch Pidgin calls only gtk_window_present. The documentation for this function is quite clear on its behavior: http://library.gnome.org/devel/gtk/stable/GtkWindow.html#gtk-window-present

I'm curious to know who wrote this patch, and if that person has prior experience working on gtk applications. I am not familiar with the problem that this patch attempts to fix, but I'm quite sure that this patch is not the correct solution. An application should not attempt to override the desires of the window manager.

On Mon, 2009-08-24 at 23:40 +0000, Mark Doliner wrote:
> It's... kind of ridiculous. Without this patch Pidgin calls only
> gtk_window_present.

I agree, but the problem was that the window manager takes into account
which application was clicked on to change focus. So, when the app
requests it itself it blocks it on the grounds of "focus-stealing."

The code there is an attempt to make it behave the way that users
expect. I think it shows that we can't win in the arms race against the
window managers. We need to let focus stealing happen, and fix the apps
that behave poorly instead of having WMs protect us from bad apps.

  --Ted

Hi Ted. I already have focus-stealing-prevention disabled in compiz, and yet Pidgin is still malfunctioning. So I don't consider this a bug in focus stealing, nor do I consider the current result of showing up on every workspace to be expected behavior. I agree that focus-stealing-prevention is annoying, which is why I disabled it. But having pidgin's window on every workspace is also disruptive, because it gets in the way of keeping a separate workspace.

Can we at the very least have "fight focus stealing prevention" as merely an option, if you think this behavior of showing up on every workspace is the only way to provide this functionality for the subset of users you are referring to? This is currently the only application I use that is behaving in this non-standard way, so it at most should be an option.

I uploaded a test package to my PPA that doesn't call gtk_window_stick():
https://launchpad.net/~debfx/+archive/ppa/+sourcepub/750497/+listing-archive-extra

Could you please test if it fixes this bug and still brings up the window to the front from the indicator applet.

I don't know anything about an indicator applet. But yes, removing the gtk_window_stick() from gtkblist.c completely fixes the bug.

Proposed fix for this bug:

pidgin (1:2.6.2-1ubuntu7) karmic; urgency=low

  * Don't stick the window to all desktops as some window managers have
    trouble to properly unstick it (LP: #346840)
    - debian/patches/11_buddy_list_really_show.patch

Here is a debdiff that also provides a workaround for bug #209440 on KDE.

pidgin (1:2.6.2-1ubuntu7) karmic; urgency=low

  * Don't stick the buddy list window to all desktops as some
    window managers have trouble to properly unstick it (LP: #346840)
    - debian/patches/11_buddy_list_really_show.patch
  * Always use default tray icon size on KDE (LP: #209440)
    - debian/patches/62_tray_icon_size_kde.patch
  * Use scrollbars in the preferences dialog if the screen height is
    below 700 px instead of 600 px
    - debian/patches/60_1024x600_gtkprefs.c.patch

Thank you for your work. Why do you change the scrollbar patch values? Why does KDE need a such hack, what about users who customize they bar and need other icons values? Not sure about the other change either...

Ted, could you comment on the _stick call change since you are the one who added it there?

I don't know why KDE needs such a workaround but it does.
Limitations in the system tray protocol and pidgin using legacy code (eggtrayicon) to draw the tray icon seems to cause this situation.
KDE4 uses a fixed tray icon size of 22x22, so that workaround doesn't have any negative effects.
I hope Pidgin will migrate to GtkStatusicon with their 2.7 release, which should allow us to drop that workaround.

I'm fine with removing the stick. It was just a hope to fight some focus stealing prevention, but it seems to cause more problems than it fixes.

This bug was fixed in the package pidgin - 1:2.6.2-1ubuntu7

---------------
pidgin (1:2.6.2-1ubuntu7) karmic; urgency=low

  * Don't stick the buddy list window to all desktops as some
    window managers have trouble to properly unstick it (LP: #346840)
    - debian/patches/11_buddy_list_really_show.patch
  * Always use default tray icon size on KDE (LP: #209440)
    - debian/patches/62_tray_icon_size_kde.patch
  * Use scrollbars in the preferences dialog if the screen height is
    below 700 px instead of 600 px
    - debian/patches/60_1024x600_gtkprefs.c.patch

 -- Felix Geyer <email address hidden> Fri, 09 Oct 2009 19:40:26 +0200