[HaikuDepot] Refresh depots resets current selection

[diver]

This is hrev48851.

Search for Jamfile in HaikuDepot and select Pe. Click Tools->Refresh depots. Several things go wrong here:

• Last package in a list doubles for a second and then disappears
• Icon of the current package changes to generic package icon for several seconds
• Package selection is lost

Refreshing depots takes 6 seconds here and uses 100% of cpu during this process.

[diver]

I can reproduce these issues only in VMware Fusion. I decided to delete HaikuDepot's cache in ~/config/cache/HaikuDepot. And it seems that it is now having some problems downloading some data from depot.haiku-os.org:

Response code: 400
Error sending request: General system error

It misses quite a few featured packages and doesn't show any icons nor package localization. However, it shows screenshots.

[diver]

The second part of the ticket is reproducible in vbox now. I.e.:

• Package selection is lost.
• Refreshing takes a whopping 13 seconds during which CPU load is at 100%.

[apl-haiku]

The new behaviour after hrev54245 is to remove all of the packages then reload them from scratch. I think this is logical. The reload should be reasonably fast now.

Loosing the selection doesn't seem unusual when clearly everything is being reloaded. It is hard to retain the selection because the packages and their data are loaded asynchronously. Because of this, the moment when the old selection should be restored is difficult to ascertain.

I think this ticket can be closed; please confirm.

[diver]

I think removing all of the packages on refresh should be avoided. Is there a problem with BColumnListView performance that it can't be made on the fly?

[X512]

It is possible to update BColumnListView without deleting old items, see ​https://github.com/X547/HaikuUtils/blob/master/Services/Services.cpp#L86.

[apl-haiku]

For the search / filtering this is exactly what it is doing now -- it is adding and removing items and this is very performant.

The "reload everything" function (effectively what "Refresh Repositories" is doing) is needing to reset HD's state against the package manager and so it is easiest to remove everything and start again in this case. To diff the in-memory state against the package manager's state would be quite a bit of work to orchestrate.

This is why the view is first blanked out and a reload happens. It is akin to restarting the application.

[X512]

To diff the in-memory state against the package manager's state would be quite a bit of work to orchestrate.

Is it possible to just lock loop during updating list?

[apl-haiku]

I think that would be quite ugly because it takes a while for it to fetch the material from the remote site for the package manager and also some time for the application to try to re-fetch data from HDS etc... and during this time it's doing a nice progress bar and gradually showing the data etc... -- so just locking up over this time would be a bit ugly. I think the way it works now after the latest changes is fine.

[X512]

I mean lock only when changing BColumnListView after all data has been already downloaded and ready.

[apl-haiku]

Sorry for being a bit slow, but I can't quite see what you mean. Do you mean to lock the Window UI when the MainWindow::_AddRemovePackageFromLists method is invoked? If so that's not really necessary because this should be happening on the main thread as a result of BMessage passing shouldn't it?

[X512]

MSG_PACKAGE_CHANGED seems to change 1 row at a time. I mean updating all list at once when message is received, not one by one.