HaikuDepot's contents tab should live-update

[humdinger]

This is hrev48848.

HaikuDepot's "Contents" tab can only show a package's contents after it's been downloaded/installed. But currently, if I click the "Install" button, I still have to restart HaikuDepot for the "Contents" tab to show the contents. Would be nice if the tab's view could be informed that the contents is now available for displaying.

[TwoFx]

Proposed patch

[TwoFx]

The attached patch updates the contents tab each time the status of the attached package changes.

[stippi]

Thanks for your work / the patch! I faintly remember that checking and preventing the same package to be rescanned in PackageContentsView was done for performance reasons. Are you sure there is no performance regression now in certain use-cases? To make sure this cannot be the case, one could move code from SetPackage() into a separate public method (maybe ScanPackage() ?) and then call that method directly when the package status changes.

[TwoFx]

Good idea. I will look into that as soon as I am home. Another option would be to reintroduce the check I removed but only return if the package is already known and its state has not changed since it was last scanned.

[stippi]

Yes, the last idea is good.

[TwoFx]

I believe that the fPackage == package check was there to circumvent a bug in PackageContentsView: fContentsView->MakeEmpty() is called outside the populator thread, so when SetPackage is called twice in a row for the same package in very quick succession, MakeEmpty is called twice and then the populator runs twice. Those quick successive calls seem to occur rather frequently in HaikuDepot, so with the check removed, you would sometimes see the "Package contents not available for remote packages" message twice in the content tab. Now, with the check reinstantiated, the bug does not occur any more, but I still suggest calling MakeEmpty again in either _ContentPopulatorThread or _PopulatePackageContents.

[TwoFx]

Improved version of the proposed patch

[stippi]

Somehow the patch did not apply anymore, and I noticed that there were no checks for packageRef.Get() != NULL. So I quickly re-implemented it based on your patch. Thanks! Fixed in hrev49557.