> > > > > 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
This is a sorting and presentation problem it can be done by adding some filter models. And we can have multiple contact list. A contact list is a list after all. We have THE VERY contact list with persistance, and the chat contact lists. Anyway this can be seen as a huge list containing all the contacts, and we filter it depending on some criteria, since THE VERY contact can be filtered by a boolean or somthing to rebuild it. And then THE VERY contact list be a view of the all contact list. > > 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 I know, but the view will handle the items creations no need to know when it's necessary to create and delete the pointers, the view will call do that for us. > > > > 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 ? Maybe I mixed something here, but it can be can be interesting to allow some plugins to not be global. So such plugin should be able to select contact where to apply the plugin (some kind of tree of check boxes) One example would be Javascript :D where you could allow some contacts to use it remotely, and some not. Or a spell cheking based on the nationality of your peers ... > 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 The contact list don't have to know wich elements are selected, the selection of elements belongs to the model. ContactList is simply a list after all, the model know how to interact with the list, and know how to call actions to the selecteds contacts. > > > > > 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 The DBusInterface would be with the Kopete::ContactTreeViewModel and the DBusContactTreeView would know how to interact with this one (act like a proxy). So with the main application we have KCL <=> KCTVM <=> KCTVWidget And on a remote case KCL <=> KCTVM <=dbus=> KDBusCTVM <=> KCTVWidget So we can reuse the same code for kparts ;) and that way all the widgets looks the same. > And the selection model can't (AFAIK) be shared between applications as it > (And why want we share the selection ?) So that all the view behave the same way. You have one view on the main app and one on the desktop, if you click to prepare one action and have to hide it, you would like to see the one on the desktop allready clicked. Maybe it also requires some QItemSelectionModel work with dbus and can be done in a second step, with the same proxying trick. > > 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 way the plugins are splitted in to libs, the main plugin, and the kcm part to control it via the gui. _______________________________________________ kopete-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/kopete-devel
