[Kde-pim] mulitpart/alternative & mixed libkmime question.

[Ingo Klöcker]

On Friday 16 February 2007 11:17, Volker Krause wrote:
> On Thursday, February 15, 2007 11:57:33 PM Ingo Klöcker wrote:
> > Both scenarios are awkward and obviously broken. IMO the right way
> > (which KMime doesn't seem to provide or else you'd use it) is:
> > Create Content A, fill it with plain content
> > Create Content B, fill it with html content
> > Create BodyPart::MultiPart::Alternative and add A and B
> > Create Content C, fill it with the attachment
> > Create BodyPart::MultiPart::Mixed and add the multipart/alternative
> > and C.
> >
> > Apparently, the complete subtree starting with BodyPart described
> > in CLASSTREE.bodyparts seems to be missing from KMime. :-(
>
> Indeed, nothing of this is actually implemented.
>
> From a quick look at the code, a small change to
> Content::addContent() should help: If it is of type mulitpart even
> without having sub-contents currently, it should not convert itself
> into a sub-content and create a new multipart node, but just skip to
> appending the sub-content.
>
> That should make it possible to get close to Ingo's scenario if you
> replace BodyPart::Mulitpart::... with Content and set its type
> accordingly.

Makes sense. But before changing it someone will have to check whether 
any code relies on the current behavior of addContent().

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20070216/e2d6ee80/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/