Additional k => tde renaming and fixes

1 files changed, 52 insertions, 52 deletions

diff --git a/kopete/KABC_INTEG_NOTES b/kopete/KABC_INTEG_NOTES
index 3b00924d..ea053dbe 100644
--- a/kopete/KABC_INTEG_NOTES
+++ b/kopete/KABC_INTEG_NOTES
@@ -20,20 +20,20 @@ Spaze's goals
 2. Allow other apps to retrieve all IM-enabled contacts and their online status for e.g. presence display in kmail or invitations for desktop sharing
 3. Allow other IM apps to share the same data that Kopete uses in a standardized way
 4. Allow other apps to start a chat with selected persons in a standardized way _regardless of client used_
-5. in the longer run i would like to add,say, an ICQ UIN from kaddressbook and Kopete automatically picks up the change, adds it to the server side contact list and does all other kind of syncing of changes made in kaddressbook as well. for the short term one way kopete->kabc is ok, but the API should be prepared for full bidi comms. ideally kopete, libkabc and all server side contact lists are always 100% in sync as much as possible for each.
+5. in the longer run i would like to add,say, an ICQ UIN from kaddressbook and Kopete automatically picks up the change, adds it to the server side contact list and does all other kind of syncing of changes made in kaddressbook as well. for the short term one way kopete->tdeabc is ok, but the API should be prepared for full bidi comms. ideally kopete, libtdeabc and all server side contact lists are always 100% in sync as much as possible for each.
 
 mETz' goals
 1. well, I just think Kopete should never edit my addressbook without me knowing
 
 Gof's goals
-1. my goal is to have the kopete contactlist a kind of address book  (i.e. i want to view and modify kabc entry from kopete, like if i am in the kab interface.  i do not want to open KAB
+1. my goal is to have the kopete contactlist a kind of address book  (i.e. i want to view and modify tdeabc entry from kopete, like if i am in the kab interface.  i do not want to open KAB
 2. and i want to share fields (gpg key) with other application, like kmail
 3.  technicaly, i think that should be transparent.
 Goals (-ve):
 *) don't store information that's not worth sharing in the address book
 
 gregj's goals
-kopete should not replace  server side data with kabc derived data nor upload information that wasn't present on the server before. 
+kopete should not replace  server side data with tdeabc derived data nor upload information that wasn't present on the server before. 
 E.g. we know someones telephone nr. but we don't want to put this information back on server if it was not present there before. Update IMO is ok.  
 
 brunes goals
@@ -47,16 +47,16 @@ KABC->kopete ok, what about server side metadata
 Display Name
 
 Priority: Goals for 3.2
-ONLY the actual linking and one-way storage from kopete in kabc and retrieval of display name and address book data
-Also ability to add kabc contained contacts to kopete ( selected ones only )
+ONLY the actual linking and one-way storage from kopete in tdeabc and retrieval of display name and address book data
+Also ability to add tdeabc contained contacts to kopete ( selected ones only )
 
 Linking
 use KMC UID to store KABC uid, QString::null if no link.
 Establish the link using KMC Props dialog (mETz: Alt+return shortcut to open pls).
 Policy:
-One way kopete->kabc contacts
+One way kopete->tdeabc contacts
 , achieve bidi later
-<Bille> what about the sync policy between IM contacts contained in kabc and in kopete
+<Bille> what about the sync policy between IM contacts contained in tdeabc and in kopete
 <spaze> mETz: alt-enter doesn't work? report a bug to tdelistview/qlistview, that sucks :( </ot>
 <gregj> hyhy
 <spaze> Bille: implied i'd say
@@ -67,7 +67,7 @@ One way kopete->kabc contacts
 <spaze> ugh..
 <Gof> and the wizzard iontegration is in the link
 <Gof> now, it has no sense  to provide a link if we don't use it at all
-<spaze> Bille: I think Gof is right. first we just ignore what's in libkabc and do it one-way
+<spaze> Bille: I think Gof is right. first we just ignore what's in libtdeabc and do it one-way
 <spaze> Bille: once that works we can do it bidi
 <Bille> ok
 <spaze> Bille: we have the luxury to be the first so no need to be compatible :)
@@ -80,7 +80,7 @@ One way kopete->kabc contacts
 <spaze> ( ) Add only these contacts
 <Gof> if not, the link is useless, and it's better no link at all
 <Bille> spaze: agreed
