<table><tr><td style="">ahiemstra added inline comments.
</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/D21721">View Revision</a></tr></table><br /><div><strong>INLINE COMMENTS</strong><div><div style="margin: 6px 0 12px 0;"><div style="border: 1px solid #C7CCD9; border-radius: 3px;"><div style="padding: 0; background: #F7F7F7; border-color: #e3e4e8; border-style: solid; border-width: 0 0 1px 0; margin: 0;"><div style="color: #74777d; background: #eff2f4; padding: 6px 8px; overflow: hidden;"><a style="float: right; text-decoration: none;" href="https://phabricator.kde.org/D21721#inline-132855">View Inline</a><span style="color: #4b4d51; font-weight: bold;">leinir</span> wrote in <span style="color: #4b4d51; font-weight: bold;">atticaprovider.cpp:355</span></div>
<div style="margin: 8px 0; padding: 0 12px; color: #74777D;"><p style="padding: 0; margin: 8px;">That'd be good, except the rest of the KNewStuff API is all QList based. It'll want doing for KF6, but since QList is being deprecated for that anyway, i'm thinking we'll end up with a general QList->QVector porting effort for that time anyway, and right now it'd just be introducing a different API style for seemingly no reason... Otherwise yes :)</p></div></div>
<div style="margin: 8px 0; padding: 0 12px;"><p style="padding: 0; margin: 8px;">Fair enough. I do try to make sure to use vectors as much as possible in new API, but consistency is also a good argument. :)</p></div></div><br /><div style="border: 1px solid #C7CCD9; border-radius: 3px;"><div style="padding: 0; background: #F7F7F7; border-color: #e3e4e8; border-style: solid; border-width: 0 0 1px 0; margin: 0;"><div style="color: #74777d; background: #eff2f4; padding: 6px 8px; overflow: hidden;"><a style="float: right; text-decoration: none;" href="https://phabricator.kde.org/D21721#inline-132849">View Inline</a><span style="color: #4b4d51; font-weight: bold;">leinir</span> wrote in <span style="color: #4b4d51; font-weight: bold;">Dialog.qml:76</span></div>
<div style="margin: 8px 0; padding: 0 12px; color: #74777D;"><p style="padding: 0; margin: 8px;">Because a changedEntries property would logically be for the lifetime of the component instance, where dialogFinished is for this specific time the dialog was opened... The property would reasonably also be useful, but it would be semantically different (unless it's documented as being cleared when the dialog is shown, and then filled with whatever's changed once the dialog has been closed... which we could do, but kind of feels uglier than this signal)</p></div></div>
<div style="margin: 8px 0; padding: 0 12px;"><p style="padding: 0; margin: 8px;">It would match with the FileDialog API (<a href="https://doc.qt.io/qt-5/qml-qtquick-dialogs-filedialog.html#fileUrls-prop" class="remarkup-link" target="_blank" rel="noreferrer">https://doc.qt.io/qt-5/qml-qtquick-dialogs-filedialog.html#fileUrls-prop</a>) however, which also has this behaviour. My main problem with signal parameters is that you cannot bind to them, so using the result gets trickier.</p></div></div></div></div></div><br /><div><strong>REPOSITORY</strong><div><div>R304 KNewStuff</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D21721">https://phabricator.kde.org/D21721</a></div></div><br /><div><strong>To: </strong>leinir, KNewStuff, VDG, Frameworks, ahiemstra<br /><strong>Cc: </strong>ahiemstra, anthonyfieroni, pino, ngraham, kde-frameworks-devel, LeGast00n, GB_2, michaelh, bruns<br /></div>