If this is acceptable I would not limit it to !LINUX; minimum dependencies may as well be desirable for those users.

What Frameworks do you have in mind? We did a bit of this for Android where DBus doesn't work at all, so I'm wondering what's left

I think at the moment KIO still needs dbus for some parts.
Or KXmlGui if I am not mistaken.

I will create a list with the frameworks that at the moment require it, then we can work on removing this requirements step by step.

Any update on that list? ;)

FTR: KIO is going to be difficult. IIRC the workers use dbus to talk to kiod which is the thingy that centrally handles and caches authentication on behalf of the workers. I struggle to imagine how we'd make that work without dbus.

kjobwidgets => kuiserver

kactivities & kactivities-stats => guess not that relevant, as not interesting for non-unices

kauth => inside backends, guess not relevant

kiconthemes => optional, seems fine for me

kcmutils => guess ok, as unices only

kpeople => atm off only on android, perhaps better optional instead

kglobalaccel => only interesting on X11

baloo => guess only used on unices

kdbusaddons => obvious ;=)

knotifications => already optional if I read this right

solid => in some backends

kio as said above. Thought, beside the auth stuff, kio works fine without dbus already on Win & macOS.

Perhaps I missed something

kpeople => atm off only on android, perhaps better optional instead

Seems sane.

kjobwidgets => kuiserver

I discussed this with @broulik and currently that is really deeply integrated in the classes. Defining more flexible interfaces could make sense, but that would be a phab task of its own.

solid => in some backends

Should be optional with https://phabricator.kde.org/D18389, but it has no CI integrated. And currently DBus is required for the windows build, here an explicit option could make sense .

kcmutils => guess ok, as unices only

That could make sense considering that there are plans to move the KCModule class there. Guess this will wait for the other task to be finalized.

kio as said above. Thought, beside the auth stuff, kio works fine without dbus already on Win & macOS.

So are you implying this needs no further work or should it be easily possible to opt-out the DBus stuff?

knotifications => already optional if I read this right

Yep, that was done in https://phabricator.kde.org/D17817

But I am generally not sure how we should do this consistently, should we have an explicit option like option(KCONFIG_USE_DBUS "Build components using Qt5DBus" ON) as in kconfig? And then we could choose a suitable default value for each platform.
Or should we have a unified option which gets reused in KF, same for the QT_DBUS_LIB or KCONFIG_USE_DBUS thing?

IMHO and as far as I have read this thread a CMake option is preferred over some if conditions for the platform.

knotifications => already optional if I read this right

Yep, that was done in https://phabricator.kde.org/D17817

But I am generally not sure how we should do this consistently, should we have an explicit option like option(KCONFIG_USE_DBUS "Build components using Qt5DBus" ON) as in kconfig? And then we could choose a suitable default value for each platform.
Or should we have a unified option which gets reused in KF, same for the QT_DBUS_LIB or KCONFIG_USE_DBUS thing?

IMHO and as far as I have read this thread a CMake option is preferred over some if conditions for the platform.

KNotifications on Linux doesn't make sense without DBus (since the freedesktop Notification spec is DBus-based) and on other Platforms DBus is not used at all, so an explicit option does not really make sense here

In T12083#248163, @sitter wrote:

FTR: KIO is going to be difficult. IIRC the workers use dbus to talk to kiod which is the thingy that centrally handles and caches authentication on behalf of the workers. I struggle to imagine how we'd make that work without dbus.

Convert KIO to use QKeychain for all auth stuff?

QtKeychain uses DBus to talk to KWallet etc, so that would merely move the problem

QtKeychain uses DBus to talk to KWallet etc, so that would merely move the problem

I don't think so.

QtKeychain will use the native stuff on Windows, macOS and Android, avoiding there any dbus, that it uses it on Linux/BSD/... is ok.

The current solution will just not work at all on Windows and macOS in contrast.

In T12083#253825, @cullmann wrote:

QtKeychain uses DBus to talk to KWallet etc, so that would merely move the problem

I don't think so.

QtKeychain will use the native stuff on Windows, macOS and Android, avoiding there any dbus, that it uses it on Linux/BSD/... is ok.

The current solution will just not work at all on Windows and macOS in contrast.

True, my statement was missing a "on Linux". I was a bit distracted by the do-we-need-an-option-on-Linux discussion.

Using QtKeychain instead of KWallet directly is something that is pretty much agreed on anyway

Ok, yeah, you are right that on Linux/BSD/... making DBus optional is a non-goal, I agree.
One can assume it will be usable there.
It is just a pain on other operating systems.

Looking closer at the kpasswdserver stuff it's not as simple as swapping out KWallet for QtKeychain. kpasswdserver is an intermediate between the worker and KWallet. It seems to cache stuff and allows to make storing the credentials in KWallet optional. Using QtKeychain directly is probably possible but would be a larger rework.

Clarification: Swapping out KWallet for QtKeychain is somewhat easily doable and matches our plans, but that won't solve the issue of Worker <-> kpasswdserver communication

In your opinion is the kpasswdserver layer necessary? What extra features (if any) does it provide compared to stuffing Auth into KWallet?

If not then it might be a good idea to get rid of this layer and then switching to QKeychain allows us to drop DBus dependencies on MacOS/Windows.

then switching to QKeychain allows us to drop DBus dependencies on MacOS/Windows.

I think @dfaure already agreed to this goal in T14316. Not sure about the first part :)

I think @dfaure already agreed to this goal in T14316. Not sure about the first part :)

I assume he meant replacing the KWallet usage, not the whole kpasswdserver

In your opinion is the kpasswdserver layer necessary?

Short answer: I'm not sure, but it's certainly not trivial to remove

What extra features (if any) does it provide compared to stuffing Auth into KWallet?
If not then it might be a good idea to get rid of this layer and then switching to QKeychain allows us to drop DBus dependencies on MacOS/Windows.

One thing that it allows is keeping auth data for the current operation/session only without writing them to the wallet.

Storing them in a separate process makes some sense given that worker lifetime != app lifetime != session lifetime. However with T12214 our assumptions may change

Also kpasswdserver is not only used by KIO, it is also used by: samba-mounter, print-manager, konqueror and khtml. That does not necessarily prevent us from not using it in KIO though

Assuming we want to keep the option to not have passwords persistently stored (which I think we rather do - there are uses for it when e.g. using a system that isn't yours) then we need kpasswdserver just as much with T12214 maybe even more. Otherwise you'd have dolphin ask to authenticate on smb://foo, you click on a photo, now gwenview wants you to authenticate smb://foo/photo.jpg again, inside gwenview you decide to draw on the photo and open with->kolourpaint, now kolourpaint also wants you to authenticate smb://foo/photo.jpg. I don't see that use case going away.

Another bit is request serialization - which I'm not sure we can do with QtKeychain alone? e.g. if you login and session restore runs and you had dolphin open on smb://foo and gwenview open on smb://foo/photo.jpg, then you only get a single auth request window, the second will be met with the cached result of the first.