On Tuesday 18 July 2006 12:23, Olivier Goffart wrote: > 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 .....)
i am not 100% positive, but i think it's basically the same, as the QHash has a list of all available items internally, just in random order. i will investigate further to make sure that is correct. > Also, we need to fix a contactid. what exactly do you mean by that? hash contactIds also? > > 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 sure. everything outside the contact list is fine with me. > > 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. isn't there some way with something like activeView()->getSelectedContacts? i have on;y started to come up with Model, didn't look into view yet, but they all have good support for single or multiple selection on random data trypes etc. i think it could be done. maybe it can stay in there for now until some solution is found. > > 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 i'll see what i can do > Olivier thanks a lot, conrausch -- [EMAIL PROTECTED] http://conrausch.doesntexist.org JabberID: [EMAIL PROTECTED] # support cryptography! public key: http://elise.no-ip.com/ch.gmx.asc Oh, I've seen copies [of Linux Journal] around the terminal room at The Labs. -- Dennis Ritchie
pgpb9JA88WQle.pgp
Description: PGP signature
_______________________________________________ kopete-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/kopete-devel
