should not present pidgin and leave pidgin tray icon visible

This is changing the default value in Pidgin to not show the icon in the notification area by default.

Ted Gould [2009-03-12 16:52 -0000]:
> This is changing the default value in Pidgin to not show the icon in the
> notification area by default.

How would the icon appear then if the user doesn't have MI? Because,
for example, he's running XFCE or KDE, or just removed it?

On Thu, 2009-03-12 at 19:05 +0000, Martin Pitt wrote:
> Ted Gould [2009-03-12 16:52 -0000]:
> > This is changing the default value in Pidgin to not show the icon in the
> > notification area by default.
>
> How would the icon appear then if the user doesn't have MI? Because,
> for example, he's running XFCE or KDE, or just removed it?

I'm not sure how we can take care of that case. I think in general we
could default to not having it in the notification area, and then allow
for people to enable it if they want to use it. To be clear, I don't
want to migrate current user settings here, I don't think that we can do
that in this case. I want to just change the default for new
installations where people wouldn't expect it to be in the notification
area already.

Ted Gould [2009-03-13 7:09 -0000]:
> I'm not sure how we can take care of that case. I think in general we
> could default to not having it in the notification area, and then allow
> for people to enable it if they want to use it. To be clear, I don't
> want to migrate current user settings here

Right, that would be crazy.

> I want to just change the default for new installations where people
> wouldn't expect it to be in the notification area already.

Since that wouldn't work with upgrades, stracciatella, and other
window managers, maybe we should keep the current behaviour of not
showing MI all the time when pidgin is running (which did a while
ago), but instead just show it when actual messages are available?

With jaunty du jour I actually don't have that redundancy any more, so
this became a lot less urgent.

raising priority and mile-stoning as per David Barth

This bug was fixed in the package pidgin - 1:2.5.5-1ubuntu2

---------------
pidgin (1:2.5.5-1ubuntu2) jaunty; urgency=low

  * Adding debian/patches/11_buddy_list_really_show.patch to make
    it so that the buddy list tries harder to appear. This fixes
    some issues with it not appearing. (LP: #341142)
  * Adding debian/patches/10_docklet_default_off.patch to set the
    default behavior to have no notification area icon. This fixes
    (LP: #340366)

 -- Ted Gould <email address hidden> Thu, 19 Mar 2009 00:49:56 -0500

Reopening. I have the lastest version running, and I still have both the MI and the pidgin icon.

In addition, this patch also seems to have caused a regression: I additionally have the "Buddy list" task bar button on *every* workspace now. Before, that task bar button was only on the workspace where the pidgin window lived (i. e. as with any other application).

I can confirm what Martin Pitt said: I have the "Buddy list" task bar button on *every* workspace now. Before, it was only on the workspace where the pidgin window was openend.

Also, defaulting to having no notification icon (which is the default at the moment) also causes the unexpected behaviour of exiting pidgin when clicking the X. I expected that the envelope icon on the indicator applet which was present before I accidentally closed Pidgin meant the program would "minimize to tray" when I closed the buddy list window.

I opened a new bug against Pidgin:

Closing Pidgin buddy list window exits Pidgin by default
https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/356024

Ted, can you clarify the cases the 11_buddy_list_really_show patch is supposed to address? The documentation for _keep_above() indicates that applications generally aren't supposed to call it.

Is this an attempt to work around the fact that calling gtk_window_present() when running recent-ish versions of metacity doesn't present the window if it's on another workspace (instead, causing it to pulse in the taskbar)?

On Wed, 2009-04-15 at 04:24 +0000, Richard Laager wrote:
> Ted, can you clarify the cases the 11_buddy_list_really_show patch is
> supposed to address? The documentation for _keep_above() indicates that
> applications generally aren't supposed to call it.
>
> Is this an attempt to work around the fact that calling
> gtk_window_present() when running recent-ish versions of metacity
> doesn't present the window if it's on another workspace (instead,
> causing it to pulse in the taskbar)?

Yes, exactly. And Compiz with many levels of focus stealing. It still
doesn't work at nearly 100%, much much lower. It does make the problem
better, but the patch is getting pretty extreme.

I'm remarking this one as Fix Released. Not that I believe it is truely solved, but more that I believe that we've done all we can here. The reality is that the Window Mangers are fighting a problem with focus stealing, which is admirable, but we really want to effectively steal focus. So any way that we do solve the problem is a bug in the WM's goals. So then we're jumping through hoops to try and make it really work. This is an arms race, and we all know how successful those end up. Long term this needs to be fixed in the toolkits with some sort of truce decided between the toolkits and the window managers. But, that is way out of scope for this bug.

The issue is still NOT solved here on Ubuntu Jaunty RC! I also have the contact list on every virtual desktop in the windows list!

I consider this bug very problematic, so much I've completely stopped using Pidgin on Jaunty.

Empathy is offering refuge...

I agree with Pascal, please someone fix this issue.

Confirmed on Jaunty Release (if anyone ever thought otherwise ;)); definitely NOT 'Fixed'.

Buddy list appears on window list on all virtual desktops. Annoying!