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!
\o/
>
> > 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?
Exactly.
>
> 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.
> >
> > http://www.progdan.cz/2012/06/evolution-gets-a-new-e-mail-formatter/
>
> 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
done.
Dan
>
>
> Matthew Barnes
--
dvratil redhat com | Evolution developer
GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348Attachment:
signature.asc
Description: This is a digitally signed message part.