-<spaze> not even conditional, just always, if you say you want to use kabc
+<spaze> not even conditional, just always, if you say you want to use tdeabc
 <spaze> that's our first test case
 <spaze> once that works we can do the addressbook fields
 <Bille> gregj: what is your take on syncing display name to addressee name?
@@ -92,7 +92,7 @@ One way kopete->kabc contacts
 ***
 
 <Gof> spaze: ( )  add all contact    is not good imo  (i don't want to add irc channels)  and also, it would make a lot of duplicate entities
-<gregj> i want kabc to provide me storage, and give back just what i stored
+<gregj> i want tdeabc to provide me storage, and give back just what i stored
 <gregj> nothing more
 <Bille> gregj: what if it changes the Kopete displayname (that is not sent to the server)?
 <gregj> if i didn't provide email, i don't want email back
@@ -101,10 +101,10 @@ One way kopete->kabc contacts
 <Gof> maybe
 <gregj> Bille: hmm, this is hard to say now
 <gregj> Bille: i am retriving all information on connect from server
-<spaze> Gof: I'm talking about the fields to IMPORT from libkabc when we start kopete and kabc was changed by another app, i.e. someone was added there
+<spaze> Gof: I'm talking about the fields to IMPORT from libtdeabc when we start kopete and tdeabc was changed by another app, i.e. someone was added there
 <gregj> Bille: as long as uid matches, this should be ok
 <Bille> gregj: ok
-<gregj> if someone changes uid in kabc, then it is his problem
+<gregj> if someone changes uid in tdeabc, then it is his problem
 <spaze> Gof: but you pointed out a nice flaw in the current addressBookFields API :(
  samppa Singularity spaze STiAT|off 
 <spaze> gregj: i'm talking about adding new entries, not modifying
@@ -115,21 +115,21 @@ One way kopete->kabc contacts
 <Bille> yup
 <gregj> spaze: than it is ok to me
 <gregj> spaze: i will have to synchronize it with server than
-<spaze> Bille: we now assume addressbook fields are either all stored in kabc or all stored in xml
+<spaze> Bille: we now assume addressbook fields are either all stored in tdeabc or all stored in xml
 
 SEMANTICS OF KABC KEYS
  ok, one question, it is already dual-key based (app, key)
 <spaze> so that's perfect
 <Bille> yeah, what's that Key about?
 <Bille> i wasn't sure what that's for
-<spaze> Bille: what kabc is "supposed" to be used like is as follows:
+<spaze> Bille: what tdeabc is "supposed" to be used like is as follows:
 <spaze> addCustomField( "kopete", "myCustomKey", "myValue" )
 <spaze> BUT
-<spaze> we use kabc for data that is NOT app-specific
+<spaze> we use tdeabc for data that is NOT app-specific
 <Bille> in our semantics, what's the All mean, all messaging apps incl kopete? :)
 <spaze> so we 'abuse' app as key and are stuck with a key that we don't use
 <-- cdr has quit (Client Quit)
-<gregj> spaze: maybe there should be a category in kabc
+<gregj> spaze: maybe there should be a category in tdeabc
 <spaze> Bille: oh... that's another 'abuse' of the sematics
 <spaze> Bille: that's only for contact id's
 <gregj> spaze: category for IM related info, emails, and so on
@@ -150,8 +150,8 @@ Use cases
 1) Add new metacontact + contacts using Add Contact Wizard
 	Decide whether to associate or not if using mandatory association.
     a) Matching addressbook entry already exists
-	- Need to choose kabc entry in ACW?
-	- Check if kabc entry already contains IM information (old install of Kopete or from another client)
+	- Need to choose tdeabc entry in ACW?
+	- Check if tdeabc entry already contains IM information (old install of Kopete or from another client)
 	b) No matching entry exists
 	- Need to add new one
 
@@ -161,15 +161,15 @@ Use cases
 3)  All new Kopete (first run / no existing configs or contactlist)
 	Add accounts
 	Server Side Contact List (SSCL) fetched, lots of permanent contacts are created.
-*)  Consider if 2 accounts are added and there are contacts from different accounts such that they represent the same person.  They belong in the same MC.  MC merging should take place prior to kabc association.
+*)  Consider if 2 accounts are added and there are contacts from different accounts such that they represent the same person.  They belong in the same MC.  MC merging should take place prior to tdeabc association.
 
