Summary: | Kopete logs into MSN, connects and pops up current contacts and mail, and then disconnects. It will not stay logged in. | ||
---|---|---|---|
Product: | [Applications] kopete | Reporter: | Slaine Fullerton <dark_times> |
Component: | MSN Plugin | Assignee: | Kopete Developers <kopete-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | crash | CC: | andri, ifinci, leo, marc.collin, tom+kdebugs |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | openSUSE | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: | RTF document containing buggy characters in kopete MSN plugin display name |
Description
Slaine Fullerton
2004-03-01 19:02:16 UTC
I had this yesterday (apart from the crashes) but it's better again today. Possibly it was a server issue. I presenet and continue to present this bug as of this writting i have the same problem since 2days. (Kopete 0.8.0 KDE 3.2.0 SuSE 9.0 rpmĀ“s) About the disconnection: It's a problem with the contactlist handling. MSN sever suddenly decided to change every group number in the server list. A simple solution could be to remove the contactlist.xml file. If you don't want to loose data, you can repair it manualy, by removing every msn group information in it. (i.e. <plugin-data-field key="group"> AND <plugin-data-field key="xxx@msn.com id"> ) removing the contactlist.xml works fine. thx :-) Do you think we should keep this bug open since the problem really lies in the MSN servers and they're going to mess everybody's contact list up anyways, or should we try to work around it? Personally, I vote for marking them as invalid because we shouldn't be putting hacks in our code because MSN decided to screw everybody's contact list up. :/ On March 2, 2004 08:50 pm, Matt Rogers wrote:
> should we try to work around it? Personally, I vote for marking them as
> invalid because we shouldn't be putting hacks in our code because MSN decided
> to screw everybody's contact list up. :/
To me, this is just another reason the often asked for option ( and too hastily dismissed )
to be able to tell Kopete to *NOT* sync the contact lists with the server.
In this case you could disable the sync, connect with MSN, move all your MSN contacts
to the root group, and reconnect, so you don't have MSN corrupting all your other data.
On Wednesday 03 March 2004 1:08 am, Jason Keirstead wrote:
> To me, this is just another reason the often asked for option ( and too
> hastily dismissed ) to be able to tell Kopete to *NOT* sync the contact
> lists with the server.
I agree. Here's what I think:
When a protocol finds something's different on the SSI to the local list, it
tells libkopete, which then chooses either to update the contact list, ignore
it, or ask the user, depending on something set in the preferences.
Richard
On March 2, 2004 09:17 pm, Richard Smith wrote:
> When a protocol finds something's different on the SSI to the local list, it
> tells libkopete, which then chooses either to update the contact list, ignore
> it, or ask the user, depending on something set in the preferences.
I have been pushing for a scheme like this for years it seems...
On Wednesday 03 March 2004 02:21, Jason Keirstead wrote:
> I have been pushing for a scheme like this for years it seems...
And we've been working towards an API in libkopete that supports this without
code duplication in all plugins for years too.
I think we all want that, but the current framework doesn't allow it without
considerable effort. For the longer term I'm all for it, but IMNSHO *all* the
syncing should be handled consistently and protocol-independent in libkopete.
Until it's moved there I object to ugly hacks to accomplish this.
*** Bug 76621 has been marked as a duplicate of this bug. *** CVS commit by ogoffart: Fix the crahs of the bug 76520 CCMAIL: 76520-done@bugs.kde.org This crash shound't happen anymore in KDE 3.2.1, i fixed another thing that make the group being not renamed, so no crash. Also, i would like to know if it's possible to commit in both two branch on the same commit M +1 -1 kdenetwork/kopete/protocols/msn/msnaccount.cpp 1.61.2.4 --- kdenetwork/kopete/protocols/msn/msnaccount.cpp #1.61.2.3:1.61.2.4 @@ -645,5 +645,5 @@ void MSNAccount::addGroup( const QString void MSNAccount::slotKopeteGroupRenamed( KopeteGroup *g ) { - if ( g->type() == KopeteGroup::Normal ) + if ( notifySocket() && g->type() == KopeteGroup::Normal ) { if ( !g->pluginData( protocol(), accountId() + " id" ).isEmpty() && *** Bug 76714 has been marked as a duplicate of this bug. *** *** Bug 77072 has been marked as a duplicate of this bug. *** As can be seen in this debian bug report, apparently, it still occurs in kopete 3.2.1: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=237337 Or would this be a different bug ? Should I reopen this bug ? > Should I reopen this bug ?
The disconnection problem is fixed in HEAD, not yet backported in BRANCH, i'm
waiting to see if my fix has not side effect.
Will be probably in KDE 3.2.2
The actual solution to fix it is to remove the contactlist.xml
*** Bug 79067 has been marked as a duplicate of this bug. *** Removing contactlist.xml hasn't fixed this problem for me in KDE 3.2.2 with Kopete 0.8.2. It worked fine before, but now it has stopped. Could of course be fine by the morning, but if windows users can log in on the same network as me, then i would have thought I could too. Created attachment 5935 [details]
RTF document containing buggy characters in kopete MSN plugin display name
I found the problem - a contact on my list was using non standard characters in
their display name and kopete couldn't handle it. This is a bug and needs
reopening. I attach an rtf document to show the characters being used.
That makes sense. I live in Iceland i have lots of people in my contact list that uses weird display names. However, removing the contact list, restarting kopete works for me. That, unfortunately did not work for me. The only way I can rectify the situation currently is to ask that user (who also uses Yahoo IM) to change their display name or log out, which for some reason they are reluctant to do either. Just very very embarrassing to have to do that. |