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