So far this is working fine, but there was an issue where, if the load of a
very large directory was started, and then the application was cancelled
right away, the application would close down but there would be a long pause
until the shell prompt came back, the cause presumably being that we were
waiting for that particular thread to end.
So here I make sure I check the cancelled state of the worker. This would
also suggest that, while I turned the use of iterdir into a loop so I could
throw the sleep in to emulate a slow directory load, I *actually* want to do
this in a loop so I can test the cancelled state as we stream in the
directory content.
Having got the initial version of background loading of nodes in the
directory tree working, this moves to a gentler approach where only so many
loads run at once, and a queue of jobs that need to be completed is kept.
This is an end-of-coding-session WiP commit; there's more to come on this.
But at the moment I'm happy with the way it's going.
Move the node population code into its own method, the idea here being that
the update happens in one call to call_from_thread rather than spawning lots
of calls to it.
This isn't the final form, not even close, this is more to help test out the
idea and how well it will work. Note the very deliberate sleep in the code
that's there to emulate loading from a slow blocking source.
This will be removed and tidied up before a final PR, of course. The main
aim here is to emulate a worst-case scenario so that the use of a worker can
be tried out with some confidence.
See #2456.
Until now the Tree.NodeExpanded and Tree.NodeCollapsed messages were only
sent out when changes were made to the tree by user interaction. This meant
that if any changes were made with the TreeNode expand, expand_all,
collapse, collapse_all, toggle or toggle_all API calls no messages would be
sent.
This PR corrects this.
The work here is, in part, required for #2456 (DirectoryTree lazy-loads
directory information on node expansion so if someone is expanding nodes
under code control the DirectoryTree never gets to know that it should load
a directory's content) and will build on #1644, essentially adding a missing
aspect to the latter PR.
As I work on what's to come (loading DirectoryTree with a worker), I'm going
to want to try and construct slow loads so I can test the effectiveness of
the changes. This means a desire to fake a very slow source of directory
information. So let's drop this into its own method so we can then do silly
things like add a sleep to really show stuff down.
I'll admit to not really following what the code does, so will really need
someone with a better understanding of the aim of this code to look over the
proposed fix; but based on a bunch of runs and hand-debugging, this seems to
do the job.
This passes all existing tests and also removes the reported error.
On the other hand I'm not confident that I'm *not* just masking an
underlying issue with this function.
