01:52 wayland joined, wayland76 left
japhb Ooofta. Back from a couple days away. 04:48
So, last question first: 04:49
long-name was intended to be a *user-readable* name that could e.g. appear in detail text or some such. Also useful when for example a user is 6 levels deep in a dir tree and then goes "Wait, *which* config/ dir was this?" 04:50
It applies to *any* node. 04:51
Er, any Node
Parent.id was meant to be an opaque, unique, and unchanging identifier for a particular node. It just so happens that in some cases, a unique long-name happens to be usable as a unique ID as well. 04:52
So you can think of .short-name fulfilling a similar role to .gist in Raku, .long-name for .raku, and .id for .WHICH. 04:53
Previous issue: the locking inversion from TWVTP.c() ... 04:57
The intent of Volatile::* was to represent data structures that might get modified at any time by some other thread, or even some other process (this is the case with DirTree, for instance). It is also assumed that getting the current state might be slow (such as disk accesses, database queries, network lookups, etc.) 04:59
I had on my local todo to allow indicating a user-wait state for this.
For example, clicking on a DirTree node to expand it might show an hourglass where the expanded/collapsed arrow normally is, until the new entries actually appear and are visible, at which time the icon switches to an expanded arrow. 05:01
It is reasonable to me to implement this in terms of a promise/then, supply/act, or channel/receive model, though we might need to be clever about whether and how the reactor and event model got included in this. 05:04
Do you have a local diff that
's doing what you want already?
patrickb: ^^
Geth Terminal-Widgets/main: 2e8e9ab96a | (Geoffrey Broadwell)++ | docs/getting-started.md
Add Drawing Sequence section to getting-started doc
05:56
patrickb I don't have a patch for the Volatile::Parent.children() that returns a promise. Currently I just hold back on putting all my outside UI state modifications on the T-W reactor. This helps avoid the deadlock, but is obviously racy. 06:23
Thanks for the long-name explanation. I might actually use this then. (I do have a "Details" frame showing details for the currently selected symbol.) 06:26
The user-wait state would fit my bill perfectly. I do have a "longish" running operation. (It's a few network requests.) One more thing to consider: The operation can possibly error. So when not getting a result it's be nice to somehow signal an error condition. (Maybe replacing the hourglass with an error marker?) 06:31
japhb Oh that's an excellent idea 06:43
Makes me wonder if DisplayNodes need a .state attribute, and whether expanded/collapsed should be part of that or separate. If part of it, we could have: Collapsed, Pending, Error, Expanded. But maybe we want to be able to poll every so often for updates, and have some way to indicate that the poll failed to get updates. So then we have expanded/collapsed orthogonal to 06:52
unknown/pending/error/out-of-date/current or what have you.
If anyone has any ideas or use cases that should be handled, I'm all ears. (all eyes?) 06:54
patrickb I do have the case of an updated state in the debugger. When e.g. stepping, the variable's content can change and new variables can ente 07:17
appear.
I planed to do this by diffing previous and new state and then rebuilding the tree from scratch. (Restoring selected item and topmost visible item.) Changed /new items are highlighted. 07:19
Speaking of such, is it currently possible to retrieve and set the topmost visible item? 07:20
The updated thing doesn't happen via polling, is triggered by an external event. (A step completes or a breakpoint hits, ...) 07:24
So at least for my usecase, combining expanded / collapsed and pending/error would work out. 07:27