I have started a  new thread covering the topic of the two previous mails.

'About missing services in FileServices initialize'

This thread is about FileList / FileList2
HH

On 10/5/17, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> Note: What [4] FileList class registeredFileReaderClasses
> says is that in the olden days FileList acted as a file registry.
>
> This is now done by FileServices [5] but is does not do it for all cases
> [6].
>
>
> On 10/5/17, H. Hirzel <hannes.hirzel at gmail.com> wrote:
>> Hello Edgar,
>>
>> Replacing file access with the FileMan API is another issue.
>> This thread is about the FileList *tool*. [3] .
>>
>> The FileMan File accessing API may be loaded through SqueakMap (for
>> 5.1, no entry yet for 6.0a).
>>
>> FileList uses the FileServices registration mechanism [4]. The open
>> task there is that the initialization code does not yet fully do its
>> job [5], [6]. See discussion earlier this year in March in which you
>> took part.
>>
>> Regards
>>
>> Hannes
>>
>>
>>
>> [3] FileList comment:
>>
>> I am model that can be used to navigate the host file system. By
>> omitting the volume list, file list, and template panes from the view,
>> I can also be used as the model for an editor on an individual file.
>>
>> The FileList now provides a registration mechanism to which any tools
>> the filelist uses ***MUST*** register.  This way it is possible to
>> dynamically load or unload a new tool and have the FileList
>> automatically updated.  This change supports a decomposition of Squeak
>> and removes a problem with dead reference to classes after a major
>> shrink.
>>
>> http://wiki.squeak.org/squeak/1975
>>
>> ------------------------------------------
>>
>>
>> [4] FileList class
>> registeredFileReaderClasses
>> 	FileReaderRegistry := nil. "wipe it out"
>> 	^FileServices registeredFileReaderClasses
>>
>> [5] FileServices -- http://wiki.squeak.org/squeak/1001	
>>
>> [6] Which file reader classes are not touched by "FileServices
>> initialize"? -- http://wiki.squeak.org/squeak/1023
>>
>> On 10/5/17, Edgar J. De Cleene <edgardec2005 at gmail.com> wrote:
>>> We should move to new File system.
>>> My choice is Juan Vuletich enhancements of original FileMan.
>>> This could be a case for Enviroments , having two file systems at once
>>> until
>>> all fell confortable with new File system,then rip older and move new
>>> out
>>> of
>>> Enviroments.
>>>
>>>
>>> On 10/4/17, 20:35, "tim Rowledge" <tim at rowledge.org> wrote:
>>>
>>>> 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?
>>>
>>>
>>>
>>>
>>>
>>
>