This is a long post. If you're not willing to read it all (but you should really read it all), here's the executive summary:
There should be one main contact list model. It should replace Kopete::ContactList and continue to provide the same functionality as that class does. We should start out with a simple view first. We'll have to write a custom view in order to get more features. Storage backends exist in order to abstract the persistance of the contact list. We don't care how it's stored as long as it's stored. While kopete is loaded, we only care about the model or what's in memory. Please find me if you have questions, I'll be happy to answer as long as you're willing to listen and attempt to understand my explanation. On Saturday 05 August 2006 18:30, Olivier Goffart wrote: > 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. > > > Anyway, i think that Kopete::ContactList (KCL) and ContactListModel (CLM) > must be two separate class. > I disagree, and you fail to specify why you think this. I did not take part in the discussion on IRC about this. > 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. > You're getting model/view confused. The model has nothing to do with the view. Think of the view as being a child of the model. The model can exist without the view. However, the view cannot have a meaningful existance without the model. > 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. > You are not completely wrong, but perhaps it would be best if I were to better explain my original designs for the contact list model, attempt to detail the possible advantages, disadvantages, etc., and attempt to provide more information, since this is all my design, and I just handed it off to kedge and DarkShock for the moment. Perhaps you can take this information and come up with something better than what you've presented here. There should be one main contact list model. It will serve many purposes, which include, but are not limited to: 1. Being the main container of contact list data as it is contained in memory. 2. Being the interface between the contact list data and those wishing to access it (plugins, protocols, views, etc.) It should take over the current functions of the Kopete::ContactList class as it currently exists. It should reside in libkopete (naturally) There can be many other contact list models that should be thought of as child models of the main contact list model. These will serve other purposes, such as: - providing easy searching and filtering. - providing an easy way to change the way the contact list is viewed. (We tell the view to use a certain model, and we have instant filtering by protocols, for example) It might help to think of this as a modified usage of the Strategy design pattern currently used in the contact list view. The concept is very similar at least. Initially, the view should consist of a simple Qt view. Either a QListView for providing a simple list of all contacts, or a QTreeView if we wish to keep the current way of viewing things. We will have to write our own custom view class in order to provide the rest of the features and functionality that we currently have. Multiple view classes may be required depending on how the contact list information is to be displayed, but I hadn't thought that far ahead, to be honest. Please be sure to read _all_ the documentation linked to from http://doc.trolltech.com/4.2/model-view-programming.html. If you don't understand it the first time, reread it. It took me three reads before I felt like I understood enough to design something around it. To answer you question about why we need a model: The model provides a way for us to abstract our data in such a way that the view displaying our data does not know and does not care about internal data structures. To touch on the storage backends quickly: Their sole purpose is to abstract the persistance of our contact list data for reuse later. We don't really care how it's stored, we just want to store it, aka loose coupling. If _anybody_ has any questions about the contact list model, please either email me, find me on IRC or IM, and I will be happy to answer any questions you might have. It's been quite hard for me to put the design in words adequate enough to be easily understandable. I sincerely hope this helps explain things. I really did not think there would be this much fuss over this. -- Matt _______________________________________________ kopete-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/kopete-devel
