| View previous topic :: View next topic |
| Filter changes should wait to process until the user says so? |
| Agree Strongly |
|
50% |
[ 1 ] |
| Agree |
|
0% |
[ 0 ] |
| Disagree |
|
50% |
[ 1 ] |
| Disagree Strongly |
|
0% |
[ 0 ] |
|
| Total Votes : 2 |
|
| Author |
Message |
Bones76
Cadet

 Joined: Dec 03, 2006 Posts: 3 Location: USA
|
Posted: Tue Dec 05, 2006 2:23 pm Post subject: REFILTER BUTTON (user option) |
|
|
One of the things that I like LEAST about MWP is the extremely sluggish nature of the filters, especially when you want to "tweak" one tiny filter setting or change it's priority placement in the list.
I have an idea (one of many) that should help fix this problem quickly. This idea I am calling the REFILTER BUTTON and it should be very easy to implement, probably could be done in a day (details below will show how simple these changes are).
Currently the MWP software appears to use the file Filters.txt for both the actual filter processing and also for handling the user-interface in real time. This approach needs to be changed. There is no reason why the filters need to be processed automatically. The changes can be defered until the user is ready to test/use the changes.
What I propose is as follows (key steps are followed by some fairly explicit how-to's):
STEP 1. On program startup copy the data files into new "pending files". Also initialize a global variable that will be needed later.
- copy Filters.txt --> Fpending.txt.
- copy Blacklist.txt --> Bpending.txt.
- create a boolean global variable named "EFLAG" and set it to FALSE.
STEP 2. Continue to point the filter processing code to Filters.txt/Blacklist.txt as before.
- no changes required here.
STEP 3. Point the user interface (filters sidebar, etc) to read/write to the pending files.
- add 2 new filepointer variables.
- add 2 new "file open" statements.
- execute search/replace to use new filepointers everywhere EXCEPT for the filepointers used by the actual filter processing (see STEP 2 above).
STEP 4. When the user is done editing or otherwise changing a filter or blacklist item the changes will now be saved into the appropriate pending file. A flag needs to be set for that entry and the entry needs to be displayed in bold text to indicate it has been changed.
- Clone the existing code section that adds a "!" to the beginning of the line for a disabled blacklist entry.
- Modify the cloned code to add a "~" to the beginning of any modified entry. This may require 2 clones, one for blacklists and 1 for filters.
- Modify the cloned code to set EFLAG to TRUE every time a "~" is added.
- Modify the filters sidebar "display routine" to use bold text if position 1 of that entry is a "~".
- Modify the "read routine" for the user interface to ignore any leading "~" chars on any given entry.
STEP 5. Currently MWP immediately re-processes the filters after every change. DON'T!!! Instead add a new button to the user interface and save the processing of ALL changes until that button is pressed.
- Create a new button labelled "REFILTER" for the user interface.
- Create a routine to do the following when the REFILTER button is pressed:
- (1) Strip both of the pending files of ALL leading "~" chars.
- (2a) Copy Fpending.txt --> Filters.txt.
- (2b) Copy Bpending.txt --> Blacklist.txt.
- (3) Set EFLAG to FALSE.
- (4) trigger normal filter processing.
STEP 6. Modify the REFILTER button display.
- If EFLAG = FALSE then grey-out / deactivate the button.
- If EFLAG = TRUE then highlight / activate the button.
STEP 7. Add a button named "CANCEL CHANGES" to the user interface.
- Create a routine to do the following when the CANCEL button is pressed:
- (1a) copy Filters.txt --> Fpending.txt.
- (1b) copy Blacklist.txt --> Bpending.txt.
- (2) set EFLAG to FALSE.
- (3) refresh filters sidebar display.
In the event that the program is exited with changes still pending, the result will be the same as pressing CANCEL since the next time the program starts up it will assume Filters.txt is current.
Ok, that's all. Sorry this was so lengthy to describe something so simple.
BTW, it would be trivial to make the software act as it currently does so this should be a user option (automatic refilter after every change -vs- manual refilter of pending changes).
|
|
| Back to top |
|
 |
stan_qaz
Premium Member
 Joined: Mar 31, 2003 Posts: 10578
|
Posted: Tue Dec 05, 2006 5:17 pm Post subject: |
|
|
My filters run fairly quickly so this wouldn't do anything for me.
Many other suggeted changes like adding SURBL or SPF would provide a lot bigger improvement for my use. _________________ Questions? Try the wiki
http://wiki.castlecops.com/MailWasher_Pro
|
|
| Back to top |
|
 |
Ikeb
Special Response Team Forums Admin
 Joined: Apr 20, 2003 Posts: 16505
|
Posted: Thu Dec 07, 2006 9:19 am Post subject: |
|
|
Re: filters being run each time a filter is changed -- yes that is the case if changing a filter from the side panel but not from Spam Tools. If making a lot of changes, use the Spam Tools >> My Filters interface. _________________
|
|
| Back to top |
|
 |
|
|