On Monday 07 August 2006 01:12, Michel Hermier wrote: > 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.
I disagree. Let's say that we have a plasmoid that gives us easy access to the kopete contact list running and we also have kopete running as well. They are two seperate entities. If I change the selection in the main application, as a user, I do not expect the selection to change in the plasmoid. IMHO, your idea above is actually worse for usability, but we should ask the usability people to know for sure. :) > > > > > 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
