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
_______________________________________________
[email protected] mailing list
Want to unsubscribe? Use this link:
http://pidgin.im/cgi-bin/mailman/listinfo/support
