D29123: Do not mark entry as uninstalled if uninstallation script failed

Alexander Lohnau noreply at phabricator.kde.org
Wed May 6 16:39:47 BST 2020


alex added inline comments.

INLINE COMMENTS

> leinir wrote in installation.h:124
> Hmm... i find myself wondering what effect this has on BIC... something tells me it might not be so great... Specifically, https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B#The_Do.27s_and_Don.27ts says that you cannot change the signature of existing functions of any type... However, it feels more like a problem with the documentation - the idea is that the entries passed into functions aren't changed (and this really should probably be a const reference, but for some reason it isn't, and again we can't change that for bic-iness), and so really what /should/ happen is that rather than saying "The entry instance will be updated" and so on, what it should be doing is say "If the entry is successfully uninstalled, listening to signalEntryChanged(const KNSCore::EntryInternal &) for an entry equal to the one you have passed in will allow you to detect the result of calling the function".
> 
> That's what it's already doing, and how it is used in places which call the function, so probably makes sense to fix that.
> 
> In the longer term (think KF6), i would also quite like all the functionality here to end up entirely asynchronous.

I told myself yesterday that I am going to have a look at this patch again^^
And you are absolutely right :-)

REPOSITORY
  R304 KNewStuff

REVISION DETAIL
  https://phabricator.kde.org/D29123

To: alex, #knewstuff, meven, ngraham, leinir
Cc: leinir, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20200506/1a30af8b/attachment-0001.html>


More information about the Kde-frameworks-devel mailing list