-4)  An existing Kopete config is present and we upgrade to a version of Kopete supporting kabc.
+4)  An existing Kopete config is present and we upgrade to a version of Kopete supporting tdeabc.
 
 5a)  After abandoning Kopete, users start using a different KDE IM client, and would like to use the IM address details stored in the KDE address book.
 
 5b)  The user used another KDE IM Client.  But he finally discovers Kopete,which is the best, decides to use it, and he would like to use information already existing in KABC
 
-6)  Protocols may deliver contact data that users may want to aggregate into the kabc entry.
+6)  Protocols may deliver contact data that users may want to aggregate into the tdeabc entry.
 
 7)  A contact adds a new IM account, either the user decides to add the new account to the MC manually, or the contact messages the user first, we get a temporary contact Kopete side, add them to the MC.
 
@@ -179,7 +179,7 @@ Use cases
 
 Implementation notes
 --------------------
-1) New MC.  Need dialogs to ask if association needed. Association dialog allows to select/search kabc contacts.  We need to write the kabc data sooner than closing Kopete!
+1) New MC.  Need dialogs to ask if association needed. Association dialog allows to select/search tdeabc contacts.  We need to write the tdeabc data sooner than closing Kopete!
 
 2) Same as 1)
 
@@ -188,16 +188,16 @@ Implementation notes
 
 4) Deferred association
 
-5a) We don't want any Kopete specific data in the kabc.  Entries should be usable by other KDE IM apps.
+5a) We don't want any Kopete specific data in the tdeabc.  Entries should be usable by other KDE IM apps.
 
 5b) The reverse case, therefore we should agree standard entry format with other apps.
     We should also make using this info really easy in the Add Contact Wizard (see below).
 
-6) Question: how to combine all contacts in an MCs' data before saving this to kabc.
+6) Question: how to combine all contacts in an MCs' data before saving this to tdeabc.
 
-7) First do dupe check or 'im-info-in-tdeabc-not-in-kopete' check in case this information already exists in KABC.  Once added to a MC, if already associated, we can add the new contact information to kabc immediately, otherwise Deferred association accessed via MC properties dialog.
+7) First do dupe check or 'im-info-in-tdeabc-not-in-kopete' check in case this information already exists in KABC.  Once added to a MC, if already associated, we can add the new contact information to tdeabc immediately, otherwise Deferred association accessed via MC properties dialog.
 
-8) Don't remove the kabc fields, other IM clients might be using them.  So we just remove them from the Kopete contact list.  Dupe contact on the MC add contact thingy will catch if the contact is added again.  (and the user might still want to have other data like the phone number) * See the kabc section
+8) Don't remove the tdeabc fields, other IM clients might be using them.  So we just remove them from the Kopete contact list.  Dupe contact on the MC add contact thingy will catch if the contact is added again.  (and the user might still want to have other data like the phone number) * See the tdeabc section
 
 Therefore we need an Association Dialog accessed in wizard and from the MC properties dialog.  Note, this name sucks, don't write any classes using it.
 
@@ -207,13 +207,13 @@ Side Issues
 It's not possible to add >1 contact per protocol using the ACW.  Martijn: >1 contact per MC is for power users, they can add extra contacts using the MC's context menu. Change to an iterative ACW would fix this.
 
 
-Possible ACW order including kabc
+Possible ACW order including tdeabc
 ---------------------------------
 1) Welcome :P
 2) Choose Account
 3) Fill in protocol details
 4) Select Group
-5) Select kabc contact from list | create new | create none
+5) Select tdeabc contact from list | create new | create none
 
 6) - if the user selected to create a new entry in the KAB, show the page showed when you add normaly a new KAB entry (if possible where some fields are
    - if the user selected to search in the existing KABC database, show a nice widget to search one user.
@@ -281,7 +281,7 @@ B) use a KPart from KAB to show the widget showed when adding new KAB entried =>
 This try to do all in as few step as possible.
 I can't count very well, but AFAICS your suggestion is equal or greater:
 
-Step Count		No IM in kabc	1 IM in kabc (new entry) + n new
+Step Count		No IM in tdeabc	1 IM in tdeabc (new entry) + n new
 Will    			7				6 +  3 * n = 9
 Gof     			6 				5 +  2 * n = 7
 
@@ -305,7 +305,7 @@ so kopete becomes in fact a addressbook itself
 
 
 
