Re: KMime API review

Sune Vuorela <[email protected]> Wed, 4 Feb 2026 15:31:26 -0000 (UTC)
Newsgroups gmane.comp.kde.devel.pim
Organization pusling.com internet technologies
Message-ID <[email protected]>
On 2025-09-15, Albert Astals Cid <[email protected]> wrote:
> As requested during Akademy.

I have been toying a bit with the new API, and so far I at least have a
couple of questions:

Content/Message:

  template <typename T> T *header(CreatePolicy create = Create);

Who owns the header if it is just created? This might just be a
documentation issue
(and similar for other headers)

The overload is a bit confusing I_think:
     KMime::Headers::Subject *subject(CreatePolicy create = Create);
     [[nodiscard]] const KMime::Headers::Subject *subject() const

if `this` is const, the function takes one optional argument, else no
arguments.

We both have
parent/child ownership explicit Content(Content *parent = nullptr);
 and Content in unique_ptr's.

This also feels weird to me. I'm guessing it means there is two ways to
manage it.
It also isn't documented if parents manages lifetime of their children,
but I guess it is like that.


Types:
 At least KMime::Type::Address have a public QList member

Headers:
 I'm not sure we need a clone method for headers, but at least the code
 I'm working with is doing reparinting a lot.
 I ended up doing this:


 template <typename T> std::unique_ptr<KMime::Headers::Base> clone(T*
 header) requires std::is_base_of<KMime::Headers::Base, T>::value
 {
     auto copyHeader = KMime::Headers::createHeader(header->type());
     copyHeader->from7BitString(header->as7BitString());
     return copyHeader;
 }

I don't know if we want it anywhere.

I'm still not done doing my porting, but this is my first findings with
the new API.

/Sune