On 10/5/17, tim Rowledge <tim at rowledge.org> wrote:
>
>> 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.

I assume you mean the model for  the FileList/FileList2 tools?

My answer: Yes!

> 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
>
>
>
>