2006/8/7, Matt Rogers <[EMAIL PROTECTED]>: > 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?
I speak about usability when you have multiple view of the contact list model. One may have the contact list view in Kopete and in another program (Kontact, plasmoid ...) When clicking on one of the view the selections of other view should be affected I think. > > > 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 > kopete-devel@kde.org > https://mail.kde.org/mailman/listinfo/kopete-devel > _______________________________________________ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel
