https://community.kde.org/Policies/Kdelibs_Coding_Style#Qt_Includes

I think you could do something like this in the header file

class ...  {
...
    m_stateToolTip = true;
    m_stateVisualFeedback = true;
    m_stateSingleClick = true;
...
};

I would remove it. It doesn't add any useful information. I don't see any word about commets in the kdelibs coding style(I assume Plasma follows it) but as a rule of thumb: comment things that are not obvious.

For example, see https://google.github.io/styleguide/cppguide.html#Implementation_Comments

This one is more clear imho because they are not optional initializations, they are must so we emphasize that.

Actually this is optional. Not a big issue. Makes it easier to follow. Specifically for this patch, it's okay imho.

Why all the asterisks?

The inline comments are no longer needed now that the variable name is self-documenting.

We want to batch our syncs to plasmarc, which the old code did better.

I wouldn't bother trying to be clever with checking if it's the original state or not here, as KConfig will do all of that for us anyway at a more correct lower level.

For the sync yes.

For checking state: the old code wrote always all values to the config file, with or without the user changing them at all. It might make sense to only write config values which have been explicitly changed by the user, because this would mean that we can later on change the default of values of this user which have never been explicitly changed by the user before with an update of just the KCM code.

Nice point. I tested the situation for the old code. When I just change single/double click option, other option files (plasmarc) are not opened. That means KConfig handles the situation. Thank you. Correction will be done now.