RE: tny-camel-mime-part.c needs some changes

[Philip Van Hoof <spam pvanhoof be>]

On Thu, 2006-12-07 at 12:10 +0200, Dirk-Jan Binnema nokia com wrote:

> Some background info on how we do this now in our project:

Okay. I looked it up and the defacto standard for this is to pick one of
the sub-mime parts of multipart message/alternative. Which one you pick
should depend on the capabilities of your view.

At this moment the TnyGtkMsgView already gets it right. It doesn't yet
get it right in case the message/alternative was in a recursive
message/rfc822 mime part somewhere.

I know why and I know how to fix this (the reimplementation of some
pieces of the tny-camel-mime-part.c will).

I strongly recommend inheriting TnyGtkMsgView and implementing
TnyMimePartView when implementing a custom message viewer set.

But oh well :)

> We actually use some simple code to find the appropriate body; the
> algorithm is basically to find the first non-attachment mime-part
> that is html (if you set the html_preferred flag) or txt
> (if you didn't set that flag, or couldn't find the html).

> Also note that we display *everything* as html; we convert
> text to html (turning URL-looking things into hyperlinks in the 
> process). Of course we could display text mails in a text view,
> but then it will be very painful to ensure selection, default font,
> zooming, ...., and other behaviour is exactly the same in these
> two views. Better to use only one :)

That, a TnyMimePartView can indeed implement itself. Just make sure that
your TnyMsgView's create_mime_part_view_for implementation returns your
special mime-part-view, and implement converting things in the
set_mime_part of the mime part view.



-- 
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
blog: http://pvanhoof.be/blog