GNOME Bugzilla – Bug 58915
Mail composer should support HTML
Last modified: 2004-12-22 21:47:04 UTC
Actually, I'm not that interested in sending HTML as such, but I need to be able to reply to incoming ones - with the original text (not HTML code) quouted, and it would be nice to have some of the functionality typically found in HTML editors (such as bulleted lists, indentation etc.) even for normal text e-mails. I would suggest that an good HTML-to-text conversion routine, called when quouting HTML messages, is introduced as a first step on this.
Created attachment 908 [details] [review] Simple HTML-to-text converter
The attached patch will introduce an html-to-text conversion step during mime processing. It will be called when quoting messages for reply only, but I'm sure it would be easy to use the same logic when viewing messages if GtkHTML is not being used. The actual conversion code is just a hack I wrote right now. It doesn't do a lot of formatting, and writing it was probably a waste of time, as there must be a ready routine that may be used out there somewhere. Anyhow, at least we get rid of tags etc. with this, so it's better than nothing.
Marking the patch for 1.4 release (1.3 development series).
OK, I just couldn't resist it. I have now: 1. Added more functionaily to convert_html(). 2. Re-written preview code so that text version is also displayed when GtkHTML is not being used. The "View part..." and "Save part" buttons will still be visible in addition to the converted version - the text preview widget will simply be added to the box created in part_info_init_unknown(). This seems to work fine and I like the way it looks, but I haven't tested the code thoroughly. A new patch will be attached. Note that it is a replacement for the other one, rather than an addition. In other words, it simply shows the diffs from today's CVS tree.
Created attachment 923 [details] [review] HTML-to-text converter, take 2 + ascii preview of text/html
Oh. This patch also contains modifications to balsa-message.c described in bug 59305. Hopefully this doesn't cause too much confusion - only the part_info_init_mimetext() bits are relevant here (in addition to the changes to libbalsa/mime.[ch]), of course.
But really, all I wanted to to was ask: Do you have anything planned at all when it comes to _composing_ HTML messages?
Created attachment 924 [details] [review] Call external app, lynx by default, on HTML conversion
Here is yet another update - an external application will now be called when html-to-text conversion is necessary, but the custom function will be called as fall-back. This is more like a finalised version, except that configure update is necessary, and an alternative to system() should be found (refer to "FIXME:" in code.) This time the patch shows only the diff from the last version. Now, I should really stop playing around with this and start with whatever I'm supposed to be doing now...
Created attachment 7532 [details] [review] Updated patch - includes HTML send support
I just started playing around with this again. The result can be seen in the new patch attached. For the first time, there is crude support for HTML in outgoing messages. There is no real HTML editing facility, but the message body gets type "text/html" if that's what it looks like from gnome-vfs's point of view. (The main idea is to allow HTML code written via the external editor command to be sent as such.) Also, inline parts of HTML type is replaced with "multipart/alternative" containing HTML and plain-text variants of the text.
I've taken this one step further now. I've added options "HTML edit" and "Convert to plain" and also HTML preview to the compose window, as well as a HTML support in "reply/quote". When editing messages that look like HTML (according to gnome-vfs), the text entry window will be disabled. Instead, a GtkHTML view will be dispalyed (if GtkHTML support is enabled), along with buttons that allow the user to edit the message, or convert it to plain-text (and redisplay the text entry area.) When replying to HTML messages, the HTML part will be quoted if preference "Don't include HTML parts..." is not enabled, the plain-text variant or the HTML code converted to plain-text (for HTML-only messages) if it is. Messages that contain HTML code will be sent as "multipart/alternative" with "text/html" and "text/plain" parts as I explained earlier. To send "text/plain" only, you will have to select "convert to plain" before submitting the message. There is no way to send "text/html", as doing so is *bad*. I'll submit a new patch once I've cleaned up a few bits (may have to wait for a few days as I have other urgent work now.)
Created attachment 8506 [details] Screen-shot of compose window in HTML mode
I've now correctly isolated the HTML updates from my other changes (I hope) - patch attached below.
Created attachment 8616 [details] [review] Final (?) HTML patch
should we bend over backwards to support broken messages generated by crap webmail interfaces ? multipart messages are required to have a text part. stick with that, or stick it to the dumb sender i say :)