Le dimanche 6 août 2006 09:09, Michel Hermier a écrit : > 2006/8/6, Olivier Goffart <[EMAIL PROTECTED]>:
> 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. Yes, I have read the Qt documentation > > 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. That's an interesting point. Could we share the main contactlist model with the chatwindow member list model. Indeed: there are similarities: - It would be nice if the item would look the same - they probably should have a similar context menu But on the other hand: - It's not the same contact: We will not add all IRC or Jabber MUC contact on the contactlist[1] - They are not stored by groups. - We don't want to share the selection. - They probably should not look exactly the same > 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 ?) We can do sorting even of a QTreeWidget > 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 ;) What do you mean ? We don't have memory management model in our current contactlist > > 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 ... Can you give me one example of such list ? Plugins only interact with the main contactlist. The only thing they need to know is the selection, for 1- enabling/disabling actions according the selections 2- do the action on the selected contact. But we have that in libkopete with Kopete::ContactList::selectedContacts > > 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) For DBus, we don't need a Model, but a DBusInterface. Model are really tight to the UI And the selection model can't (AFAIK) be shared between applications as it (And why want we share the selection ?) > 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. Please see my other mail :-) > And maybe we should also go for the kcm way > in the protocols also. What is the kcm way ? -- Olivier [1] Jabber MUC contact can't technically be added as it to the server list. And there is not even always a way to make the correspondence real JID <-> MUC ressource
pgpIWQwdFux6U.pgp
Description: PGP signature
_______________________________________________ kopete-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/kopete-devel
