Re: [Evolution-hackers] A better mail formatter

On Friday 01 of June 2012 17:29:59 Matthew Barnes wrote:
> On Fri, 2012-06-01 at 19:10 +0200, Dan Vratil wrote:
> > 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.
> That sounds freaking awesome!
> > The first big step is to move everything to libemformat. Why have
> > something
> > here and something there.
> I vaguely recall EMFormatHTML had some mail-specific dependency that
> kept it in the mail library, but maybe that's long since been solved.
> It totally makes sense to consolidate if that's indeed possible now.

Haven't found any :) 

Btw I forgot to mention that I also renamed EMailAttachmentBar to 
EAttachmentBar and moved it to widgest/misc as I haven't found any real reason 
for it to be in mail. It's a widget, it does not really have any mail 
dependency and all other EAttachment* components are in widgets/misc already.

> > 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.
> I'm literally crossing an item off my own To-Do list now.  Nice!


> > 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.
> That would be itip-formatter and prefer-plain, right?


> Nowadays I'm not sure the Preferences dialog should even be extensible
> at all.  It's too tempting to just tack on options willy-nilly without
> giving them sufficient thought.  If something's important enough to show
> up in the application preferences then it probably ought to live in the
> core application.  That's just my opinion.
> I'm inclined to suggest just add those plugin preferences directly.

I'm for it doing right with this patch. If we promote itip-formatter and 
prefer-plain to be core parts, we can get rid of the EPlugin hack there. The 
other ({audio,vcard}-inline and tnef-attachment) will still have to install 
the .eplug XML in order to appear in the plugins dialog though.

> BTW, my branch and your branch will probably collide in itip-formatter,
> but hopefully the conflicts are easy to resolve.

Yeah, but it looks like it's the only place we actually met. :) I'm rebasing 
the patch on top of your changes right now and so far it went quite well.

> > 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.
> > 
> >
> Neat!  Does the text-highlight have to be chosen each time or is it
> remembered somehow?

Milan was suggesting that Evo should remember the chosen formatter, and I 
remember I was against it, but I can't recall for what reason :) But it's a 
matter of discussion because as said in the blog, this feature is not yet 


> Matthew Barnes
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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]