Bug 459039

SUMMARY
This isn't necessarily a bug with Kwallet but rather a usability gripe with it about how it's designed as a whole.

Comparing Kwallet to the likes of KeePassXC, Kwallet's password management is less structured to maintained in the UI and has far fewer features than KeePassXC. Some will say: "then don't use Kwallet," but there's a few problems with this that I'm going to get into but my primary response to this is that I don't *mind* Kwallet as a concept but I find it greatly lacking and even frustrating in a few different ways.

One of these reasons is because of the aforementioned lack of features compared to KeePassXC: as it stands, KeePassXC is superior to Kwallet almost in every conceivable way. So much so, that I honestly think KDE should actually integrate KeePassXC better into Plasma and SystemSettings officially *instead* of Kwallet because of both how much better it manages data (from the user-end) and its other great features like: password generation, 2FA/OTP, and browser integration. As a user, I interact far more with KeePassXC as a password manager than with Kwallet and this brings us to my next point...

In my experience, Kwallet does a better job at requesting for authentication for desktop applications than KeePassXC; kwalletd5 is just better than the KeePassXC secrets integration and matches the system theme better; however, Kwallet has an irritating user flaw: if a user opts to save a credential but enters it incorrectly (to my recollection or something to that effect), fixing this becomes an unnecessarily frustrating task to fix. An example would be like using git@github SSH and then being stuck having to enter the key manually forever because Kwallet won't prompt for this anymore.

Another usability example would be when a matrix client asks to save encryption key data to Kwallet but Kwallet's only export options are XML and "encrypted;" which on its own isn't "bad," but when KeePassXC is so much more feature-complete than Kwallet, makes transferring this data either impossible or non-user friendly enough to seem that way thereby barring user-choice and unintentionally creating a "lock-in" if they discover KeePassXC later because Kwallet is the KDE community default.

That said, I think it would be better for the Plasma ecosystem as a whole to adopt a fork of KeePassXC to integrate with kwalletd5 to get the best of authentication requests, user data management, and user security in regards to supporting secure password generation, and 2FA/OTP.

Another option is to evolve Kwallet far beyond what it is in both UX/UI and usability but... honestly, that would be far more work than just implementing a rebranded KeePassXC fork because it functions and already feels like it belongs in a Plasma desktop; Kwallet seems almost ancient by comparison, in my opinion.


OBSERVED RESULT
Kwallet, despite being an official KDE password manager, falls short in how effective it should be.

EXPECTED RESULT
Kwallet should either officially integrate with a fork of a superior Qt offering or substantially adapt to achieving equal parity in design and functionality.

SOFTWARE/OS VERSIONS
Linux: Arch Linux x86_64
KDE Plasma Version: 5.25.5
KDE Frameworks Version: 5.98.0
Qt Version: 5.15.6

ADDITIONAL INFORMATION
N/A