[Pidgin] #1422: buddy list tooltip and auto-expand affect wrong buddy

[Pidgin]

#1422: buddy list tooltip and auto-expand  affect wrong buddy
---------------------+------------------------------------------------------
Reporter:  jblittle  |       Owner:  datallah       
    Type:  defect    |      Status:  new            
Priority:  minor     |   Component:  winpidgin (gtk)
 Version:  2.0.1     |    Keywords:                 
 Pending:  0         |  
---------------------+------------------------------------------------------
 Running Windox XP, Pidgin 2.0.1, installed with GTK 2.10.11b.  I have
 tweaked my gtkrc (see below).  When I hover over buddies, the tooltip that
 appears is often for the buddy just above the buddy it should be.  For
 example, I have buddies Abud, Bbud and Cbud in my list.  If I hover over
 Abud, I'll get the (correct) Abud buddy info tooltip.  If I hover over
 Bbud, I'll also (incorrectly) get Abud tooltip.  If I
 hover over Cbud, I get (correct) Cbud tooltip.  At first I thought this
 was an every-other-buddy problem.  But it's not that simple.  It also
 happens regardless
 of the setting of "show buddy details" or "show offline buddies".  I have
 alphabetic sorting enabled, but I have the same problem if I switch to
 manual sorting.

 As a concrete example, currently I'm seeing this ordering of popups (for
 buddies A-O):
  A, A, C, C, D, F, F, H, H, J, J, L, L, N, N

 This problem appears related to a setting in my gtkrc (.purple/gtkrc-2.0).
 I wanted to compress the vertical spacing of the buddy list, so I reduced
 the vertical separation in the tree control.  My gtkrc contains this (in
 its entirety):

 {{{
 style "my-style"
 {
   GtkTreeView::vertical-separator = 0
 }
 widget_class "*" style "my-style"
 }}}

 If I empty my gtkrc and re-read it, the problem goes away.

 This also affects auto-expand when dragging a buddy onto a contact.

 Looking at the 2.0b4 code (where I first saw the problem), the thing I see
 in common between gaim_gtk_blist_expand_timeout, and
 gaim_gtk_blist_tooltip_timeout, is that in both cases, the motion callback
 computes the affected buddy into "tip_rect", and then the timeout function
 uses tip_rect.x and tip_rect.y to map back to the path of the affected
 buddy
 in the model.

 I wonder if there is a fence-post error in GTK regarding this, and if it
 would be better to use (x + width/2), (y + height/2), that is, use the
 center of the tip_rect, in order to find the buddy for a particular rect.

-- 
Ticket URL: <http://developer.pidgin.im/ticket/1422>
Pidgin <http://pidgin.im>
Pidgin