Bug 257339

Summary:	No need to insert username and password even if I disable KWallet
Product:	[Frameworks and Libraries] Akonadi	Reporter:	Simone Pinton <simone.pinton>
Component:	GoogleData Resource	Assignee:	Adenilson Cavalcanti <savagobr>
Status:	RESOLVED INTENTIONAL
Severity:	wishlist	CC:	dvratil, kdepim-bugs, korossy, vkrause
Priority:	NOR
Version:	4.5
Target Milestone:	---
Platform:	Ubuntu
OS:	Linux
Latest Commit:		Version Fixed In:

Description Simone Pinton 2010-11-19 17:39:57 UTC

Version:           4.5 (using KDE 4.5.3) 
OS:                Linux

If you disable KWallet, every time you start a new KDE session a dialog window appears asking username and password of your Google account.
The dialog could ask the user to save this data. They could be saved in a configuration file. Obviously this is not a secure solution, because everyone can read your password from the config file, but is surely more convenient than rewrite username and password each time (and for some aspects more secure, because it's easier than someone read your password when you're writing it).
Personally I use this solution also with gmail-plasmoid, which remembers username and password in its configuration file (unfortunately in plain text).

Reproducible: Always

Comment 1 Pal Körössy 2011-10-06 10:26:24 UTC

I second this. The option (storing login information in config file instead of KWallet) has already been implemented in KMail 1.x but is still missing from KDE 4.7.2 (konadi with Kmail 2.x). 
I prefer starting KMail without asking Kwallet-password everytime I log in to the KDE. On the other hand I use more different wallets for different purposes and I have to store every passwords in each Wallets which is very uncomfortable.

Comment 2 Daniel Vrátil 2018-08-27 22:15:34 UTC

Although undoubtedly KWallet has many shortcomings, it is the only viable password storage solution we have and we do not really support the no-kwallet usecase at this point (as that would mean implementing kwallet fallbacks everywhere in PIM).

We may choose to implement this at some point if an alternative password storage appears that we will want to support.