Version: 0.7.2 (using KDE 3.1.3) Installed from: compiled sources Compiler: gcc version 3.2.2 OS: Linux (i686) release 2.4.22 A way to ignore users (and edit the ignore list per-server) would be phenomenal.
Can you describe this, I never heard about this(seems not a part of the RFC). If you have some links to some docs, post them here and I'll think about it.
It's a feature pretty much all clients have, you do "/ignore <userhost>" and the client will discard all messages matching the userhost. Mostly used like killfiles for emails if certain people annoy you in a channel.
This is from ircii documentation: Usage: IGNORE [<nick>] [-|+|^][<message type>] IGNORE [<user@host>] [-][<message type>] The standard form of IGNORE allows you to specify which type of messages you wish to ignore from a user. The message type parameter can be one of the following: MSGS All MSGs received NOTICES All NOTICEs received PUBLIC All normal channel conversation INVITES All INVITEs received WALLOPS All WALLOPS received NOTES All NOTEs received CTCP All CTCPs received CRAP Anything else ALL All of the above message types NONE No message types You can ignore by nickname or by specifying a userid@hostname format. Wildcards may be used in all formats. You can specify multiple types of messages to ignore on the command line. Preceeding a type with a - indicates removal of ignoring of that type of message. For example: IGNORE BigCheese MSGS INVITES ignores MSGs and INVITES from BigCheese. IGNORE *@*.cmu.edu ALL -NOTES ignores all types of messages except NOTES from anyone from CMU. You may also specify a + before any message type to cause messages of that type from that user to be displayed with the nickname highlighted. (See SET HIGHLIGHT_CHAR) For example: IGNORE *Cheese* +MSGS will cause all MSGs from anyone with Cheese in their nickname to appear with their nickname highlighted. IGNORE * +PUBLIC +NOTES will highlight all PUBLIC messages and NOTES received. The + has no effect with the user@host name format. If you specify a ^ before a message type, then messages from the matching nicknames will be displayed no matter what. This allows you to exclude certain nicknames from larger matching lists. For example: IGNORE * MSG IGNORE BigCheese ^MSG This will ignore private messages from everyone except BigCheese. All forms of IGNORE use the - to remove ignore attributes, and the type NONE will remove the user from the list completely. All forms of IGNORE will match against the nickname with the most true matching characters. What this means is if you have: IGNORE BigCheese MSGS IGNORE * +ALL Then MSG's from BigCheese will be ignored, and all other types of messages from BigCheese will be unaffected. All messages of all types from any other user will be highlighted. See Also: SET HIGHLIGHT_CHAR
Subject: Re: [Kopete-devel] IRC plugin: Ignore feature[Scanned] IGNORE doesn't have anything to do with the RFCs because it is a client feature, has nothing to do with the server. As such, it should probably not be IRC specific. Many Kopete protocols support some method of ignoring. MSN has block user, ICQ has a block, so does AOL. I propose an API addition to KopeteContact that can be overloaded, virtual void ignoreContact( bool ignore, const QString &reason = QString::null ) virtual bool isIgnored(); ..where ignore is a bool that adds or removes this contact from the "ignore list" The default implementation in KopeteContact would use some form of a local Kopete only ignore list, where messages from these contact addresses would simply not be processed. Individual protocols could overload the method to use their own implementations that do things on the server. Of course the Kopete implementation would have to store the ignored contacts based on their contact ID rather than based on the contact itself, since if you are ignoring a contact you are probably going to delete him from your temporary contacts shortly afterwards. What do people think of this idea? The suggested API could probably be improved upon.
Note that some IRC servers have the SILENCE command, which allows you to keep a small list of server-side ignored users/masks. Don't expect the SILENCE table to be larger than 16 entries.
Subject: Re: [Kopete-devel] IRC plugin: Ignore feature On Wednesday 24 September 2003 14:33, Jason Keirstead wrote: > What do people think of this idea? The suggested API could probably be > improved upon. Yes :) I agree on the basic idea, but as for the implementation you mentioned: > virtual void ignoreContact( bool ignore, const QString &reason = > QString::null ) > virtual bool isIgnored(); I'd prefer the following: public: void setIgnoreContact( bool ignore, const QString &reason = QString::null ); bool isIgnored(); protected: virtual doIgnoreContact( bool ignore, const QString &reason ); Reasoning: - isIgnored should be non-virtual because it is really overkill to require subclassing, and it would make calling it from the KopeteContact c'tor impossible. The ignored status can already be deserialized there, before the contact-specific code is running. - setIgnoreContact should be non-virtual to make sure it's always run, even when doIgnoreContact is subclassed. If we don't do this we require plugins to always call the parent, and this way they can just add their own 'payload', the parent is called anyway.
> What do people think of this idea? The suggested API could probably be > improved upon. >..where ignore is a bool that adds or removes this contact from the "ignore > list" This is bad, because it does not allow wildcard-based filtering (see previously posted irssi documentation). On IRC one can change their nickname on the fly. One can also use the same nickname across multiple hosts.
Martijn As for your API suggestion, note that isIgnored() cannot be a member of KopeteContact. It would need to be a member of KopeteAccount, since "ignoring" a contact should be persistant, even if you delete him (think ignoring a spammer who is a temporary contact, then deleteing him). So it'd be like KopeteAccount::ignoreContact( const QString, &contactId, const QString &reason ) There'd also need t be some thing in the config pages to manage the ignore list, that could also interact with the protocol's own ignore implementations. Not sure how to work this part.
Subject: Re: [Kopete-devel] IRC plugin: Ignore feature On Tuesday 21 October 2003 14:55, Jason Keirstead wrote: > It would need to be a member of KopeteAccount, since "ignoring" a contact > should be persistant, even if you delete him (think ignoring a spammer who > is a temporary contact, then deleteing him). Good one. > So it'd be like KopeteAccount::ignoreContact( const QString, &contactId, > const QString &reason ) Agreed. I suggest post-3.2 for this though. > There'd also need t be some thing in the config pages to manage the ignore > list, that could also interact with the protocol's own ignore > implementations. Yes.
Re-assigning this as a request for general ignore functionality (and changing title to reflect this)
See http://www.jabber.org/ietf/draft-ietf-xmpp-im-22.txt section 10 "Blocking Communication" to see how this functionality can be implemented in the Jabber plugin to make it XMPP compatible.
Sander, if you would like to have this implemented specifically for the Jabber plugin, please submit a separate wishlist item there.
> Sander, if you would like to have this implemented specifically for the > Jabber plugin, please submit a separate wishlist item there. See Bug 81510
This bug has been changed entirely from it's original request, so I'm changing it back. I would like to see per-server ignore lists on IRC. This is to include standard IRC wildcard masks as implemented by ircii, so that I can ignore a nickname, username, host, or any combination thereof. It will also need to be able to filter what TYPES of messages from that user I might want ignored, as also indicated in the ircii documentation snippet above. I should be able to ignore only INVITEs from *@*.kopete.kde.org with the final implementation, as well as ALL messages from anybody with the nickname of 'foo' (not kopete internal contact ID since that doesn't match with IRC's implementation, but current nickname). This has nothing to do with a global ignore function, which I think is a very bad idea rather than implementing ignore functionality per-protocol, as many protocols actually have proper user blocking functionality that is superior to filtering incoming messages.
This bug has everything to do with a global ignore function. Just because we have global ignore functionality does not mean that individual protocols cannot have their own superior funcitonality that re-implements existing virtuals, the same way we do many other things. These things should be unified.
i wish ignore be implemented soon.
If you want it to be implemeneted soon, then I suggest that you take a shot at implementing it yourself. It might take awhile otherwise. Your contribution would be much appreciated.
*** This bug has been marked as a duplicate of 63839 ***