[Kde-pim] asCleanHtml, and thoughts towards html replies to html emails
Thomas McGuire
mcguire at kde.org
Sun Sep 14 17:18:52 BST 2008
Hi,
On Saturday 13 September 2008 16:43:38 Stephen Kelly wrote:
> I've spent the last while working on a way to get clean html from
> KRichTextEdit.
Great work! I tried it out a bit and it seems to be already pretty solid.
Just a couple of comments (most of which I already said on IRC I think)
1) I don't think all those e-mail specific classes are necessary. For inline
images/attachments, we probably only need a MailBuilder which inherits
HTMLBuilder, and simply converts the image/attachment to a link. The quoting
stuff IMHO doesn't belong into the builder at all, currently quote handling is
done in keyPressEvent() in KMeditor, and highlighting with
KEMailQuotingHighlighter. Unless I missed something, that pretty much covers
quoting.
2) In the end, unit tests which verify that the produced HTML code is the
expected output would be nice.
3) An empty line produces two lines in the re-rendered box, one empty, and one
with a single space.
4) Are the "style="margin-top:0;margin-bottom:0" attributes in the p tags
really necessary?
5) Just out of interest: Why is changing the font size done by <span
style="font-size:16pt;"> instead of a plain <font size="16">?
6) Do we really need manual <u> and <span> tags for links? Isn't <a> enough?
> I've recently been reading Design Patterns[Gamma et al] and decided to make
> it also output plain text markup using the Builder pattern (I'm a kid with
> a hammer). Making it produce markdown should be easy, and should be
> something that kblogger should be able to use for blogs that accept
> markdown entries. I intend to put those classes in kdelibs, but not until
> they've had some maturity and use in kdepim (hopefully in KDE4.2), as I
> can't add any new virtuals to the AbstractMarkupBuilder once it's in, and I
> might have forgotten something.
As we said on IRC about the virtuals: Just add a virtual
beginSpecial/endSpecial with an enum as parameter, that can be extended easily
in the future (for example for tables)
> I've put the lot in playground here:
>
> http://websvn.kde.org/trunk/playground/pim/richtextbuilders/
>
> To try it out, just cmakekde in there to get a krichtexteditor with outputs
> in dock widgets when you push the update button. I looked at callgrind
> output for it, and as far as I can tell it's pretty fast, but I'm planning
> to design some incremental update system for it too, so the entire thing
> doesn't have to be updated all the time. I might also add some kind of
> MarkupDirector::registerBuilder() method and maintain a list of builders so
> that the doc only needs to be traversed once even for multiple output
> types.
Just for the record: For KMail, those incremental upgrades are not needed,
since we only build the document when sending/saving a message.
> Files for kdelibs:
> markupdirector -- instructs builders to construct markup
> abstractmarkupbuilder -- abstract class for all builders
> plaintextmarkupbuilder -- builds plain text markup
> htmlbuilder -- builds nice html markup
Nice and understandable class names. Seems like the Design Patterns book is
something I should read as well :)
> Files for kdepim (don't work at all. Mostly a braindump):
> emailmarkupdirector -- markupdirector with support for quotes,
> attachments etc
> abstractemailbuilder -- builder with support for quotes, etc
I don't get the point about the quotes, what are you trying to do here?
> richemailbuilder -- multiply inherited htmlbuilder (for
> html building implementation) and
> abstractemailbuilder. To be used to
> create html replies to html emails
Creating HTML replies to HTML mails is something that would likely need some
modifications in KMail (KMMessage::createReply(), the template parser and the
objecttreeparser). I don't see why this class would be needed.
> etc. emaildocument -- QTextDocument with overriden
> createObject for attachments (and maybe
> quotes - depends on how it eventually
> works).
> emaildocumentquotedata -- quote data associated with a textblock.
> Might be able to make quoting cleaner,
> and allow nepomuk queries like 'replies
> to me in a mailing list containing the
> word giraffe'
Hmm, I'm a bit skeptic about the need for all the e-mail specific classes
above, but I'll see how you can surprise me here :)
> One major issue I see with html replies to html emails is that non-kmail
> clients will send html that qtextedit doesn't know how to handle. That
> might take some work to manipulate foreign emails into a format usable to
> kmail.
Doesn't QTextEdit already deal with that, e.g. simply ignoring all the stuff
it doesn't understand?
> On the other hand, I think khtml and webkit now have editing capabilities,
> and might be usable instead of the pim stuff above. Does anyone know more
> about it?
I think KHTML is not really capable of it (or at least it is very difficult to
implement). I heard the Quanta VPL guys had some problems with it.
About webkit, I'm not sure. But I'm sure it would require an enormous amount
of work to make webkit as capable as QTextEdit/KTextEdit/KRichTextEdit already
is.
Thanks for your great effort.
Regards,
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20080914/7896d446/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/
More information about the kde-pim
mailing list