And there is no FileList2 in Pharo.

On 10/5/17, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> Thank you for the analysis, Tim.
>
> Noteworthy that FileList2 has a class comment from 2003.
> http://wiki.squeak.org/squeak/2379
>
> But it seems FileList2 goes back at least to version 3.0 (screen
> shot). It seems it was introduced as an experiment for extending
> FileList and then later was never fully integrated.
>
> As FileList is built via the ToolBuilder it seems worthwile to focus
> on extending that and get rid of FileList2.
>
> --Hannes
>
> 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.
>> 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
>>
>>
>>
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FileList_tool_in_Pharo6.png
Type: image/png
Size: 144141 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20171005/1e94fa03/attachment-0001.png>