A little teaser for something I have in the works

Get Help
6

Also, @logan, if I may bend your ear a little more, there is a kind of wish list that has developed from my experiment:

  1. Multi-line items in TreeViews. One line gets really short when you want to convey some information with the item, as happens with test results. Barring this, providing some alternative section view type with a flat, more textual structure would work too, as one could create a parent-child section relationship to provide more information for the selected TreeView item in that case (tooltips really do not cut it when it comes to that). People have been creating information type panels in sidebars, which are shallow (no child items); those would also greatly profit from that kind of capability, I think.
  2. Make FileSystem.listdir() accept a glob pattern like FileSystem.watch() does. Right now, I have to bridge between the pattern I need to provide to the latter and the literal path the former needs to get my test files, which is a bit of a pain. Not trivial, as accepting “**” means recursive listing, but that would be so very helpful.
  3. Document that FileSystemWatcher fires two events for changes, first an “old state” one, then a ”new state” one. Now, that is actually very cool, as it allows you to figure out what happened (one event, file exists: file addition to the watch path; the inverse means file removal; two events mean file modification when identical, file renaming when not), but should be documented. Of course, having the watcher itself do the figuring out and returning a matching event would be even better. I have a hand rolled version debouncing processing by 1 ms to wait for the second event, but that suffers from race conditions in mass changing situations.

From the department of “it might just be me, but”, we have:

  1. I had a hard time figuring out that TreeViews need to match a sidebar section ID, not a sidebar ID. The code provided by the extension generator names both the same, so the more dense readers (like me) can be led astray.
  2. I can’t for the life of me get TreeView.reveal() to expand parents of items to reveal, even while providing a “reveal” count vetted to match the hierarchy (and being below 3, I hasten to add). Selecting works, expanding does not; am I missing something?

Finally, fresh out of the department of “wouldn’t that be nice, probably not worth the effort, tho”, I have one item:

  1. Refreshing TreeViews via root level (argless / null) reload() flickers something fierce. While reloading an existing element is smooth as butter, root level reloads make the tree disappear, then rebuild, which is visually rather irritating. As noted, the internal diff of the source needed to not make this happen is probably not worth it, but, hey, I’m wishing for a pony already, might as well …
2 Likes