I've worked some more on this bug with KWallet.
It turned out finally that the cause of the bug is that somehow D-Bus
service of KWallet API library call is unregistered during this call
and kwalletd considers it as the application died while user is
entering the master password for wallet (there's special processing in
kwalletd for this case). What's more, it turns out that this call's
service is somehow exactly this: "org.kde.Akonadi.Firstrun.lock".
To be more exact, the method KWalletD::slotServiceOwnerChanged is
called in kwalletd even before the password is entered (here's my
debug message):
kwalletd(30399) KWalletD::slotServiceOwnerChanged: name, oldOwner,
newOwner: "org.kde.Akonadi.Firstrun.lock" ":1.21" ""
I looked at the code some more and found that the 'service' of the
(async) call (i.e. ":1.21") is taken from QDBusMessage.service(); in
KWalletD::openAsync method.
Does someone know how such an aliasing could ever take place and what
could lead to such a situation? I think it's quite significant problem
as I guess it works like this for _every_ d-bus call from plasmoids.
2011/8/25 Alexey Chernov <4er...@gmail.com>:
> On 24 авг 2011 22:40:20 Valentin Rusu wrote:
>> On 08/24/2011 09:30 PM, 4ernov wrote:
>> >>> Sorry for unclear text, yes, I meant KWallet API, you're right.
>> >>> Here's
>> >>> those method itself:
>> >>>
>> >>> bool MicroBlog::enterWalletFolder(const QString &folder)
>> >>> {
>> >>>
>> >>> //TODO: seems a bit silly to have a function just for this
>> >>> here
>> >>> //why doesn't kwallet have this itself?
>> >>
>> >> What's this TODO exactly meaning? Check for setFolder? I don't get it
>> >> :-)>
>> > I actually don't know) It's not my code, I just wanted to fix it, so
>> > it's "as is" :-)
>>
>> Ok, NP.
>>
>> >> Use KWallet::isEnabled() as it calls the daemon to check for that and
>> >> it
>> >> eventually starts the daemon if it's not already started.
>> >> But you must have the Wallet system enabled system-wide, in System
>> >> Settings, for this to happen.
>> >
>> > Thank you for advice. And should I wait for it to return true or it
>> > returns true after the daemon is started?
>>
>> It's a synchronous call, so when you get the "true" result, the daemon
>> is already running.
>
> Just test it. Both isEnabled() and openWallet() return true, but the behavior
> is just the same.
>
> I've got a thought: could it be because the "Open Wallet" dialog is already
> shown by the same app's call (as to this dialog text, all the plasmoids are
> treated as "Plasma Shell")?
>
> To be exact, the behavior is like this:
> 1. I start KDE.
>
> 2. Few seconds later the dialog from KWalletManager appears to make me enter
> master password. The application mentioned there is "Plasma Shell" (sorry if
> incorrect, I've got localized version). The Microblog plasmoid behaves itself
> as always: it's empty and no account is logged in.
>
> 3. I enter master password. The plasmoid is still the same. KWalletd is
> running this time (as of 'pidof kwalletd').
>
> 4. I push Enter and right here the plasmoid fallbacks to the place of code
> mentioned above and make me enter login and password once again. If I enter,
> everything works correctly until the next KDE login.
>
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
