It's probably being created by an app using QT4 and KDElibs that hasn't been ported to KDE Frameworks 5 yet. Are you using any such apps? One example would be Amarok.

(In reply to Nate Graham from comment #1)
> It's probably being created by an app using QT4 and KDElibs that hasn't been
> ported to KDE Frameworks 5 yet. Are you using any such apps? One example
> would be Amarok.
No I am not. Qt4 and any application depending on it have been purged for a while already from the Gentoo repositories. The closest I have is kdelibs4support:

$ eix kdelibs
[I] kde-frameworks/kdelibs4support
     Available versions:  (5) 5.54.0(5/5.54)^t ~5.56.0(5/5.56)^t **9999(5/9999)^t[1]
       {X debug +handbook libressl test}
     Installed versions:  5.54.0(5/5.54)^t(22:33:27 06-02-19)(X -debug -libressl -test)
     Homepage:            https://kde.org/
     Description:         Framework easing the development transition from KDELibs 4 to KF 5

[1] "kde" /var/lib/layman/kde
$ equery d kdelibs4support
 * These packages depend on kdelibs4support:
dev-vcs/subversion-1.10.4 (kwallet ? kde-frameworks/kdelibs4support:5)
kde-apps/kdepim-runtime-18.12.3 (>=kde-frameworks/kdelibs4support-5.54.0:5)
kde-apps/kolourpaint-18.12.3 (>=kde-frameworks/kdelibs4support-5.54.0:5)
kde-misc/zanshin-0.5.0 (>=kde-frameworks/kdelibs4support-5.54.0:5)
kde-plasma/khotkeys-5.14.5 (>=kde-frameworks/kdelibs4support-5.52.0:5[X])
kde-plasma/kmenuedit-5.14.5 (>=kde-frameworks/kdelibs4support-5.52.0:5)
kde-plasma/plasma-desktop-5.14.5.1 (>=kde-frameworks/kdelibs4support-5.54.0:5)
kde-plasma/plasma-workspace-5.14.5.1 (>=kde-frameworks/kdelibs4support-5.54.0:5)

I'm curious: unless you have some Qt4 application still: do you still have the .kde4 directory?

it's probably kdelibs4support that's the culprit.

No, this is done by Plasma itself in a few places, eg.

https://cgit.kde.org/plasma-desktop.git/tree/kcms/mouse/backends/x11/evdev_settings.cpp#n132

https://cgit.kde.org/plasma-desktop.git/tree/kcms/workspaceoptions/workspaceoptions.cpp#n211

Darn, that's disappointing. :/

>it's probably kdelibs4support that's the culprit.

It's krdb in plasma-desktop/kcms (then run on startup indirectly via kcminit)

We sync settings, fonts/style etc to where kde4 loads them from.

We can't know if you have (or are going to have) a KDE4 app installed.

It's fairly harmless, there's no kde4 deps needed, it's just some config files.

(In reply to David Edmundson from comment #6)
> It's fairly harmless, there's no kde4 deps needed, it's just some config
> files.
Is there any way to get these under .config instead of under ~?

Not really

(In reply to David Edmundson from comment #8)
> Not really
Would you consider changing this bug to a feature request for compile-time or runtime functionality that would allow this?

Why?

(In reply to David Edmundson from comment #10)
> Why?
To avoid clutter in my home directory. Dotfiles/Dotdirs are useful, but if every application just keeps on dumping their stuff there, it's a pain to browse. (Also, some applications like Firefox don't filter out dotfiles in its file save dialog.) The XDG Base Directory Specification that AFAIK KDE as a project intends to support is 7 or more years old and Qt4/KDE4 have been deprecated for 4(?) years now.

I guess that at some point this writing out of .kde4/... will cease. I assume that this will be done with deprecation first, where the functionality is still available if explicitly compiled-in or configured, before final removal. So implementing my feature request is essentially preparing for that already.

"clutter" is not a compelling reason, so no I would not accept such a patch.

As for firefox. Right click -> show hidden files.

(In reply to David Edmundson from comment #10)
> Why?

To complete proper support of XDG base directory spec. I'd prefer to avoid all such clutter, and $HOME/.kde is one of the remaining offenders.

For instance Debian now removed kde4libs altogether. Going forward probably all of such cases will be gone. But if you want to still keep it for legacy purposes, at least it would be useful to be able to turn it off, either at compile time (then distros can do it), or as a runtime config key, then users can turn it off on demand.

For XDG support you can see the specification itself: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

In fact, KDE project is behind it too, so it's a bit surprising that still needs reasoning.

For what it's worth, looks like $HOME/.kde isn't being created anymore (even with current plasma before Qt 6 usage). Hooray!