On Wednesday, October 05, 2005, at 03:31 PM, Paul Van Noord wrote: DAC>> To me, using the attachment is what one is doing if one is attempting DAC>> to forward it. TB! should assume that the user wants it to do what the DAC>> user tells it to do. If the user is not interested in the attachment, DAC>> why should TB! know to go back and download it then forward it.
> I agree! IMO, the following should happen: Hit forward and TB! popups up this message: The attachment/s associated with this message have not yet been retrieved from the server. Do you wish to retrieve and send the attachment/s as well. [Yes] [No] [ ] Make my choice the default. (There should be an option in the preferences so that you can adjust the default behaviour, i.e., prompt all the time or yes/no all the time.) Yes - will make TB! retrieve the attachments. No - will make TB! generate the message with null attachments. Those not wanting null attachments can delete them. Those wanting null attachments will leave them alone. This part, I could do without, but you, Paul, mentioned that the null attachments would be useful to you. :) I strongly believe the option should be there. Why? I may wish to forward the message without the attachments. Why should I then have to download the attachments which may be huge, take up my bandwidth doing all of that, only to delete them, as has been suggested? Good IMAP is about efficiency. In fact, a fabulous IMAP client will allow you to forward only some of the attachments if there are multiple attachments. It will then retrieve only those attachments you need to include in your forwarded message copy. I'm just not sure how I'd elegantly go about it. Perhaps this could be done: After hitting yes, that you wish to retrieve the attachment/s, another pop-up appears for those messages containing multiple attachments. The pop-up will list the attachments that you may then use to select those attachments you wish to send and hence retrieve. It's not all the time that the user has enough bandwidth to just retrieve attachments ad lib. I'm one such user and I know I'm not alone, hence my appreciation for them. It's this sort of thing that I miss about Mulberry. However, TB!'s current behaviour is *just* adequate. I avoid certain messages at work because of this. -- -= Curtis=- Using TB! v3.61.07 Echo (Beta) System Specs: http://specs.aimlink.name =-=-= ...Oxymoron: Rising Deficits.
pgpI89csJY4lR.pgp
Description: PGP signature
________________________________________________________ Current beta is 3.61.09 (Echo) | '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/