Entering a password in the settings dialog no longer seems to have any effect, after confirming the settings dialog and then doing a mail check I'm asked for the password again.
The resource incorrectly set a flag to prompt the user again after the configure dialog was closed. This is easily fixed, however, it reveals another bug. Opening of the wallet fails, because the WId returned by winIdForDialogs() isn't accepted by KWallet: KWallet::Wallet::openWallet: Pass a valid window to KWallet::Wallet::openWallet(). The result is the user is prompted for the password again! Not sure whats going on here.
SVN commit 1148685 by link: Don't set the "Ask Again" flag to true after a the config dialog is closed. If the user did indeed change the password, it will be loaded from the wallet. This reveals another bug, namely that the WId returned by winIdForDialogs() isn't accepted by KWallet. See bug. CCBUG: 243922 M +0 -1 pop3resource.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1148685
From IRC today: <tokoe> casey: hmm, the winIdForDialogs() might change when some application is opened/closed... have to check that... <tokoe> casey: ahh, it takes the winid from the systemtrayicon, which i haven't running... <casey> tokoe: hm neither do i <tokoe> volker: do we require to have the akonadisystray running? <volker> I don't think so <tokoe> volker: if not, wallet integration seems to be kind of a problem, since we have no window id that kwallte can remeber to not ask the user over and over again Summary: WId comes from systray icon, and thus is invalid if the icon is not running. Thoughts?
Discussed this with Volker today, we think we should separate the two concerns here. 1) there should be an akonadi wide ID that is used for the wallet identification, independent of GUI processes. 2) every gui process that calls "needsWorkingAkonadi" should add its pid to a list of available window parents, and then the top most of those (or some other heuristic) should be used when a resource needs to raise a wallet dialog. There's already API in resourcebase to find out a win id to use as a parent.
The original bug here has been fixed (it works for me now), so closing this bug report. Not sure what the issue about window IDs is about, but that should be a separate Akonadi-wide bug report.