ChatZilla:Message Filter: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
m (→Existing things that could be done using filters: missed a brace) |
||
Line 56: | Line 56: | ||
*The stalk list | *The stalk list | ||
*Sound preferences (when to play sound) | *Sound preferences (when to play sound) | ||
*? (I'm fairly sure there are more, but can't think of any at 7.16 in the morning. This is a wiki, feel free to add them. | *? (I'm fairly sure there are more, but can't think of any at 7.16 in the morning. This is a wiki, feel free to add them.) | ||
The question is, what do we want to do with those existing things? Can we/Should we dynamically move them to some filter? Create a filter based on the lists/preferences? Opinions please! :-) | The question is, what do we want to do with those existing things? Can we/Should we dynamically move them to some filter? Create a filter based on the lists/preferences? Opinions please! :-) |
Revision as of 06:19, 2 January 2006
Aims
- Allow the user to specify exactly where any message should go, by use of a system based on filters, similar to mail/news.
- Make a default set of filters to mimic current behaviour. Keep this around in order to be able to switch back to it. You don't want users to mess stuff up and find themselves unable to return to a normally working state.
- Allow filters to specify whether the system should continue to look into other filters that may match.
- Save the filters using Silver's system for javascript object storage.
Filter rules
The user should be given an option to have all rules match, or just one (AND/OR difference) The filter rule system should be based on 4 fields:
- The Type of the rule (e.g. message type, message contents, source of the message, etc. etc.) Note that for wicked-leet-überness, we should also try to support functions. This rocks for plugins, who can alter anything they want this way.
- The type of match done. This can be any of:
- An exact match. This is easiest.
- Starts with. Slightly harder, but still easy compared to others.
- Ends with. Slightly unusual, but should be easy to do when the previous type is supported, and besides, don't kill people who don't understand regular expressions!
- Contains. Simple, and expected by normal users
- Regular Expression. Expected by power users.
- Function match. Used by the client itself and obviously also by plugins/scripts.
- The text/regular expression/function we're matching to. Note that the GUI won't support referencing a function here, it should just show an empty label. For now, don't count on an edit field for users to edit in their own custom functions. It may be done in a later stage.
- Optional negation field. Easier than adding 'Does not' entries for everything mentioned in field 2.
Types of rules
What you can possibly match:
- Source Network url.
- Source Server name.
- Target channelname.
- Target username (you, but remember that you can have various nicks! You could use this, for example, to make a 'beep' when people use your name, *except* when it contains "sleep". Nifty, eh?)
- Source username
- Message contents
- Message types (INFO, JOIN, PART, QUIT, etc., and we need a way to get nice names for all those stupid response codes (end of list, whatever))
Filter Actions
Somewhat surprisingly, we probably want 3 fields on 'what to do now'. So, suppose we matched a filter. What can the user tell us to do from the first field?
- Create tab for ... (source, target, handling, parent of handling etc.)
- Display on the target tab (passed in by the caller, usually server / channel / user)
- Display on the source tab (for example, the user who sent the message)
- Display on the current tab. (whatever's current when display is called)
- Display on the handling tab. (the tab display was called on)
- Display on the parent of the handling tab. This is the network/server tab for users/channels/dcc, and the client tab for networks/servers.
- Display on client tab. Plain, simple.
- Get Attention. Will flash the window. Ignores other fields.
- Set the tab state. Will use the other field to pick a state and tab to do this on.
- Play sound. Takes the second field into account: beep or url to sound file
- Dispatch. Takes the second field as the parameter.
- Run function. Only available using a plugin / script?
- Is important. Mark as an important line, just like stalking currently does.
Fallback for displays
Suppose a tab we want to display on does not exist? The user should be able to specify how to fallback (we can't just not display anything without notice). Suggestions welcome, the talk page should be good for that.
Existing things that could be done using filters
- The stalk list
- Sound preferences (when to play sound)
- ? (I'm fairly sure there are more, but can't think of any at 7.16 in the morning. This is a wiki, feel free to add them.)
The question is, what do we want to do with those existing things? Can we/Should we dynamically move them to some filter? Create a filter based on the lists/preferences? Opinions please! :-)