Implementation detail: the patch introduces a d pointer to a private subclass,

Why is this needed? IIUC, the private subclass pattern is only useful for hiding private members from public API/ABI. However, in this case, the whole class is basically private (nothing else should be accessing the members either directly or indirectly) so I don't think this is necessary.

In this case it's really an implementation detail, meant to unburden the main class which is becoming unwieldy, and make more isolated changes that don't require rebuilding the majority of the plugin each time you make a small change. Ultimately I think it's a princple that allows cleaner coding, not just by hiding things from public API but also by exposing internal things only where they're needed.

So is it needed, no. Is it useful, yes, I think so, though of course the current change is too small to have a real impact. I'm working on an unrelated follow-up that will give this private class a bit more justification.

Maybe we could change the subclass name, and the pointer to it?

In this case it's really an implementation detail, meant to unburden the main class which is becoming unwieldy, and make more isolated changes that don't require rebuilding the majority of the plugin each time you make a small change.

Putting everything in a different class will not help.

Ultimately I think it's a princple that allows cleaner coding, not just by hiding things from public API but also by exposing internal things only where they're needed.

I disagree. Basically everything in here is internal so following that will basically make the original class a thin wrapper and put all code in a real class.

If there's a group of field/functions that are closely coupled and not to anything else, those can certainly be put in a separate file/class and be a field of the main class. Such fields should also be grouped by the function they provide and have a corresponding name and should be created very conservatively, much more conservatively than adding a private pointer for other classes since there isn't a strong reason to do so (like hiding implementation details from public API/ABI).

So is it needed, no. Is it useful, yes, I think so, though of course the current change is too small to have a real impact. I'm working on an unrelated follow-up that will give this private class a bit more justification.

Given what I said above, is the current form harmful, no. Will putting more things in there be harmful, yes. That's because there's no methods (apart from a few override methods that are the public API) and no fields that are not "private" so adding a private pointer to a private object is strictly confusing.

Maybe we could change the subclass name, and the pointer to it?

As I said above, separate according to function is fine, so it would be fine if it is done on a group of fields/functions that are very self-contained.
It will be a trade-off between making it easier to find things closely related (i.e. the code that are separated out) and making it harder to find the caller/callee or find this code from caller/callee.

This is a qt bug that I can't reproduce and the change looks safe so LGTM....

This is a qt bug that I can't reproduce and the change looks safe so LGTM....

Yes, it addresses an issue that occurs only very sporadically. If memory serves me well the situation where orphaned style instances remain after unloading the plugin occurred a bit more often but usually didn't lead to issues. Or they didn't until we introduced the access to the plugin instance from style instances, I don't recall. Either way, I have been testing this long enough to forget the details, clearly.

I've reduced the footprint a bit. There's no point for the DBusHelper class to have its own header file since it'll only ever be used from the main style module.