Hello Thomas,
> 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.
The NFS gives possibility to create complex conditions and to see the conditions
in more understandable way - it's an advantage in comparison to the OFS. The
drawback is that a lot of Windows controls must be created and handled. We must
overcome the slowness, but it is not a trivial thing to do - either a new
condition editor control must be written or we should optimise the way the
exiting controls are being handled.
Before we find a solution, I would recommend a trick that would help in most
cases - instead of numerous conditions of the same type I would recommend to use
a single condition with multiple alternatives, i.e. instead of
Sender contains [EMAIL PROTECTED]
OR Sender contains [EMAIL PROTECTED]
OR Sender contains [EMAIL PROTECTED]
...
OR Sender contains [EMAIL PROTECTED]
you should use
Sender contains any of [EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
....
[EMAIL PROTECTED]
This may even make condition evaluation a bit faster.
> 2.) Also, people have correspondence with incoming and outgoing mail. for
> each new communication partner, they have to manually create two
> filters. Other clients have an option to just save the reply in the
> same folder as the original message. 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
Basically, incoming and outgoing filters have different semantics and context:
senders and recipients are changing over, source folders are different, possible
action sets may become different in future... I don't see a wide range of tasks
that require same sets of actions for both incoming and outgoing messages.
Another thing is handling of filters available for different categories - it
must be possible to specify position of "multipurpose" filters in files lists in
each category, how sub-filters must be processed, what to do if a filter is
deleted from a category, etc. etc. It's not that simple as it may look.
For very specific you are talking about (i.e. placing messages to/from a single
sender), it is possible to use a pair of incoming/outgoing filters that looks
for
a presence of a sender/recipient in a specific address group and moves message
to a folder determined by template like Friends\%ABFROMNAME (%ABTONAME for
outgoing filter). This way, you may have just two filters for a range of
correspondents. Well, it may be tricky, but it's an elegant solution IMO.
Another possibility should become available soon - specifying the folder to
store a message in for each new message and providing macros for doing so. This
is a long standing wish and it was already given as a task to the team.
> 3.) And the last major reason why TB is not the perfect client is that it
> does not download images from the internet.
It's just another long standing wish which was almost put into production
recently, but the developer was thrown into fixing his bugs in other area.
So, this is going to be implemented as soon as he fixes his bugs. I believe I
was talking about this many moons ago, but I'm not sure whether it was in
private or in some TB! ML - this is a planned feature which will be implemented,
but nobody knows when exactly.
When it will be implemented, it will come with three options: always on, always
off, always confirm with possibility to select images to download. By default,
it
will be either off or confirm with all images deselected (except whitelisted).
> 4.) One serious shortcoming has been fixed: In this latest beta series, I
> cannow see all recipients of an email message, and if the list of
> recipients is longer than one line, TB will open another line. this
> was a problem, because I cannot expect from my colleagues to press
> shft-crtl-K and look at all headers. This ridiculous thing has
> fortunately been fixed.
It required complete rewriting the message header component and took long time,
but I'm glad that's worth it. It also removed a problem with Ctrl+Shift
selection in a header field. The component is now available only for viewing,
the next Beta series (I believe) will include adding editing capabilities to it
as well as some other valuable additions like LDAP lookup for address fields and
some other...
> 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.
This is another long standing wish, I agree. It just keeps falling off the to-do
list from each Beta series and we must add it to the "hot" list now. I won't go
deep into explaining why it happens so - basically, it's lack of resources (we
have some other non-public projects running and that often takes too much time
and resources from TB! project, but we have to deal with such things anyway) and
some management faults as you may have guessed already.
> 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.
Sometimes, I miss it either, but being an insider for many years I can explain
things to myself, but won't go to public with those explanations. 9Val tried to
put his vision of some problems many times earlier, I did it many times before
him, some people understand, some don't agree, some just ignore. From what I see
now, the best we can do for now is do our best and get the problems fixed - this
is what we actually do now (the explanations of nature of tabs and other fancy
things may be found in previous messages in TBBETA). I am sorry for lack of
communication with testers and users, but it takes really long time and we have
too much job to do and, as I told you before, we are limited in resources.
--
Best regards,
Stefan mailto:[EMAIL PROTECTED]
________________________________________________________
Current beta is 3.62.05 | '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/
