Le mardi 18 juillet 2006 02:04, Conrad Hoffmann a écrit : > Hi folks. > > I started looking at implementing (subclassing) an QAbstractItemModel to > use for the contact list, and what i started with was to look at the > contact list itself (Kopete::ContactList, that is, not UI). Here are my > thoughts: > > currently, the list does no sorting and is basically just a central lookup > point for contacts and stuff. i think that's cool. sorting should go into a > data model, so different views (a feature i hope we might end up with) can > use differently sorted models (grouped vs. plain, etc).
I agree > So it's basically a lookup point, and i thought a QHash would be a better > way to look up in many metacontacts. For groups it probably doesn't > _really_ matter, but i just went ahead and did it anyway. > My main reasoning btw: most functions just iterate over all contacts > anyways (data structure shouldnt make a difference), but the few lookup > ones can gain performance when using a hash. Yes. How fast is QHash::values ? are you sure we don't loose performence when we call ContactList::metacontacts() ? (how often do we call this and .....) Also, we need to fix a contactid. > Also, i would like to suggest this: > The only other thing happening in there is a bunch of (mostly rather > unelegant) functions that are only used for the dcop interface, and i think > they should not be in there. Yes, I agree, they should go in the interface dirrectly. > Since the dcop interface has to be ported to > dbus anyways, i figured it could go into a seperate place. my suggestion > would even be: put in a plugin. that way, whenever it is decided that some > external app needs a new function, it would suffice to release a new > version of the plugin. but i don't really care about that, it should just > be seperated from the core contact list. Yes... Why not. although i think this is fine in the Kopete application > Also, i think all the stuff related to selection should not be in there, > that should be view/gui specific.I think ContactList shoud be a pure > backend. Stuff related to selection are there to allow plugin to handle them (when using KXMLGUI) Plugin MUST access to the list of selected contact when an action is called (eg. "Show history"). but also to know if they need to enable or not their action. > Anyways, attached is a patch for trunk to use QHash instead of QMap for > storing the metacontacts and the groups. Let me know what you think about > all that, i am ready to give it some loving... Looks ok to me. maybe you could have moved some fooIterator loop to foreach -- Olivier
pgpqHDkaY9Sy6.pgp
Description: PGP signature
_______________________________________________ kopete-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/kopete-devel
