> On 03-10-2017, at 12:59 PM, tim Rowledge <tim at rowledge.org> wrote:
[snip everything but the randomly chosen sigline]
> Two wrongs are only the beginning.

Too true in this case. As I look through and trace the code involved in FileList and it’s subclasses I’m struck (forcefully) by the amazing appallingness of it. 

Some highlights of the horror movie -

 - FileList is referred to in 70 places, FileList2 in 33. Which one is meant to be our standard UI for files? No idea.
 - When opening a default FileList (from the dock menu for example) the contents of the default directory are read and processed twice. This may not seem a big deal, unless perhaps you have a thousand or more files in a directory, or your default directory is across a network, or you machine is slow etc. It’s stupid, whatever.
 - A FileList2 seems to double that stupidity.
 - There are strange artefacts of what looks like partial attempts to hack in EToys support, left to bitrot.
 - Why would a FileList be a subclass of StringHolder?
 - A default FileList is built via the ToolBuilder. FileList2 adds a load of non-TB ways to build.
 - The look of different variants of secondary dialogues built from FileList* vary wildly. Some have rounded blue frames. Some look like ‘normal’ windows.
 - Some variants show a directory hierarchy by adding spaces in front of path elements. Others use a hierarchy displaying morph. The space-formatted list is built even when not needed.
 - FileChooser adds yet another layer of ‘interest’ but appears totally unused.
 - PluggableFileList appears to only actually get used within MVC world, which is just as well since the morph version is rather ugly; it also seems to be only referred to usefully from StandardFileMenu, which makes an especially odd thing since the code reads as asking for a menu and you get a dialogue/window. And in some places the code alternately requests a StandardFileMenu and a FileList! Talk about causing confusion. As an extra bit of fun, the fact that it got squeezed into place as if a menu means that it has to implement assorted menu messages like #startUpWithCaption:

I think we’re probably at the point where a completely new file accessing model is needed in order to try to obsolete this nest of nightmares. Unless, of course, someone can point to a nice replacement already written and functional?


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: RLB: Ruin Logic Board