[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kopete-devel
Subject:    Re: [Kopete-devel] Misc info re: 0.6 release and showstoppers
From:       Martijn Klingens <klingens () kde ! org>
Date:       2003-01-30 20:37:49
[Download RAW message or body]

On Thursday 30 January 2003 17:24, Stefan Gehn wrote:
> 1. I don't get why I want my Contacts get renamed based on the MC name. I
> like to see the real nicknames in the Contacts but normally chat using a
> real-name. At least that's how _I_ use MetaContacts. I don't want to "get
> rid" of the contact's nicknames :)

Hmm, and I most definitely do :)

It would be kind of annoying with server side contact lists to switch clients 
and have a contact list that is different from your Kopete one. I thought ICQ 
used a serverside list too now?

> So what to do?. Another option is probably out of question (I smell
> featureitis *g*) and my current icq-hack is not nice either because not all
> protocols behave in the same way now. Maybe we have to rearrange our
> thoughs about what MetaContacts are for, in order to create a proper
> solution.

To me the meta contact _is_ the contact, and it's only technically a container 
of smaller entities (KopeteContact), but not GUI-wise. For me a meta contact 
would work perfect if it acted as a single contact and would make sure that 
'in the background' all smaller sub-contacts are synced automatically and 
kept in sync.

The sync direction (from KMC to KC, from KC to server, from server to KC and 
from KC to KMC) should ultimately be configurable. What I would like to see 
is roughly the following:

1. When adding a KC to a new KMC it gets the display name from the server, as
   does the KMC. The KMC is set to sync to and from the KC.
2. When the KC changes names and sync form a KC is set the KMC changes too
   _AND_ all other KCs in the KMC are also renamed.
3. When another KC is added to the KMC and sync from a KC is set the entire
   KMC and all KCs take the display name from the new KC.
4. When renaming a KMC and sync to a KC is set all KCs are renamed too and
   sync from a KC is disabled (KMC is authoritive now, KC changes no longer
   propagate back, KMC renames OTOH always propagate forward).
5. When renaming a KMC and sync to KC is disabled nothing is done to the KC.

Your (currently disabled) code does #1 and #2. My code does #4. Not 
implemented are #3 and #5, nor is there a way to set/reset the sync.

We definitely don't have time to implement a GUI for this for 0.6, not to 
mention that I'd prefer a way that works automatically, without GUI. I see no 
way to reset the 'sync to KC' using the above heuristics though, and that one 
is absolutely needed. In fact, that's the option you are missing.

I could disable the sync for 0.6 (it's a one liner, just comment out the call 
to c->rename() in KMC::rename()) but for after that we definitely need 
something better.

What should we do? Disable now, but continue discussing the implementation for 
0.7 in this thread?

-- 
Martijn

_______________________________________________
Kopete-devel mailing list
Kopete-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/kopete-devel
[prev in list] [next in list] [prev in thread] [next in thread]