I occasionally encounter the problem that GTK windows don't get the focus, i.e. they do not become the active window. Specifically the window of Goldendict for which I have a shortcut to translate words open in front, but I still have to navigate there and to click it in order to enter the word. I tried various settings such as focus stealing prevention ...
Thanks for your ideas!

Could be https://bugs.kde.org/show_bug.cgi?id=347153

=> Can you please dump the output of "xprop" for the relevant window?

Not sure that it is this bug. I don't have these conditions. I am using kubuntu packages, not this application and do not need to switch desktops.
Also the problem is not new. I had it already with kde4.

I tried your command:
xprop -name GoldenDict
gives

_KDE_NET_WM_FRAME_STRUT(CARDINAL) = 6, 6, 33, 6
_NET_FRAME_EXTENTS(CARDINAL) = 6, 6, 33, 6
_NET_WM_DESKTOP(CARDINAL) = 0
WM_STATE(WM_STATE):
window state: Normal
icon window: 0x0
_NET_WM_STATE(ATOM) = _NET_WM_STATE_ABOVE, _NET_WM_STATE_STAYS_ON_TOP
_NET_WM_ICON_GEOMETRY(CARDINAL) = 297, 867, 219, 29
_NET_WM_USER_TIME(CARDINAL) = 0
_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE
_KDE_NET_WM_ACTIVITIES(STRING) = "e00dc9ac-f5a4-4d57-985a-94f18c468690"
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 119537703
_NET_WM_ICON(CARDINAL) =
XdndAware(ATOM) = BITMAP
_MOTIF_DRAG_RECEIVER_INFO(_MOTIF_DRAG_RECEIVER_INFO) = 0x6c, 0x0, 0x5, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, 0x0, 0x0
_NET_WM_NAME(UTF8_STRING) = "GoldenDict"
WM_CLIENT_LEADER(WINDOW): window id # 0x7200008
_NET_WM_PID(CARDINAL) = 1769
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x3, 0x3e, 0x7e, 0x0, 0x0
WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_NAME(STRING) = "GoldenDict"
WM_LOCALE_NAME(STRING) = "en_US.UTF-8"
WM_CLASS(STRING) = "goldendict", "Goldendict"
WM_HINTS(WM_HINTS):
Client accepts input or input focus: True
Initial state is Normal State.
bitmap id # to use for icon: 0x7200025
window id # of group leader: 0x7200008
WM_NORMAL_HINTS(WM_SIZE_HINTS):
user specified location: 935, 286
program specified location: 935, 286
user specified size: 653 by 538
program specified size: 653 by 538
program specified minimum size: 594 by 293
window gravity: NorthWest
WM_CLIENT_MACHINE(STRING) = "einstein"
WM_COMMAND(STRING) = { "/usr/bin/goldendict" }

No, not that bug - the client supports, but doesn't rely on the WM_TAKE_FOCUS protocol.

Does is work as expected if you lower the global FSP to "None" in "kcmshell5 kwinoptions"?

Yes, indeed! As I removed the window specific settings for that application and set the global focus stealing prevention to none it started to work. It seems that it helps also for KGgpg where, as I remembered now, I had the same problem.
I never completely understood the focus stealing prevention. I assumed that I should choose it high if I encounter this sort of problem ...

no. "high" makes it harder for the window to get the focus.
revert the global value to "low" and create a rule with "none" - if the client doesn't illegally change its class after mapping (my actual concern), that should do fine.

the spec-compliant fsp would be "none", but that allows random clients to obtain the input focus whenever it pleases them, so the default is "low".
your kgpg issue is likely esp. a non-risen window, i've a patch for that since years. kf5 port: https://git.reviewboard.kde.org/r/124130/

Excellent, thanks!