Main BList vs Accessors
aluink at gmail.com
aluink at gmail.com
Sun Mar 15 20:07:09 EDT 2009
Moreover, if we only expect clients to work with a single PurpleBuddyList, why do PurpleBlistUiOps pass a list pointer if it's always the same list?
"None are more hopelessly enslaved than those who falsely believe they are free."
--Goethe
"Freedom is living without government coercion."
--Ron Paul (www.ronpaul2008.com)
On Sun, Mar 15, 2009 at 19:36, Eric Polino <aluink at gmail.com> wrote:
> So I'm working on writing setters and getters for the ui_data members
> in blist. The current implementation of the blist module has a main
> PurpleBuddyList* that purple_blist_[get|set]_ui_data work with. What
> names should I then use for working with a given PurpleBuddyList*?
> There doesn't seem to be a clearcut way of working with them.
> Gntblist has a bunch of methods it uses to manipulate its list, while
> gtkblist seems to do it quite differently (my knowledge of gntblist is
> better than that of gtkblist, clearly).
>
> There seems to be a conflicting set of ways PurpleBuddyList objects
> are to be used. Are clients to only rely on the one stored in the
> blist module in purple, or does purple support allowing more than one
> list? If we only want to allow working with the main list, then why
> provide accessor methods at all? On the other hand, if we want to
> allow more than one list, we want to rid the main list, or other
> ideas? Anyhow, I'm rambling on, if someone can give me some direction
> as to how we want to deal with this in the context of hiding the
> structs, I can implement it.
>
> Thanks,
> Eric
>
>
> "None are more hopelessly enslaved than those who falsely believe they
> are free."
> --Goethe
>
> "Freedom is living without government coercion."
> --Ron Paul (www.ronpaul2008.com)
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20090315/d24f0331/attachment.sig>
More information about the Devel
mailing list