UserListElement is really a wrapper on ULEPrivate (using QExplicitlySharedDataPointer allows us to have many copies of UserListElement object that points to the same data).
UserListElements is a list of UserListElement. UserGroup is a set of UserListElements. Why there are two classes - nobody knows (it is really old code...).
UserList is a global list of all known contacts.
ULEPrivate stores all data for one contact.
Problem is how it stores the data - in three big hashes (one of them is really a hash of hashes...). Unfortunately - almost no comments. Also, the main hashes key's are protocol names (with one used - Gadu) - subhashes have keys as names of properties.
For Kadu 0.7.0 we need more elegant design. I started to rewrite contact-management and the results seems to be very good (at least a lot better). Now there are more classes (but with better names and one-class-one-task approach).
Each contact is now stored in Contact class (UserListElement was a cryptic name). Like in previous version data is hidden with QExplicitlySharedDataPointer and stored in ContactData class. ContactData contains QMap that maps accounts into ContactAccountData object (as in Kadu you can have multiple accounts, you also can be connectect with each of your contacts on each of your accounts). There will be something like ContactModuleData - each module (plugin) will be allowed to add new data to each contact.
Also ContactData contains (or will contain...) fields for data that is not specific per account - first/last name and so on.
Classes UserListElements/UserGroup will be merged as ContactList (QList
Now code is in mixed-state: half of it used old classes, half uses new. There are conversion methods that allows to move data from one type to another, so code does not have to be ported at once.
Three people are doing the transition: uzi18, Juzef (they are from jabber-module team, so it is really important to them to make Kadu more multiprotocol) and me. And the work is progressing very, very fast ;)