TriEnt wrote:Let me take back my early comment. I DO test, I've been using Mozilla since 1.1 and will do the same with this great tool, which btw it's quite interesting to think why this has never been implemented when it adds so much value. Think of going thumbdrive when 500 MB of e-mail suddenly drops to 100 just because of this tool. So thanks again ausdilecce!
Now for the comments:
1. I still think the paperclip should stay there. The need to have access to the message history (what is it that it originally contained) is I believe far more important than the annoyance of seeing the paperclip in the message list view. After all, what made people ask for this feature was not the issue of having old attachments but their size and the fact that they are either already stored on disk or are obsolete (while the message isn't).
My thoughts exactly. ( I just couldn't explain it as well as you did )
TriEnt wrote:But, we live in a world with different opinions and different tastes, hence if this can be tuned via a GUI checkbox then it should make everybody happy. It should be pretty easy to implement I'd assume.
No, not really. The paperclip toggle is set by TB when it 'sees' attachments. So if one wants the paperclip to go away, *all* indications of an attachment need to go away.
TriEnt wrote:The new (dummy) attachments names should be again tunable via some sort of GUI preference. For example a C-like %s syntax e.g. "Erased - %s" or "%s - deleted". I'd rather vote for the second option because it keeps the original name as the top priority element (think when the attachment window is too tiny and only part of the names is visible. It's important to see the relevant part).
Very good point. that idea is on the to-do list now ( as a tunable pref ).
TriEnt wrote:While I too thought about adding a footer to the message, with the list of removed attachments, I see some major con's here:
- we should never leave room for someone to think that the original author wrote that. If we alter the message body, one could be tricked and this could lead to trouble (think legal terms). It might be fine with 99% of the people, but others' mileage might vary big time and we certainly don't want that (think corporate users).
Absolutely right. This is the issue ( I think ) so soo many comments were made about in the bug filing.
TriEnt wrote:- how do we deal with HTML mail? Adding text to a compact fully-formatted page can only break its layout. Unaesthetic. Why bother adding one feature and risking lots of potential bugs.
Again, absolutely right. There is (almost) NO way to code this to make it work 'correctly'
TriEnt wrote:- how do we deal with a scenario when multiple attachments are deleted one by one at different times. Again, why take chances when we need this simple and efficient.
That was my initial feeling. I really didn't like what it would do to the overall look n feel, nevermind what the coding would have to look like to make it right under all possible circumstances.
TriEnt wrote:Agreed with jimmy73, we need to be able to remove only one attachment at a time. Actually, that should do it (I think the cases when one needs to remove all 50 attachments of a given message are quite rare), although it doesn't hurt if "delete all" stays there. Just do the same as with "save as" / "save all", and again, it should make everybody happy.
The thing I am struggling with at the moment is UI. How would one 'choose' which attachments to strip/delete/save/whatever. Listbox? Listbox w/ checkboxes? prompts ? Ugg. ( think possibility like wanting to delete the 3rd attachment in a message with 10 attachments. Ugg ) I really dont even like TBs own attachment listbox in compose. Any ideas on this ?
TriEnt wrote:Can't wait to see this turn into a fine final product!
Cheers,
Lf
I can't either !