Heavyweight tasks should be asynchronous

[nexus6-haiku]

Currently, loading a medium sized project folder from disks is fairly quick but the process may require several minutes when loading large code base like the Haiku source, for example. Tasks like loading or building a project should be made asynchronous and performed in a separate process. A progress bar could be added in a status bar at the bottom of the main window with a progress bar indicating that something is moving on. Once the task is completed a message should notifiy the user and ideally a BNotification may be shown as well. The strategy implemented in _ProjectFolderScan may also be revisited and optimized.

[Freaxed]

About loading a large folder structure: what's the main bottleneck of the loading? We could investigate a bit and optimize it before the full async solution is ready. Let's try for example to remove the icon loading.. how much does it effect the overall processing time? Does it make sense to have a dynamic loading? I provide the user the first level quickly then in background I can prepare the others.. or maybe I load the other levels as soon as they are requested..

[nexus6-haiku]

Lazy loading might be useful when traversing the folder tree, further analysis is required though as I don't know how this would work with Node monitoring

[Freaxed]

I did some measurements: On my system loading the 'haiku' repository in the current project-folders branch took 6.10291 seconds. By removing the icon loading it took 2.1702 seconds.. (around -65%)

What about if we preload a set of icons? Like one for folder, one for cpp, for h, for Makefile.. and one for generic file? We can set the icon only based on extension otherwise if we read the mime, we lost the speed :)

[waddlesplash]

Tracker has an IconCache system for this exact reason. It supports per-node icons, but it defaults to just using the MIME type's icon (it also shares the BBitmaps in memory so a new one is not allocated for each entry with the same MIME type.)

[waddlesplash]

You can also improve the situation by overriding ExpandOrCollapse of BOutlineListView to load and insert the items, before calling the base class implementation to do the actual expansion. That should work with node monitoring, too, as monitoring can be associated with the BListItem for the folder (and you can use B_WATCH_CHILDREN to avoid having a separate node monitoring entry for every item within a folder.)

[nexus6-haiku]

and you can use B_WATCH_CHILDREN to avoid having a separate node monitoring entry for every item within a folder.)

Thanks @waddlesplash, unless I'm short sighted the documentation for NodeMonitor.h does not seem complete. Can I use B_WATCH_DIRECTORY | B_WATCH_CHILDREN on the project folder (root) to watch all the changes in it including all the items below it in the hierarchy down to n-th level children?

[waddlesplash]

No, B_WATCH_CHILDREN only applies to a single directory. You will need to traverse the tree and run it on each directory in order to see changes to children of each directory.

[Freaxed]

There is also PathMonitor.h with a private call to do recursive monitoring..

Il giorno lun 6 mar 2023 alle ore 16:18 waddlesplash < @.***> ha scritto:

No, B_WATCH_CHILDREN only applies to a single directory. You will need to traverse the tree and run it on each directory in order to see changes to children of each directory.

— Reply to this email directly, view it on GitHub https://github.com/nexus6-haiku/Genio/issues/18#issuecomment-1456328896, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALC2DTBWIPRLIR7HLCMW5TW2X53HANCNFSM6AAAAAAUZT7O5A . You are receiving this because you commented.Message ID: @.***>

[nexus6-haiku]

A quick summary of the past few weeks:

1. Path monitoring at the project folder lever (and all its children has been implemented and merged in the main branch (using private PathMonitor class)
2. Some experiments on ExpandOrCollapse in BOutlineListView highlighted a bug in the current implementation of this control. As a consequence, we now carry a patched version of BOutlineListView in Genio source tree and @Freaxed has submitted a patch to Haiku

[nexus6-haiku]

@waddlesplash I assume there is no way to reuse IconCache in Genio? I can see BPrivate::IconCache and BPrivate::Model with autocompletion but without the include files build fails. I've tried to add these to the project but I've easily ended up adding half of the Tracker includes. Any advice?

[Freaxed]

What about if we implement a basic iconcache by ourself? Shouldn’t be much far from an std::map<fileType, BBitmap*> ..

Il giorno mer 29 mar 2023 alle 11:37 Davide Alfano @.***> ha scritto:

@waddlesplash https://github.com/waddlesplash I assume there is no way to reuse IconCache in Genio? I can see BPrivate::IconCache and BPrivate::Model with autocompletion but without the include files build fails. I've tried to add these to the project but I've easily ended up adding half of the Tracker includes. Any advice?

— Reply to this email directly, view it on GitHub https://github.com/nexus6-haiku/Genio/issues/18#issuecomment-1488268917, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALC2DQVIP3GJMKWM5NPUS3W6P7GZANCNFSM6AAAAAAUZT7O5A . You are receiving this because you were mentioned.Message ID: @.***>

[nexus6-haiku]

Sure but I would prefer reusing the existing IconCache, if there's an easy way to do it. Otherwise we can go your route for sure. Current IconCache implementation picks up the icon from either the node or the mime type. Is the former any quicker?

[waddlesplash]

The internal Tracker classes should not be used directly outside the tree, they do change. As a general rule, don't copy any headers into a project from outside headers/private/... without also copying the .cpp files too.

The Model usages in IconCache should probably be deleted. Actually it may indeed make the most sense to write a separate caching system, Tracker's is pretty specific to it...