There's a significant underlying principle there. Commom UI widgets are not prepared to deal with collections of widely varying sizes.
The two-pane file browser (folder tree plus folder contents like Windows 95 Explorer, or two parallel panes like Norton Commander) was a compromise solution that has worked for decades.
But this idea of showing in context a limited view of representative items of each collection could be generalized and exploited in other generic data-heavy interfaces, where there's no business code to show the specific data loads in the best way.
It's the zero/one/infinity rule. Programmers don't even know what it's called, they just absorb it by osmosis. But in the real world there are so many lists that will never have more than 20 items.
Well, I'd say the rule should be upgraded as zero/one/small-sample/expand-for-infinity, at least for user interfaces (not for coding, although doing it for coding is what lazy evaluation is for).
> Commom UI widgets are not prepared to deal with collections of widely varying sizes.
I don't think there is a standard widget other than what's implemented by each solution. Broot is one way of looking at a volume at the expense of lots of disk reads (for every file on the volume). Ranger does that at a single depth and that's a design choice in Miller's view. nnn doesn't prefer to read within directories unless explicitly requested and that's a design choice too. There's nothing good or bad about these other than a choice to the user to pick the one that fits his use case.
A user always has the liberty to concentrate only on the current directory, just know where he is in the filesystem from the file path and do a fuzzy search to find a file deep in the subtree when he needs to do so. As you might have noticed, even with Broot there's no simple way to list the files marked "unlisted" without navigating to the dir and expanding it. It's a nice program and is a solution to people who likes to see a snapshot of the filesystem in a glance. But would everyone be always interested in the contents of /etc, /run, /usr and /var as shown in one of the sample images?
Anything listed at https://en.wikipedia.org/wiki/Graphical_widget#List_of_commo... does count as "standard widgets". There may be variations in different GUI libraries, but anything that deviates too much from common user expectations will be perceived as broken.
There are ways to avoid traversing the whole volume in each use, namely caching each directory content when it's updated.
As for always showing unwanted information, an interactive solution could allow an option to "fold and hide" specific folders so that their contents are not shown until the user specifically reopens them. A user-friendly interactive solution doesn't require the user to remember and choose among all the available choices for each use, it provides good defaults and reminders on how to access alternative options when those are needed.
One of the guiding principles of nnn is minimum disk IOs so probably it's not comparable in this respect. Reading through a complete volume on a stuffed microSD or SD card attached to a RaspberryPi to list the filesystem and then supporting dynamic events may not be very simple. nnn development is driven by minimum resource availability and usage.
Yes, but that's a less informative solution, as you can only see contents of one directory at a time. Broot provides a more comprehensive view of the file system.
