[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:       Stefan Gehn <sgehn () gmx ! net>
Date:       2003-01-30 20:58:32
[Download RAW message or body]

Moin, don't worry if the thoughts are a bit unsorted, I'm going to bed now ;))

On Donnerstag Januar 30 2003 21:37, Martijn Klingens wrote:
> 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?

No, it doesn't. It just downloads but writes only things back occasionally 
(don't know which parts it writes back yet, that'd need much more knowledge 
about libicq or documentation). Btw, just found something to rename a user in 
libicq :)

> 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.

Hmm, I wonder how these msn-folks will react that chat using their nicknames 
;)

> 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.

Eh, why that, why not take the KMC name then? That's the one a user usually 
sees and probably also wants to see elsewhere (if you really want to have one 
name everywhere).

> 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.

Hmm, disabling sync to KC will work HOW then? Sounds like an option to me :)

> Your (currently disabled) code does #1 and #2. My code does #4. Not

Was meant to do :D Also the AND in #2 is done by your code I think :)

> 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

> 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.

I think I found out how to make sure people can still access both names in icq 
:)
An ICQUser got Nick and Alias. Alias is the one that gets set on renaming that 
user and what gets sent to server as well (found something that should send 
things, have to test that).

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

Two ideas:
1. Don't disable rename and let plugins that already support serverside 
renaming work
2. Disable rename to make people happier who still like to see the original 
nicknames

I'm not sure which one is better. Actually you are right that syncing 
serverside lists as much as possible is a good idea but currently almost no 
protocol can do that properly.

Bye, Stefan aka mETz
-- 
sgehn_AT_gmx.net | ICQ#51123152 | Moege der Pinguin mit euch sein

_______________________________________________
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]