[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 21:21:23
[Download RAW message or body]

On Thursday 30 January 2003 21:58, Stefan Gehn wrote:
> > 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).

Hmm, might make sense to have 'sync to KC' take precedence here if both are 
set and only take the new KC's new if 'sync from' is set, but 'sync to' is 
not.

> > 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
> :)

That's my problem too. It's also the reason why most of it is not implemented. 
If you hadn't done #1 and #2 I certainly wouldn't have done them myself yet, 
since I still haven't figured out the GUI side of things yet.

And if I wasn't annoyed so much about my display names not synced to the 
server because MSN didn't react on KMC renames I would probably have put a 
bit more thought in it and realized that the rename shouldn't be done 
unconditionally (as it is now) but needs a toggle somewhere...

This sucks a lot. Without the rename sync contact lists tend to become a mess, 
with it people who like it are screwed. And I want this somehow done 'right' 
without adding GUI options.

Do you see any way to make this work ok for both of us by chance without 
adding GUI stuff?

> > 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 :)

Uhm, true :)

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

Well, if we didn't have this discussion there would probably another fix in 
CVS now that I considered a bug until you told me you prefer to see the 
'real' display name: make the chat windows use the KMC's displayname 
everywhere instead of the KC's one.

Personally I only want to be able to see the 'real' nick somewhere in a 
tooltip or the user info in case I'm really interested in that and use the 
KMC's data the rest of the time, but it seems you will fiercely oppose me 
here :)

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

For MSN it currently seems to work well. No other protocol implements rename() 
now yet. We could slip this for 0.6 and implement it correctly in 0.7. It's 
easy to disable and as I'm always using CVS I will only suffer from the 
problem myself for about 6 days or so, and I'll surely be able to survive 
that :)

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