Bug 139701

> Isn't it possible to do it once the status of a user has changed?

It is possible but unreasonable. The away message is independent from the status, e.g., now listening messages change regularly without any status change.

IMHO, this bug is a duplicate of Bug 129501

Oh, I'm sorry, I didn't find that bug.
Yes, it is a duplicate, but in my case not resolved.

I understand the problem regarding the independence from status, so frequently polling has to be done. 

Nevertheless, I think at least it should be configurable at which rate kopete refreshes the away msg. Those "Now Listening" stuff is completely unrelenting to me. So it is unnescessary for me that Kopete annoys other people that frequently. 

Greetings,
Karsten

I'd like to second this... Too many people are annoyed at me because of this - and most of the time I'm not even interested in their away messages.
For me a possibility to turn off the automatic checking, but an additional context menu entry to check manually (and display it in an additional dialog) would be the perfect solution.

(BTW, this would be helpful for another reason: My friends sometimes put URLs into their away messages. As I can't select the text displayed in the contact list I have to copy the addresses by hand. That's tiresome, to say the least.)

SVN commit 620836 by rjarosz:

Fix bug 139701: Away msg polling too frequently.

When user or Auto-Away plugin change status in ICQ we change invisible status even though invisible status didn't change at all and as a 
result of this ICQ server sends us packets that indicate status changes for all contacts.

BUG: 139701



 M  +15 -21    changevisibilitytask.cpp  


--- branches/KDE/3.5/kdenetwork/kopete/protocols/oscar/liboscar/changevisibilitytask.cpp #620835:620836
@@ -79,38 +79,32 @@
 {
 	SSIManager* manager = client()->ssiManager();
 	Oscar::SSI item = manager->visibilityItem();
-	Oscar::SSI newSSI;
 	if ( !item )
 	{
 		kdDebug(OSCAR_RAW_DEBUG) << k_funcinfo << "Didn't find a visibility item" << endl;
+		setError( 0, QString::null );
 		return;
 	}
 	
-	//remove the old item and add the new item indicating the
-	//change in visibility.
-	manager->removeItem( item );
-	kdDebug(OSCAR_RAW_DEBUG) << k_funcinfo << "found visibility item. changing setting" << endl;
-	newSSI = Oscar::SSI( item.name(), item.gid(), item.bid(), item.type(), QValueList<TLV>(), 0 );
-	QValueList<TLV> newList;
-	QValueList<TLV>::const_iterator it = item.tlvList().begin(), listEnd = item.tlvList().end();
-	for ( ; it != listEnd; ++it )
-	{
-		if ( ( *it ).type != 0x00CA )
-		{
-			TLV t = ( *it );
-			kdDebug(OSCAR_RAW_DEBUG) << k_funcinfo << "adding TLV of type" << t.type << endl;
-			newList.append( t );
-		}
-	}
-	
 	Buffer c8tlv;
 	BYTE visibleByte = m_visible ? 0x04 : 0x03;
 	c8tlv.addByte( visibleByte );
 	
-	TLV c8( 0x00CA, c8tlv.length(), c8tlv.buffer() );
+	QValueList<Oscar::TLV> tList;
+	tList.append( TLV( 0x00CA, c8tlv.length(), c8tlv.buffer() ) );
 	
-	newList.append( c8 );
-	newSSI.setTLVList( newList );
+	Oscar::SSI newSSI(item);
+	if ( Oscar::uptateTLVs( newSSI, tList ) == false )
+	{
+		kdDebug(OSCAR_RAW_DEBUG) << k_funcinfo << "Visibility didn't change, don't update" << endl;
+		setSuccess( 0, QString::null );
+		return;
+	}
+	
+	//remove the old item and add the new item indicating the
+	//change in visibility.
+	manager->removeItem( item );
+	kdDebug(OSCAR_RAW_DEBUG) << k_funcinfo << "found visibility item. changing setting" << endl;
 	manager->newItem( newSSI );
 	sendEditStart();
 	

Karsten wrote:
> So it is unnescessary for me that Kopete annoys other people that frequently. 
and Frank wrote:
> I'd like to second this... Too many people are annoyed at me because of this [...]

Sorry, this is a OPP (Other People's Problems). If they offer their away message for reading, they shouldn't bother others actually reading it. Just my $0.02.

In theory, I agree wholeheartedly.
But you know how people are... Arguing with them over who's to blame is no use in most cases.

(And I have to admit, in my Windows-times I used such notifications as well and would have been annoyed at the request-spamming.)

*** Bug 137048 has been marked as a duplicate of this bug. ***

*** Bug 147646 has been marked as a duplicate of this bug. ***