Hello Stefan, On Sun, 30 Oct 2005 13:29:32 +0200 GMT (30/10/2005, 18:29 +0700 GMT), Stefan Tanurkov wrote:
Thanks for replying at length. I appreciate it. >> 1.) If you have more than 10 filter conditions, you will have to wait >> several seconds (several minutes in case of 100 filter conditions) >> before the conditions are shown. ST> The NFS gives possibility to create complex conditions and to see the conditions ST> in more understandable way - it's an advantage in comparison to the OFS. Granted. ST> The drawback is that a lot of Windows controls must be created and ST> handled. I understand this. However, it is impossible to explain it to my colleagues. They just want the software to work as expected, not get an explanation why they have to wait several seconds or even minutes to update a filter. ST> We must overcome the slowness, but it is not a trivial thing to do ST> - either a new condition editor control must be written or we ST> should optimise the way the exiting controls are being handled. I hope you find that solution soon, so that I can proudly recommend TB again. ST> Before we find a solution, I would recommend a trick that would help in most ST> cases - instead of numerous conditions of the same type I would recommend to use ST> a single condition with multiple alternatives, i.e. instead of [...] 9Val recommended the same workaround, but failed to advise how I can easily convert my hundreds of filters. I did try this workaround with three example filters but didn't get it to work. >> 2.) Also, people have correspondence with incoming and outgoing >> mail. [...] I'm ready to set up a filter, but there is no way I can >> explain why in TB two filters have to be set up. >> https://www.ritlabs.com/bt/view.php?id=3319 ST> Basically, incoming and outgoing filters have different semantics and context: ST> senders and recipients are changing over, I filter on Headers. ST> source folders are different, Inbox versus Sent. ST> possible action sets may become different in future... Not in my example, which I think is not very unusual. But if they do, different filters will have to be created, this is normal. ST> I don't see a wide range of tasks that require same sets of ST> actions for both incoming and outgoing messages. Well I do: If Header contains <[EMAIL PROTECTED]> move to Folder X. That's what almost all of my incoming and outgoing filters do. The set-up is the exact same for Incoming and Outgoing. OK, the source folders are different (Inbox versus Sent), but take a look at the BT report mentioned above, and a tickmark can set set it to both or either. ST> Another thing is handling of filters available for different categories - it ST> must be possible to specify position of "multipurpose" filters in files lists in ST> each category, how sub-filters must be processed, what to do if a filter is ST> deleted from a category, etc. etc. It's not that simple as it may look. OK, we are talking shop now. My suggestion is as follows: I assume you have one module/procedure for incoming filters, one for outgoing filters. Let's ignore for a moment that a lot of code may be duplicated. Instead of calling the modules for each category directly, the Sorting Office could call a superior module which calls the category modules depending on the tickmarks. I do think that the code duplication is unneccessary in the case of Incoming/Outgoing filters, as the only difference is the source folder. I am not using Read and Selective download filters, so I don't comment about those. ST> For very specific you are talking about (i.e. placing messages to/from a single ST> sender), it is possible to use a pair of incoming/outgoing filters that looks for ST> a presence of a sender/recipient in a specific address group and moves message ST> to a folder determined by template like Friends\%ABFROMNAME (%ABTONAME for ST> outgoing filter). This way, you may have just two filters for a range of ST> correspondents. Well, it may be tricky, but it's an elegant solution IMO. No, this is exactly what I criticise. I need to update two filters each time something changes, where one update should be sufficient. As mentioned earlier, I have hundreds of filters, all of them with multiple conditions (up to over a hundred conditions per filter). ST> Another possibility should become available soon - specifying the folder to ST> store a message in for each new message and providing macros for doing so. This ST> is a long standing wish and it was already given as a task to the team. I'm not exactly sure this would do what I mean, but I'm looking forward to it. >> 3.) And the last major reason why TB is not the perfect client is that it >> does not download images from the internet. ST> It's just another long standing wish which was almost put into production ST> recently, but the developer was thrown into fixing his bugs in other area. ST> So, this is going to be implemented as soon as he fixes his bugs. OK. :-) ST> When it will be implemented, it will come with three options: always on, always ST> off, always confirm with possibility to select images to download. By default, it ST> will be either off or confirm with all images deselected (except whitelisted). Excellent! A wish will come true. I hope we will not have to wait so long that everybody looses faith again. >> 4.) One serious shortcoming has been fixed: In this latest beta series, I >> cannow see all recipients of an email message, [...] ST> It required complete rewriting the message header component and took long time, ST> but I'm glad that's worth it. It is. Thank you again. ST> It also removed a problem with Ctrl+Shift selection in a header ST> field. The component is now available only for viewing, the next ST> Beta series (I believe) will include adding editing capabilities ST> to it as well as some other valuable additions like LDAP lookup ST> for address fields and some other... You do have a plan... looking forward to the new beta cycle. >> 5.) Not fixed has been the shortcoming that if I set TB to download >> messages no bigger than 500K, and then this one mail comes in with an >> attachment of 1MB which I need, I have to go to the despatcher and >> manually find this mail in order to download it. ST> This is another long standing wish, I agree. It just keeps falling off the to-do ST> list from each Beta series and we must add it to the "hot" list now. Thank you! Yes, this is "hot", please don't let it cool down again. ST> I won't go deep into explaining why it happens so - basically, ST> it's lack of resources (we have some other non-public projects ST> running and that often takes too much time and resources from TB! ST> project, but we have to deal with such things anyway) and some ST> management faults as you may have guessed already. That's OK, understanding the problem is the first step to solving it. I hope that your insight does have the desired effect, and improvement can be felt by the beta community within short. >> These are POP-related problems that make me wonder who RL's target >> group is. Chat functions, Message list tabs, roguemoticons - all nice >> little toys I enjoy to play with. However, I miss the seriousness in >> developing a commercial email client. ST> Sometimes, I miss it either, but being an insider for many years I can explain ST> things to myself, but won't go to public with those explanations. 9Val tried to ST> put his vision of some problems many times earlier, I did it many times before ST> him, some people understand, some don't agree, some just ignore. I'm one of those who understand, but it doesn't help recommending the product. The world out there looks at hard facts, such as a software that works without explaining workarounds. The software industry has become very competitive, and people can move easily to another client - or not register a product if it isn't up to expectation within the 30 days trial period. Getting someone to download a trial version is one thing, making him use it and not abandon it after a day is another. Every necessary workaround or "trick" translates directly into lost revenue for you. Joe User doesn't want explanations about Windows handles or whatnot, he will just move on. That's a cold truth, sorry about that, but I want TB to be one of the few email clients to survive. ST> I am sorry for lack of communication with testers and users, but ST> it takes really long time and we have too much job to do and, as I ST> told you before, we are limited in resources. Just let us know your priorities. If TB is a major source of income, you will assign the resources accordingly (or increase your resources). If it isn't, you can either invest in making it the rock-solid product it was known to be earlier and thus increase sales and revenue, or sell it to someone who is interested. Slacking has only one outcome: Demise. I don't think you will want to see this, as you are one of the fathers. -- Cheers, Thomas. A bartender is just a pharmacist with a limited inventory. http://thomas.fernandez.hat-gar-keine-homepage.de/ Message reply created with The Bat! 3.62.07 under Windows XP 5.1 Build 2600 Service Pack 2 ________________________________________________________ Current beta is 3.62.07 | 'Using TBBETA' information: http://www.silverstones.com/thebat/TBUDLInfo.html IMPORTANT: To register as a Beta tester, use this link first - http://www.ritlabs.com/en/partners/testers/
