GNOME Bugzilla – Bug 224149
option to disable display HTML mail
Last modified: 2013-07-24 14:39:57 UTC
Please fill in this template when reporting a bug, unless you know what you are doing. Description of Problem: I want to be able to (optionally) disable rendering of HTML mail. Steps to reproduce the problem: 0. Get an email address. 1. apt-get install evolution 2. Receive lots of HTML spam 3. Install spamassassin 4. Become frustrated because you still see occasional HTML spam slip through 5. Write a patch which optionally disables HTML mail rendering. How often does this happen? Too often. Additional Information: Patch attached.
I don't see the patch here, but this would be pretty nifty. Marking NEEDINFO, adding RFE keyword, changing description.
Hm. My attempts to attach the patch in bugzilla have failed. Anyways, it's at: http://lists.ximian.com/archives/public/evolution-hackers/2002-April/004445.html
Created attachment 41204 [details] [review] patch for optionally disabling html rendering
Any progress on this one?
Created attachment 41297 [details] [review] patch for controlling HTML rendering, for evolution CVS
I just updated the patch to apply to the Evolution CVS, as requested.
Adding patch keyword
Hi. Please see also http://bugzilla.gnome.org/show_bug.cgi?id=219136 It is closely related to this, and could be solved after this one is ready. I really really hate to read my Spam -folder becaus there are lot's of mail opening LARGE text with nice COLORS. I'd rather read it in ASCII thank you. :) - Toni
Created attachment 41767 [details] [review] Ported to 1.2
There were just a couple of changes to make this patch apply to Evolution 1.2. Err, and I submitted a busted the patch on the first attempt, here's another one that actually compiles, and seems to be working for me.
Created attachment 41768 [details] [review] Revised patch for 1.2
From talking to Colin Walters on IRC, it appears that this latest patch is slightly broken, but beyond my ability to fix. It seems that both options should be "checked" (or "toggled," or "on," or whatever you want to call it) by default, but they are not.
From a bit of review of the available information (mostly this bug report and the related RFC), I think this bug could use a UI change. I think it would make sense to replace the "Prefer rendering mail in HTML format by default" checkbox with a set of radio buttons. I'm open for suggestions on the phrasing, but I think they ought to be something like "Prefer displaying mail as HTML", "Prefer displaying mail as Text", and "No preference". The last could also be "Use sender prefered format", but I can't figure out a really clear way to say that. I've added anna to the cc list in the hopes of some comments. Thanks
Hi guys. Greg, from a UI point of view, how would you have this option interact with the image loading options? Currently when I look in the HTML Mail tab of the "Mail Preferences" section of the Settings dialog, I see a frame filled with options designed to let me configure which (if any) images should be downloaded in html mails; it would seem that the rendering-as-html options you'd like to add need to take into account the presence of/language used in these options. Would you just have the "Loading Images" option be insensitive if "Prefer mail to be rendered as text" was selected? -Anna
I don't think that the "Loading Images" section would ever need to be insensitive, given the three options that I talk about[1]. They would still be relevant for messages where there was no "plain text" part, or for messages where one chose to view the HTML part. I attempted to use glade to do a mockup of my proposal, but I couldn't make heads nor tails of what to do with glade, so I gave up. [1]In the current patch, there is a checkbox for "Display HTML-only mail", which should make the "Loading Images" section insensitive. I'd just as soon that this option were removed entirely, since it doesn't make sense to have an option not to display some email messages.
*** bug 219136 has been marked as a duplicate of this bug. ***
*** bug 231754 has been marked as a duplicate of this bug. ***
*** bug 220666 has been marked as a duplicate of this bug. ***
Created attachment 43762 [details] [review] Updated to 1.4.6
your patch doesn't even compile besides, we aren't going to do this.
Jeff Stedfast wrote: > your patch doesn't even compile Sorry, this patch is against the debian source because the original source code of Evolution 1.4.6 does not seem to be available any more. All search result (and even the Help-->FAQ menu) are redirected to http://www.novell.com/products/evolution/ There is a link to a shell script that installs the binary and links for the developing version 2.0
Yes. Well. One should be implementing new features or functionality against CVS HEAD, not 1.4. If you want 1.4, there are original source tarballs available, on many ftp sites, as well as cvs and the mirrors for it.
Jeff, i can apply this patch against http://ftp.gnome.org/pub/gnome/sources/evolution/1.4/evolution-1.4.6.tar.gz without compilation errors. Can you give more details on the compilation problem?
you used c++ code which will not compile with a c89 compiler.