-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127121/#review92589
-----------------------------------------------------------



Sorry for being the guy who says "I don't like this improvement because it's 
still not perfect"...
Why have a timeout at all and not, for example, retry after getting a timeout 
error? (A long timeout still makes sense to avoid most UI glitches)
I hope nobody uses the synchronous API in the UI thread, it would be a terrible 
idea to do that anyway. Is this for e.g. Akonadi agents? Those could as well 
wait indefinitely. If they can't -> well they shouldn't use synchronous API. 
Synchronous IPC to an unreliable peer (if the user is involved it's unreliable 
;) is asking for problems.

- Andreas Hartmetz


On Feb. 20, 2016, 2:16 p.m., David Faure wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127121/
> -----------------------------------------------------------
> 
> (Updated Feb. 20, 2016, 2:16 p.m.)
> 
> 
> Review request for KDE Frameworks and Valentin Rusu.
> 
> 
> Repository: kwallet
> 
> 
> Description
> -------
> 
> The default DBus timeout is 25 seconds, which means that if the user went to
> get a cup of tea during session startup, when they come back they get prompted
> with all sorts of additional non-kwallet password requests due to all kwallet
> requests having timed out.
> 
> I added setTimeout in QDBusAbstractInterface in Qt 4.8 for things like this.
> 
> Testcase:
>  eval `dbus-launch`
>  export SSH_ASKPASS=$KDEDIR/bin/ksshaskpass
>  ssh-add < /dev/null
> (but the same happens with the IMAP resource etc.)
> 
> 
> Diffs
> -----
> 
>   src/api/KWallet/kwallet.cpp b72edad19840943f70755c8668668a1881f1fb39 
> 
> Diff: https://git.reviewboard.kde.org/r/127121/diff/
> 
> 
> Testing
> -------
> 
> (see commit log)
> 
> 
> Thanks,
> 
> David Faure
> 
>

_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Reply via email to