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