Opened 5 years ago

Last modified 6 weeks ago

#11890 new bug

[HaikuDepot] Refresh depots resets current selection

Reported by: diver Owned by: stippi
Priority: normal Milestone: R1
Component: Applications/HaikuDepot Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All


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.

Change History (11)

comment:1 by diver, 5 years ago

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

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.

Last edited 5 years ago by diver (previous) (diff)

comment:2 by diver, 5 years ago

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%.

comment:3 by apl-haiku, 6 weeks ago

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.

comment:4 by diver, 6 weeks ago

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?

comment:5 by X512, 6 weeks ago

It is possible to update BColumnListView without deleting old items, see

comment:6 by apl-haiku, 6 weeks ago

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.

comment:7 by X512, 6 weeks ago

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?

Last edited 6 weeks ago by X512 (previous) (diff)

comment:8 by apl-haiku, 6 weeks ago

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.

comment:9 by X512, 6 weeks ago

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

Last edited 6 weeks ago by X512 (previous) (diff)

comment:10 by apl-haiku, 6 weeks ago

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?

comment:11 by X512, 6 weeks ago

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.

Note: See TracTickets for help on using tickets.