On Sunday 06 August 2006 04:11, Olivier Goffart wrote: > 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 >
NO! Models are not tied to any GUI! Views are the GUI. Models are simply data. > 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 ? > The kcm way is basically doing with the protocols what we do with the all the settings dialogs, and I am completely against doing something like that. -- Matt _______________________________________________ kopete-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/kopete-devel
