Maybe too radical, but since KWallet will no longer be a direct dependency of clients, can KeePassXC instead be used as the platform implementation?

In T12219#210789, @IlyaBizyaev wrote:

Maybe too radical, but since KWallet will no longer be a direct dependency of clients, can KeePassXC instead be used as the platform implementation?

I've been thinking about that as well (I would love to use such a mode). But that's more a "nice for later" thing, it's not blocking a KF6 existence (can be done during KF5 lifetime even) so can be done whenever if QtKeyChain joins KF.

can KeePassXC instead be used as the platform implementation?

If QKeyChain gains a backend then sure, everything will "just work".

I'm not sure we can depend on it (especially given this project seems to have a trillion forks) for our default implementation.

Talked to Frank, he's not opposed to this, but would like to know how much would need to change in the API for this first.
I guess the next step is doing a closer review of it then.

AFAICT it looks mostly fine to me API wise. It has its own job class, but I'm not sure it'd be worth porting to KJob to be honest so it could likely stay like this. Other than that changes would be mostly about coding styles and aligning the organization of the files and build system with other frameworks.

In T12219#213565, @ervin wrote:

AFAICT it looks mostly fine to me API wise. It has its own job class, but I'm not sure it'd be worth porting to KJob to be honest so it could likely stay like this. Other than that changes would be mostly about coding styles and aligning the organization of the files and build system with other frameworks.

Changing to KJob would be a problem for Frank's use-cases I think, and it would make this a tier2 framework, so I'd agree it makes sense to keep that as-is. What about the name, can we keep that as well?

You mean keeping it named QKeyChain?

I don't think this is a problem. Might look a bit odd on the new library naming because of the libKF5 prefix but I don't see that as a blocker.

Q* always sounds like something is provided by Qt.

OTOH if the renaming is blocker for getting it as a framework, we can keep the name ;)

"KeyChain" already has the "K" prefix ;) so Let's just drop the Q

Hi!

I'm not opposed to make QtKeychain a KDE framework. I'm lacking time these days to properly maintain it, especially when it comes to testing changes and decisions that require an overview of what is used where on which Linux distribution. One thing to consider is always the compatibility at runtime on older distros, with obscure desktop environments, etc. I just lack the overview of what is used in which Ubuntu, Fedora, CentOS or whatnot and what is still worth supporting. (Gnome keyring vs. libsecret, etc.). So any help here is welcome :)

As for the API and implementation: I chose an async API mainly to avoid issues when hiding async (DBus) implementation behind a synchronous API. So I would keep it that way, although the implementation of other platforms is usually synchronous.

I would like to keep the lib free of any other KDE dependencies (like KJob), as one major use case is to add it as a "code snippet" to any Qt project, often using QMake. That's much easier if there's no additional dependencies.

As for the name, please note that its "Keychain", not "KeyChain" :)

Regarding naming, one thing to consider is compatibility with existing code. For that it might be worth keeping the names (and possibly even ABI) as-is for the KF5 series and adjust for KF6 only, when user code needs to be ported anyway. This does affect other about to be incubated frameworks too, see eg. Grantlee.