Comment 1 Olivier Fourdan 2008-06-21 17:25:19 CEST

For the positioning issue, I hardly see how this could be a WM bug since the windows are placed where told to by the application.

Run xprop on the window and check the WM_NORMAL_HINTS, "user specified location". Note that the window might also move itself at some location using a configureRequest event and that will not show in the property.

As for "minimize to systray", there is no such thing, it is a hack in the application. Does it minimize if you use the window manager? If not, what does xprop gives (type of window, etc)?

And BTW I cannot reproduce any of these using:

    $ pkg-config --modversion gtk+-2.0
    2.12.10

    $ rpm -q pidgin
    pidgin-2.4.2-1.fc9.x86_64

Comment 2 Moritz Heiber 2008-06-21 17:36:25 CEST

I know Olivier. It appeared out of nowhere .. I just ment to file a report in order to get some wisdom as to how to track down the issue. I'll try to provide more useful information later this evening.

Comment 3 Moritz Heiber 2008-06-21 17:45:07 CEST

Okay, xprop returns the following:

WM_NORMAL_HINTS(WM_SIZE_HINTS):
		program specified location: 0, 0
		window gravity: NorthWest

Does that mean pidgin sets a specific location?

As for the systray issue: There are no state changes when I click on the systray icon.

The whole xprop output is here:

http://rafb.net/p/nDAqJo69.html

I have absolutely no clue here I'm afraid .. sorry :-/

Comment 4 Olivier Fourdan 2008-06-21 17:59:48 CEST

(In reply to comment #3)
> Okay, xprop returns the following:
> 
> WM_NORMAL_HINTS(WM_SIZE_HINTS):
>                 program specified location: 0, 0
>                 window gravity: NorthWest
> 
> Does that mean pidgin sets a specific location?

Yes, (0, 0) - Try with a program that doesn't set its location and you'll see there is no such things as "program specified location".

> As for the systray issue: There are no state changes when I click on the
> systray icon.

But this is the application, not the window manager, that does this. The systray is the application, and the application unmaps or remap the window when the user clicks on the systray. The window manager is not involved in this (ie, it is not an iconification, there is not such thing as minimize to systray, it's a misnomer).

> The whole xprop output is here:
> 
> http://rafb.net/p/nDAqJo69.html
> 
> I have absolutely no clue here I'm afraid .. sorry :-/

Well, unless proven otherwise, I see no bug in xfwm4 here. It reminds me of  bug #3969 so I wonder if there could be a race cond or a bug in pidgin.

Comment 5 Olivier Fourdan 2008-06-21 18:28:57 CEST

Looking at the code of pidgin, the buddy list (blist) is toggled on button 1 click on the icon. The code is in pidgin/gtkdocklet.c

void
pidgin_docklet_clicked(int button_type)
{
	switch (button_type) {
		case 1:
			if (pending) {
				GList *l = get_pending_list(1);
				if (l != NULL) {
					pidgin_conv_present_conversation((PurpleConversation *)l->data);
					g_list_free(l);
				}
			} else {
				pidgin_blist_toggle_visibility();
			}
			break;
		case 3:
			docklet_menu();
			break;
	}
}

So if the blist is not toggled, it might be because "pending" is TRUE. "pending" seems to be set when there is a conversation pending.

Or, it could be that pidgin_blist_toggle_visibility() does not work. This function is defined in pidgin/gtkblist.c as follow:

void
pidgin_blist_toggle_visibility()
{
	if (gtkblist && gtkblist->window) {
		if (GTK_WIDGET_VISIBLE(gtkblist->window)) {
			purple_blist_set_visible(PIDGIN_WINDOW_ICONIFIED(gtkblist->window) ||
					gtk_blist_visibility != GDK_VISIBILITY_UNOBSCURED);
		} else {
			purple_blist_set_visible(TRUE);
		}
	}
}

In that case, I would say that it is because "gtk_blist_visibility" is already GDK_VISIBILITY_UNOBSCURED since the window is not iconified. That value is set in the followiung callback:

static gboolean gtk_blist_visibility_cb(GtkWidget *w, GdkEventVisibility *event, gpointer data)
{
	GdkVisibilityState old_state = gtk_blist_visibility;
	gtk_blist_visibility = event->state;

	if (gtk_blist_visibility == GDK_VISIBILITY_FULLY_OBSCURED &&
		old_state != GDK_VISIBILITY_FULLY_OBSCURED) {

		/* no longer fully obscured */
		pidgin_blist_refresh_timer(purple_get_blist());
	}

	/* continue to handle event normally */
	return FALSE;
}

Unfortunately, that's pretty much I can say reading that code (I wouldn't want to dig too deep in pidgin's code).

You may want to ask on a pidgin dedicated mailing list, or you may want to add some traces to pidgin to verify the above assumptions :)

Comment 6 Olivier Fourdan 2008-06-21 19:55:50 CEST

Reading that code, if the window is not entirely visible, it won't be hidden. I can reproduce it, move the window slightly off screen, or place a window above (like "keep above") and the buddy list window will not be hidden by the systray anymore.

This is precisely because of the test "gtk_blist_visibility !=
GDK_VISIBILITY_UNOBSCURED", ie if the window is obscured somehow, it will not hide.

Comment 7 Moritz Heiber 2008-07-15 17:51:30 CEST

Its a pidgin error. Confirmed and fixed upstream. Thank you for your time Olivier.

Comment 8 Olivier Fourdan 2008-07-15 21:22:16 CEST

Good, do you have a link to the post that details the bug, that might also apply to the other pidgin related BZ I have?

Comment 9 Moritz Heiber 2008-07-15 21:53:28 CEST

Unfortunately, I got the confirmation on IRC, hence I'm unable to pinpoint the changes that have been done in order to fix this issue. But pidgin does no longer show this behavior with pidgin 2.4.3 installed.

Sorry I can't be of any further help :-(