<table><tr><td style="">ahmadsamir added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D28880">View Revision</a></tr></table><br /><div><div><blockquote style="border-left: 3px solid #8C98B8;
color: #6B748C;
font-style: italic;
margin: 4px 0 12px 0;
padding: 8px 12px;
background-color: #F8F9FC;">
<div style="font-style: normal;
padding-bottom: 4px;">In <a href="https://phabricator.kde.org/D28880#651415" style="background-color: #e7e7e7;
border-color: #e7e7e7;
border-radius: 3px;
padding: 0 4px;
font-weight: bold;
color: black;text-decoration: line-through;">D28880#651415</a>, <a href="https://phabricator.kde.org/p/dfaure/" style="
border-color: #f1f7ff;
color: #19558d;
background-color: #f1f7ff;
border: 1px solid transparent;
border-radius: 3px;
font-weight: bold;
padding: 0 4px;">@dfaure</a> wrote:</div>
<div style="margin: 0;
padding: 0;
border: 0;
color: rgb(107, 116, 140);"><blockquote style="border-left: 3px solid #8C98B8;
color: #6B748C;
font-style: italic;
margin: 4px 0 12px 0;
padding: 8px 12px;
background-color: #F8F9FC;">
<div style="font-style: normal;
padding-bottom: 4px;">In <a href="https://phabricator.kde.org/D28880#651209" style="background-color: #e7e7e7;
border-color: #e7e7e7;
border-radius: 3px;
padding: 0 4px;
font-weight: bold;
color: black;text-decoration: line-through;">D28880#651209</a>, <a href="https://phabricator.kde.org/p/ahmadsamir/" style="
border-color: #f1f7ff;
color: #19558d;
background-color: #f1f7ff;
border: 1px solid transparent;
border-radius: 3px;
font-weight: bold;
padding: 0 4px;">@ahmadsamir</a> wrote:</div>
<div style="margin: 0;
padding: 0;
border: 0;
color: rgb(107, 116, 140);"><p>There are only two places in KDE code where readEntryList() is used, falkon and kwalletmanager; in both cases readEntryList() was used with "*" which means "read all entries", which is logical since in both cases the list is used to fill a "password manager" of some kind.</p></div>
</blockquote>
<p>Does this mean that the most useful API would be entryList() which would return all entries.</p></div>
</blockquote>
<p>Yes. And then the "matching"/filtering part is done with a QSFPM-like model, which is what the two, and only, current users of readEntryList() do... I was hesitant thinking that there may be many entries and that filtering right here in kwallet might make more sense, but how many passwords will an average user have? 10-20 I would say. This is the same as say firefox (didn't look at the internals there), you get a list of all "saved logins" and filter from a line edit. That option is looking more promising (and less work :D).</p>
<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>I am thinking of having 3 new methods (right now there is read{Entry, Map, Password}List, very intuitively replace "read" with "get") that take a third parameter:<br />
enum KWallet::MatchType {KWallet::PlainText, KWallet::Regex}</p>
<p>this way in regex mode, the QString &key parameter is used to construct a QRegularExpression, abstracting the type of the regex class (nitpicking really, since given QRegExp has been around for what 10/15 years? QRegularExpression may live even longer with sturdy PCRE support o/...).</p></blockquote>
<p>Well actually the regexp syntax changed (a bit) so better be explicit.</p></blockquote>
<p>If we go this route, we can be explicit in the docs, but always take a "QString &pattern" param (sort of like KTextEdit find/replace classes, it's always a QString pattern param and a KFind::RegularExpression options flag).</p>
<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;">
<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>New method names solve some hurdles (e.g. overloading a function that takes only one QString param, and it actually invoked by a dbus call).</p></blockquote>
<p>Yes.</p>
<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>In the meantime: <a href="https://marc.info/?t=146788789300003&r=1&w=2" class="remarkup-link" target="_blank" rel="noreferrer">https://marc.info/?t=146788789300003&r=1&w=2</a> , can't say I understood all the issues there but it's definitely a grim read :)</p></blockquote>
<p>Yes the idea of using QtKeychain as the application API came up again more recently, see <a href="https://phabricator.kde.org/T12219" style="background-color: #e7e7e7;
border-color: #e7e7e7;
border-radius: 3px;
padding: 0 4px;
font-weight: bold;
color: black;text-decoration: none;">T12219</a><br />
This would make a lot of sense (abstracting the actual backend).<br />
Still, unless someone makes the bigger effort of "finishing KSecretService" it makes sense to fix the KWallet backend...</p></blockquote>
<p>Yeah...</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R311 KWallet</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D28880">https://phabricator.kde.org/D28880</a></div></div><br /><div><strong>To: </strong>ahmadsamir, Frameworks, dfaure, blaze<br /><strong>Cc: </strong>kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns<br /></div>