[squeak-dev] FileList2>listForPattern(s): and MessageSend abuse

Marcel Taeumel marcel.taeumel at hpi.de
Thu Oct 5 09:32:35 UTC 2017


Hi, there.

We should distinguish between (1) tools for artifacts and (2) the artifacts themselves. That is, cleaning-up FileList and FileList2 is a different challenge than moving to a new file system, which would also need appropriate tools.

Let's not mix those up but keep focus during discussions if possible. ;-)

Best,
Marcel
Am 05.10.2017 10:47:18 schrieb Edgar J. De Cleene <edgardec2005 at gmail.com>:
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" 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?




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20171005/c101263d/attachment.html>


More information about the Squeak-dev mailing list