Yeah, i consider it the better option.
Depending on kcm_pulseaudio which comes with plasma-pa is rather moot as plasma-pa disables kmix.

I see. Then i'll let $things happen. Thanks!

Cool thanks!

Ah, that seems a lot better yes, thanks.

Refactor show functions to be members of VolumeOsd

Yeah, was unsure too if it's a good idea but now with your sanitized wording i'd prefer it that way :)
But if i should go for a single OSD on/off i wouldn't mind either.

now with spacing

Add spacing

Change wording

"default output"
"Default output"
"Default output device" ?

Oh.. good catch thanks :)

Fix typo

Not sure about the actual wording and whether we would want all 3 of them.
Probably would use "input volume", "output volume" but i tried to match the existing "aural feedback" string.

If phononsettings is missing/uncallable the message box inf KMixWindow::forkExec is shown providing at least some feedback.
For the kcmshell5 call, KProcess::startDetached is able to start the process - but that fails internally. I don't see a way to fix that in this 'fire and forget' style besides validating kcm_pulseaudio is available.

I'm aware that the proposed change is still far from optimal as the error handling doesn't work for missing kcm modules and still may result in silent errors for the user.
If you think rewriting that to verify the kcm actual exists is the way to go, please say so. I was reluctant to add the KF5Service dependency to enumerate kcms (at least i see kcmshell uses that).