-Adding fields to kabc
+Adding fields to tdeabc
 ~~~~~~~~~~~~~~~~~~~~~
 Either - all new addressee, no IM + new IM to add | existing address, no IM + new IM to add
 | existing addressee, no IM + new IM to add | existing addressee, existing IM + new IM to add | existing addressee, existing IM + nothing to add
@@ -314,17 +314,17 @@ I think we're going to need a more complex data structure to tell KCL::addMetaCo
 
    I don't understand this <p>  -Olivier
 
-Fields to put in kabc
+Fields to put in tdeabc
 ~~~~~~~~~~~~~~~~~~~~~
-Relation between kabc entries and kopete metacontacts could be 1:1 or 1:many.  1:1 is neatest.
+Relation between tdeabc entries and kopete metacontacts could be 1:1 or 1:many.  1:1 is neatest.
 
 In Kopete contact list:
-include UID from related kabc entry
+include UID from related tdeabc entry
 
-In kabc
+In tdeabc
 Something like X-MESSAGING-MSN:[email protected] for each protocol account that contact uses.
 
-We should keep the extra stuff in kabc to a minimum.  We can store nicknames in contactlist.xml.
+We should keep the extra stuff in tdeabc to a minimum.  We can store nicknames in contactlist.xml.
 
 We should allow plugins to save some data:
 Some protocol allow to reach phone numbers, or more (see the ICQ info page)
@@ -332,9 +332,9 @@ It would be useful if KABC could remember what application writes an entry. so w
 
 Or like the language or the PGP public key
 
-It is too complex to store the phone number according to icq as well as the kabc phone number and every other protocol's idea of phone.  The fields would be of no use to any app other than the inserting program or else we would have to update the world.  We *should* have a facility to insert information obtained from protocols into the common kabc fields but this is a hard problem to solve neatly.
+It is too complex to store the phone number according to icq as well as the tdeabc phone number and every other protocol's idea of phone.  The fields would be of no use to any app other than the inserting program or else we would have to update the world.  We *should* have a facility to insert information obtained from protocols into the common tdeabc fields but this is a hard problem to solve neatly.
  - - I think it is not, ICQ phone number ~should~ be the same as all others one.  storing it here is just a way to *centralise* all information about someone.  Then, when you want to know his phone number, you look only there, and not at every place
- 		*problem: how to trust the information? that's why kabc could handle a source of the information
+ 		*problem: how to trust the information? that's why tdeabc could handle a source of the information
 
 
 KABC Participation modes
@@ -371,15 +371,15 @@ Scenario 2:
 Mandatory
 ~~~~~~~~~
 Scenario 1
-1) When fetching SSCL, automatically create synthetic kabc entries.
+1) When fetching SSCL, automatically create synthetic tdeabc entries.
 Scenario 2
-1) Fetch SSCL, ask user to create kabc entry normally.
+1) Fetch SSCL, ask user to create tdeabc entry normally.
 Hybrid 1-2
 1) Fetch SSCL
-2) Match SS contacts with kabc entries and associate automatically.  Unmatched contacts are associated with synthetic kabc entries.
+2) Match SS contacts with tdeabc entries and associate automatically.  Unmatched contacts are associated with synthetic tdeabc entries.
 
 -- For
-.) Can integrate with kabc contacts without disturbing user
+.) Can integrate with tdeabc contacts without disturbing user
 
 -- Against
 .) User has control of address book, this removes that control.
@@ -422,7 +422,7 @@ But how to use such as information available only at runtime, like the Status.
 2) KMail could contact Kopete via DCop
    --too bad if i want to use another IM Client?
 
-3) add an interface in kabc (or other) which could contact Kopete, or the IM which is actualy running.  This is in effect what dfaure suggested above.
+3) add an interface in tdeabc (or other) which could contact Kopete, or the IM which is actualy running.  This is in effect what dfaure suggested above.
 
 KDE Games/Desktop sharing use of Kopete
 ---------------------------------------
@@ -453,7 +453,7 @@ see also Bug 63297: "meta-contact" global(local) display nickname for all accoun
 
 Notes: some user might don't want to export their info the the server.
 
-Yes this would be cool.  I think we need a general UI to control the flow of contact information between kabc and kopete.  The myself issue is the same as the metacontacts issue.
+Yes this would be cool.  I think we need a general UI to control the flow of contact information between tdeabc and kopete.  The myself issue is the same as the metacontacts issue.
 
 
 What about the API?
