2006/8/14, Olivier Goffart <[EMAIL PROTECTED]>: > Le lundi 14 août 2006 09:15, Michel Hermier a écrit: > > > The thing is that Kopete::Group Kopete::MetaContact and Kopete::Contact > > should share the same base. > > I don't see a reason. > They already share the same base btw (QObject) > > And even if they share the same base, that would *Not* be ContactListElement, > which is not done for that. > > > > This way we could remove the dependency of the Contact knowing it's > > MetaContact. > > Wow ! > *Cardiac attack* :-) > > > > And we can also create now a *UID* for all the the contact listelements for > > cheap (and that we could use as a reference with akanodi ?) > > Wait, we still don't know how element will be stored in akonady. > There is no need to have KopeteContact and KopeteMetaContact share the same > uid espace. > A MetaContact is very different from a contact > > > > Why is there no need to know our metacontact for a contact ? The good > > question would be why an object know it's parent ? Object model say, > > we don't need to know the parent. > > The child can inform some other class that some of it's internal > > values using signal calls. > > So the Contact may inform that it changed and that a listening > > metacontact may or may not have to change it's data using the rules we > > allready have before (in the current code). > > The Contact doesn't need to really interact with the parent. But all other > code need to know Contact's MetaContact to interact with. > > All Qt classes have the parent() method. (QObject, Q3ListViewItem, > QListWidgetItem, ....)
Yes I know QObject know there parents but you see how it's complicated behind the scene when reparenting ... Anyway the way I see the things, there we should have multiple parents, but there is only one real parent (the protocol or the model the element belongs to). > > What would be the object tree ? > > Kopete::Group accepts all Kopete::ContactListElement as a child. > > Kopete::MetaContact accepts Kopete::Contact as a child. > > Kopete::Contact accept nothing as a child. > > That's perfectly ok if Contact is not a ContactListElement. > because tou can't add Contact directly into groups. > > > We also gain the fact that we can then have multiple multiple contact > > list and manipulates them differently. > > there is already that. In MSN, i was maintaining a serverside contactlist. > But this is NOT a contactlist made with expensive QObject, but just with > strings and msn id. > > Jabber also maintain his own contact pool which take care of ressource. > > so ContactListElement doesn't help here. But having this private lists doesn't help the user to mange the server side list. Using the same system, we can offer the user a view of the protocol contact system and allow him to manipulate the remote list for a given protocol. > > > I don't see a single reason to have Kopete::Contact inherit from this. > > > > Contact not beeing a ContactListElement is quite ironic ;) > > Why ? Because it means that a Contact is not a part of the contact list. > Maybe the name of ContactListElement is not well chosen ? Do you prefer > Kopete::PluginDataObject ? > (which is going to be a right name again since both notifications and pixmap > are or will go away) > > > For now yes, but I'll try to move some common stuff that I hope will > > simplify the creation of > > the items of the view (using the model). > > First create the model, then do that. > I really don't see how this can simplify the model. It would simplify the model by reducing the number of Item class/model that we should handle. If the base class expose all the *capacities*, we can write only one model that will handle all the item case in a row. Else we will have to create dedicated model for each subclass. And this way we simply (with 0 line off code) allow to have one *line* per contact in a metacontact in the tree. And if we want a condensed metacontact (like we had in the previous contact list), it still can be done. > > What all these objects have in common ? They all belongs to the > > contact list and therefore have at least a "display name" and the > > custom icon/photo. > > AAAAAAAAAAAAAAAAAAAAAAAAARHHHHHHHHHHHHHHHHHHHHHH NOOOOOOO > Kopete::Contact has no dislpay name!!!!!!!!!!!!!!!!! > it has a nickname, which is not the same. > nickname is set by the contact, and display name is set by the user. From my pont of view only the metacontact name should be modifiable. Anyway the property would be simply named "name". Thougth trying to change it may be ignored, delayed or changed directly. > same for the photo. there is no custom photo for a contact, there is just a > photo *if* the protocol support it and the contact has set one You are still in the way I have the photo in my contact I should give it to the metacontact. This is wrong. The contact get the photo and inform that it has it via signal. If there is a slot connected to it (most probably a metacontact), it may react on it or not. It's not to the contact to decide if he should inform it's metacontact, it's the metacontact itself that should *decide* to follow or not data from it sub contacts. > Why can't people understand that ? the difference is pretty big (and that's > why the name has been changed) > > > Since we move the code to use the externalised storage classes, we > > need need a common way to to store and load data, at least for group > > and contact. > > That's an implementation detail of the backed storage class. > > > So in conclusion, none of your reason convinced me. > There is nothing wrong in wanting to refactor something, but this is not the > thing to refactor. > > > You also want that some Contact doesn't have MetaContact. That's a bad think > that lead to crash. > Example: in lot of part of code, you need to show the > contact->metacontact()->displayname() if a contact may not have > metacontact, that make this code really complicated. There are not much of these calls and it seems most of them are used for the UI. And leading to crash doesn't mean the code is rigth. The crash can be the reason that some code was abused somewhere else. In addition I never said that I wanted metacontact to return 0, I wanted to simply remove this method at long term. > You should *NOT* see Kopete::MetaContact as a group of Kopete::Contact. > Kopete::MetaContact *IS* really the contact, and Kopete::Contact are just a > place for abstract method to be reimplemented in the protocol. It doesn't remove the fact that it holds a list of Kopete::Contact. > Maybe we should rename Kopete::Contact into Kopete::AbstractContact or even > Kopete::AbstractProtocolContact > > I hope you understand better the difference between Contact and MetaContact. Yes I allready know the difference bettween the 2, but I want to remove some of the limitations in the MetaContact. _______________________________________________ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel
