[libpurple] Privacy API questions.

Stephen stephen at enflick.com
Wed Apr 7 12:59:38 EDT 2010


Hello,

I am relatively new in the realm of using libpurple, particularly in an 
application that is not Pidgin nor Finch.  Recently I've been developing 
some functionality to display blocked users in my own application, and 
have been getting some peculiar results.  Thus far it smells like 
there's a bug afoot in libpurple, but I figured I'd share these results 
and ask a few questions before submitting a bug report.

Libpurple uses a per-account member, 'perm_deny', to determine what 
logic is used to determine if a buddy is 'blocked' (the meaning of 
which, as I understand it, being highly protocol-dependent).  Thus, a 
call to purple_privacy_check() on an account/buddyname pair should yield 
FALSE if the buddy is blocked, and TRUE otherwise.  Furthermore, 
callbacks to the privacy ui-ops are made when an account is signed in to 
indicate which buddies are on the deny/permit lists for the account.

However, the part that concerns me is that 'perm_deny' is being set to 
PURPLE_PRIVACY_ALLOW_ALL upon account creation in purple_account_new(), 
and this value is not changed unless either purple_privacy_allow() or 
purple_privacy_deny() are called explicitly.  Therefore, any attempts to 
check a buddy's blocked status via purple_privacy_check() happily 
returns TRUE despite the permit/deny lists.  (I realize that the data 
written to 'blist.xml' stores the 'perm_deny' value and the permit/block 
lists, but using this saved data across sessions is not an option in my 
case.)  Am I expected to be setting 'perm_deny' directly?

Or am I mistaken?  Pidgin seems handles this correctly even with 
blist.xml missing, but a brief grepping showed that it does directly set 
'perm_deny' in gtkprivacy.c at some point.  I'm feeling a mite stumped, 
so any light shed on the problem would be greatly appreciated.

Cheers,

   Stephen




More information about the Support mailing list