Normally it's not a great idea to eat and hide exceptions within library
code; but I think it makes sense to make an exception here. This is a UI
element that lets the user navigate about a filesystem. If there is
something they don't have permission for, that should not cause an
exception, it should just give up with the best possible outcome.
If actually doing something with the exception is important, the developer
using this could use the filter to do tests and act accordingly.
See #2564.
Plan C; or is it plan D? Something like that. Anyway... in this approach we
keep a single "forever" async task worker per directory tree, which in turn
looks at the async Queue, and when a new node appears on it it starts a
short-lived thread to load the directory data.
This seems to be working fine on macOS. Next up is testing on Windows.
Turns out, there's a maximum number of threads you can have going in the
underlying pool, that's tied to the number of CPUs. As such, there was a
limit on how many directory trees you could have up and running before it
would start to block all sorts of operations in the surrounding
application (in Parallels on macOS, with the Windows VM appearing to have
just the one CPU, it would give up after 8 directory trees).
So here we move to a slightly different approach: have the main loader still
run "forever", but be an async task; it then in turn farms the loading out
to threads which close once the loading is done.
So far tested on macOS and behaves as expected. Next to test on Windows.
When the default screen is first created it was not getting the event ScreenResume. All other screens receive a ScreenResume when first created and _all_ screens (the default one and custom screens) receive this event when they become the active screen again, so this was kind of an edge case that needed the event to be posted by hand.
Related comments: https://github.com/Textualize/textual/pull/2581\#issuecomment-1550231559
After deciding
https://github.com/Textualize/textual/pull/2545#issuecomment-1547544057 it
makes more sense to roll back to the state of `main` than to try and get to
where I want to be from where we've decided we didn't want to be.
Can't get there from here, so let's go rogue-like on this PR...
While the fix for #2557 likely isn't *the* fix (see #2582 for some context
around that), it is a fix that works for now. As such, with the change,
there was a double attempt to refresh the content tracking in the clearing
of options in the OptionList, which shouldn't be necessary.
This removes that.
