On Friday 01 of June 2012 19:10:05 Dan Vratil wrote: > Hi, > > I've spent last few weeks re-working the email formatter and I think it's > finally ready for landing to master. Milan will review it on Monday or so > and if it's OK, I'll commit it early next week. Hi, I just committed the new formatter to git master. If you find any issue or major divergence from the behavior of 3.4 formatter, please open a bug in. Please tag the bugs with "evolution[formatter]" so that it's easier for me to track the issues. I'll be now working on the bugs with which I've been waiting for this new formatter and of course fixing anything new that appears. Dan > > I have already reworked it for the WebKit port, but the result was not good. > There was only one class (EMFormat*) which was doing two completely > separate actions - parsing and formatting and everything was stuffed in > just a few .c files, making the code quite a mess. > > I have realized that the formatter could be made much more flexible and > nicer by making proper object-oriented design. With Milan we have came up > with quite a nice design. > > The first big step is to move everything to libemformat. Why have something > here and something there. > > The parser and formatter were separated to their own classes EMailParser and > EMailFormatter and the _actual_ parsing/formatting is done by extensions. > Essentially there is a class for each mime type we support and they are > derived from EExtension. > > This splitting makes the code much easier to read, navigate in and keep it > in shape. > > As part of the work, I converted some plugins, namely audio-inline, itip- > formatter, prefer-plain, tnef-attachment and vcard-inline, to modules. There > is no API yet to extend the preferences dialog though, so for this some of > them still install a little EPlugin-based library with the GUI. The main > improvement here is that they react to changes in settings immediately, no > need to restart Evo, some of them even cause the current view to refresh > immediately. When a proper API for this is in place we can make on-demand > loading etc. > > And why we have done this all? Because of text-highlight module. I've > written less technical blog about it, so see for yourself what we already > have and what I plan for near future. > > http://www.progdan.cz/2012/06/evolution-gets-a-new-e-mail-formatter/ > > Bye > > Dan > > > > dvratil redhat com | Evolution developer > GPG Key: 0xC59D614F6F4AE348 > Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348 -- dvratil redhat com | Evolution developer GPG Key: 0xC59D614F6F4AE348 Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348
Attachment:
signature.asc
Description: This is a digitally signed message part.