previous discussion was done accidently inside kube phab: https://git.kolab.org/D196

No we also have TextPart "just" representing a QByteArray. To make GPGInline workable. And other structural elements like EncryptionPart and SignaturePart.

So we have different types of Parts:
StructuralParts: SignaturePart, EncryptionPart, MainContentPart
ContentParts: MimePart, AttachmentPart, TextPart

None of this new parts should exist in the interface.

void pointer - no way with that we really make the software not safer in terms of BIC and API breakage :D Because now nobody knows, that is inside this void pointer.

It does help for the interface.
It's then up to the user to deal with whatever is extracted from the void pointer.

If you assume that the void pointer always returns the same structure and that every user of the library will have to access that anyways, then this design isn't very useful of course.
But if we don't need to access it in the majority of cases and you simply want to make the it still possible for some future usecases, then this is a viable way to go.

The point of the void pointer is of course as well that it is a generic handle to whatever underlying datastructure, should we i.e. not use gpgme for some reason.

can something like this help:

class gpgmestructure;

class Signature {
  public:
     str::shared_ptr<gpgmestructure> getGPGmepointer();
}

and in private header:

class gpgmestructure
{
  public:
    GpgMe::Signature signature();
}

this way we make public interface free of use of GpgMe and make it obvious to use the private headers with risk?

I suppose this would be possible, although I don't know if it would really solve all BIC problems (but it seems to me like it)

If we have the risk of BIC/API breakage, than we need to add complete interface for the GpgMe structures.

This means:

class Singature

class GPGSignature : public Signaute

and anytime in future maybe:

class PEPSignature : public Signature

Which would break BC anyways so you could just as well return GPGSignature, unless you want to extend it somehow.

If you think GPGSignature is the right interface for clients to get to all they need to know for the signature then use that. Should we figure out that we need something different after all then we'll just break BIC and release version 2.

I suppose this would be possible, although I don't know if it would really solve all BIC problems (but it seems to me like it)

well no it doesn't reslove the BIC problems, because also if GpgME breaks BIC, the cleitn software needs to be recompiled. But without void pointers it should be more clear, that there is this connection.

Singature/GPGSignature/PEPSignature

Which would break BC anyways so you could just as well return GPGSignature, unless you want to extend it somehow.
If you think GPGSignature is the right interface for clients to get to all they need to know for the signature then use that. Should we figure out that we need something different after all then we'll just break BIC and release version 2.

No this won't break BIC, because the existing classes aren't touched. So an existing client can still interact with mimetreeparser.All methods defined in Signature baseclass are still working and also the special GPGSignature routines works like before. We only break BIC if we touch the Signature class and remove methods and or change existing method headers.