@@ -461,7 +461,7 @@ What about the API?
 
  In KABC
 ---------
-The actual add to kabc could be performed in KopeteContactList::addMetaContact()
+The actual add to tdeabc could be performed in KopeteContactList::addMetaContact()
 
 ACW::accept() -> KopeteContactList::adddMetaContact()
 
@@ -486,9 +486,9 @@ Gof: This was not our idea, we intend not to pollute the KABC with any more extr
 so for example, the pgp plugin will request the public key:
 metacontact->data("application/pgp-public-key");
 
-if the contact is in KABC, then libkopete will request info from kabc. Else, it will take the data stored internaly in the contactlist.xml (Gof)
+if the contact is in KABC, then libkopete will request info from tdeabc. Else, it will take the data stored internaly in the contactlist.xml (Gof)
 
-This is a good question.  I think since we have the constraint that we have to keep kabc clean, this is the way to do it. (Will)
+This is a good question.  I think since we have the constraint that we have to keep tdeabc clean, this is the way to do it. (Will)
 
 for contacts same things.
 Anyway? what if we have several contact in one metacontact.
@@ -498,15 +498,15 @@ messenging/msn         =>   [email protected] ; [email protected]   (it's a StringList)
 messenging/nickname    =>    Mr. X ; Mr. Y
 
 that looks fine, but how to make sure than Mr. X is for [email protected], imagine if we have icq contact, or other? (Gof)
-We should never store nicknames in kabc.  The metacontact name should be taken from the kabc formatted name (Will)
+We should never store nicknames in tdeabc.  The metacontact name should be taken from the tdeabc formatted name (Will)
 
 Of course every fields shouldn't be stored in KABC (for example: MSN's groups, or others)
-to know what can be saved or not in kabc, i see two ways:
+to know what can be saved or not in tdeabc, i see two ways:
 1) KopeteMetaContact::setData( QString key , QString data , bool saveToKAB);
 2) if the key is or not recognized by KABC. example, if i save  "messaging/msn-groups"  KAB is not able to store it, so don't store it in KABC
 
 
-Syncing contactlist info currently takes place when Kopete exits.  other kabc apps write kabc during their runs.  We will have to make changes to do this and to make sure that we don't try to write 200 kabc entries simultaneously with individual tickets after fetching the SSCL for a new account.
+Syncing contactlist info currently takes place when Kopete exits.  other tdeabc apps write tdeabc during their runs.  We will have to make changes to do this and to make sure that we don't try to write 200 tdeabc entries simultaneously with individual tickets after fetching the SSCL for a new account.
 
 I don't think that syncing the KAB on an SSCL fetch is necessary. The only information we get when we fetch the SSCL is the contact name of that person who is on our SSCL, it's not until later, perhaps when we request the user info that we update the KAB. (Matt)
 
@@ -532,9 +532,9 @@ Association creates a 1:1 relationship between KMC and Addressee.  If we assume
 
 Association with existing contact: 1) No messaging information 2) Some messaging entries already exist.  Possible courses of action - add (only in KABC) accounts to MC - ask (how do we remember what the user wanted the next time we read the KABC)
 
-What if a related kabc entry is deleted while Kopete is running?
+What if a related tdeabc entry is deleted while Kopete is running?
 
-Deserialising contact from contactlist.xml - do we try to check the kabc entries and create any accounts that we find there but not in the contactlist.xml?
+Deserialising contact from contactlist.xml - do we try to check the tdeabc entries and create any accounts that we find there but not in the contactlist.xml?
 
 When to update KABC
 -------------------
@@ -544,7 +544,7 @@ NOT when starting kopete and the MC is filled with contacts!
 *) When adding a new contact (Use case: A new contact messages me, I add them to my contact list, and then I want to play a game with them, and invite them using IM, for example)
    KopeteContactList::addMetaContact()
 *) When linking an existing contact to KABC (so other apps gain the benefit of the new link)
-   handle this in KMC::setMetaContactId() - remember issues if a link is changed, do we delete the kabc fields?
+   handle this in KMC::setMetaContactId() - remember issues if a link is changed, do we delete the tdeabc fields?
 *) When adding new contacts to a KMC.
 	KMC::addContact()
 *) When moving contacts between KMCs. KC::setMetaContact()?