----------------------------------------------------------- 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