On Sunday 06 August 2006 02:09, Michel Hermier wrote: > 2006/8/6, Olivier Goffart <[EMAIL PROTECTED]>: > > Hello. > > > > So we are going soon or later to drop the Q3ListView stuff for the > > contactlist. > > > > I have made an experimental contactlist using QAbstractItemModel. > > > > I have to say i'm still not convinced by the supposed advantage of > > QAbstractItemModel. > > We could as well use QTreeWidget, and have subclass of QTreeWidgetItem > > for MetaContactLVI and GroupLVI like we have now. > > Could you explain me how having his own model is better ? thanks. > > This model is better in the seens that you divide the data, from it's > rendering. This way you can have multiple view using the same model that > are > affected when you affect one off the view. > If you look at one of the Qt model/view explanation, you'll see 2 file > list widgets. > When you select one item in the treeview, the selection also affect > the list view. > > So do we have a real interest in such features, I would say yes, > because you can also add some filter model layers. And this is > interesting by example for the chat lists. So we have one model for > the contact list, but we may make the view more precise for the chats, > making a *who is in this chat* filter, and then a sort by name filter. > Another thing, if we have a tree view model, we also can use it as a > list view model (limited to one column, and only thee first ?) > > And to conclude, the when the wiget interact with model, it knows when > to add/remove it's child Item, and we remove some memory management > problems ;) even if we have 10 views, the views will handle them for > us ;) > > > Anyway, i think that Kopete::ContactList (KCL) and ContactListModel > > (CLM) must be two separate class. > > I agree, due to the selection model (and maybe other), we must be able > to have multiple KCLM, refering to the KCL singleton. >
The views handle the selection. What are you talking about here? > > KCL, in libkopete, is the central storage class (in memory) which make > > the interface between protocols, plugins, and the contact list ui > > > > CLM is part of the contact list ui. There is no reason to have it in > > libkopete, and let plugins see that. > > I would say that plugins have to see it. Like the main application. > Some plugins allow to refine their activity base on plugins account. > And it would be stupid that the plugins have to rewrite code to handle > such lists when we could reuse the libkopete ones ... > > > I'm not talking about the storage backend in this mail. > > > > > > Is my attached draft the way to go ? Or am I completely wrong ? > > I'm still discovering the inter view stuff. > > For me what you wrote is the way to go. Only one final comment. Make > an intermediate Kopete::AbstractContactTreeViewModel, and use this > intermediate in all the views. > So that we could provide the real and direct > Kopete::ContactTreeViewModel and maybe somewhere else the > Kopete::DBusContactTreeView model (to finally allow remote view, for > cheap, and maybe even with the selection model updated every where) > > I don't want to start a troll for that again, but it would be great to > separate the ui code from the main code again. thougth it will > requires us some effforts. And maybe we should also go for the kcm way > in the protocols also. In fact protocols don't really need to know > about how it's data will be represented. (icon status should be left > to application decision and for the buddy pictures it can be handled > as raw data in the protocols) I'm sure a split between core/gui will happen eventually. Just be patient. -- Matt _______________________________________________ kopete-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/kopete-devel
