The main idea is that the rendering process should not get access to KMime::Content and all calls to this are going via the MessagePart. That is leaks into the renderer is because of getting a fast working solution.
So the right way IMO is to move the getter into proctected and than every MP that needs to have it public mark the getter public or even provide these information the Render needs getFileName, contentDescription ...
But maybe this makes it more completcated than easier.
I know, that my aproch treats plugins autors to writer a propper MessagePart...

so i had in mind something like:

Kmime::Content <-> messagepart <->Renderer

and NO:

Kime:Content <-> Render calls

The problem with that is that we end up duplicating all kinds of KMime API without any gain. MessagePart makes sense for everything that needs decoding/decryption etc, and for changing the hierarchy, but IMHO not for verbatim forwarding of KMime data.
For my use-case (generic highlighting plugin) I need to have access to Content-* headers to check if it's something I want to handle or not.

In D8071#150843, @vkrause wrote:

The problem with that is that we end up duplicating all kinds of KMime API without any gain. MessagePart makes sense for everything that needs decoding/decryption etc, and for changing the hierarchy, but IMHO not for verbatim forwarding of KMime data.
For my use-case (generic highlighting plugin) I need to have access to Content-* headers to check if it's something I want to handle or not.

But this is exactly the usecase for an own MessagePart type. You process a mimetype and create SytaxHighlightMessagePart (SHMP) if you want to handle this part, the MessagePart has access to the KMime::Content and than you handle your specific MP and be happy and i think your SHMP only need the type of the KMime::Content.

My idea is that a plugin should early decide if it wants to handle a mimetype. And not that the process are done and than later on the render decide own we process the mimetype complety different

But that would tie processing and rendering always together to the same plugin, wouldn't it? In which case the entire exercise of splitting this up becomes kinda pointless, we could just render with the same plugin that managed to succeed in processing.

Also, look at it from the plugin developer POV: In this scenario I need to implement process() to decide if I want to deal with it (fair enough), implement my own sub-class of TextMessagePart or AttachmentMessagePart (without any extra data, everything I need is already there, so that's just busy work), fill it with the same logic that TextPlainBodyPartFormatter has presumably (that's highly error prone, that code deals with sign/encrypt state for example), and then I eventually get that passed to my render() method that actually does what my plugin wants to do.
As most plugins are purely dealing with rendering, I think this deserves a more convenient API. Ie. leave processing to things like crypto that actually manipulates the hierarchy, and to do things like determining what's the main body text etc, and allow rendering to work on top of that result.

In D8071#150859, @vkrause wrote:

But that would tie processing and rendering always together to the same plugin, wouldn't it? In which case the entire exercise of splitting this up becomes kinda pointless, we could just render with the same plugin that managed to succeed in processing.

I think in most cases they are connected yes: for vcard, WKS, calendar there is for sure things, that should be done in Processing and not at render step.

Also, look at it from the plugin developer POV: In this scenario I need to implement process() to decide if I want to deal with it (fair enough), implement my own sub-class of TextMessagePart or AttachmentMessagePart (without any extra data, everything I need is already there, so that's just busy work), fill it with the same logic that TextPlainBodyPartFormatter has presumably (that's highly error prone, that code deals with sign/encrypt state for example), and then I eventually get that passed to my render() method that actually does what my plugin wants to do.

well that is a valid point, the formatter need to get much easier! btw. the distintion between AttachmentMessagePart/textmessagepart is also something that really should be removed, the descition if what is an attachment should be done later in ther rendering step.

As most plugins are purely dealing with rendering, I think this deserves a more convenient API. Ie. leave processing to things like crypto that actually manipulates the hierarchy, and to do things like determining what's the main body text etc, and allow rendering to work on top of that result.

Okay we don't come to a good conclusion...

So be pramatic: So far we don't have that many plugins, and these need at least be updated to the recent interface. And this patch helps to do the work.

We can later still make the getter as deprecated and rework, if we have more clearer picture with the plugins...