<body><div id="__MailbirdStyleContent" style="font-size: 12pt;font-family: calibri;color: #000000">
Hi, there.<div><br></div><div>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.</div><div><br></div><div>Let's not mix those up but keep focus during discussions if possible. ;-)</div><div><br></div><div>Best,</div><div>Marcel</div><div class="mb_sig"></div><blockquote class="history_container" type="cite" style="border-left-style:solid;border-width:1px; margin-top:20px; margin-left:0px;padding-left:10px;">
<p style="color: #AAAAAA; margin-top: 10px;">Am 05.10.2017 10:47:18 schrieb Edgar J. De Cleene <edgardec2005@gmail.com>:</p>We should move to new File system.<br>My choice is Juan Vuletich enhancements of original FileMan.<br>This could be a case for Enviroments , having two file systems at once until<br>all fell confortable with new File system,then rip older and move new out of<br>Enviroments.<br><br><br>On 10/4/17, 20:35, "tim Rowledge" <tim@rowledge.org> wrote:<br><br>> Too true in this case. As I look through and trace the code involved in<br>> FileList and it¹s subclasses I¹m struck (forcefully) by the amazing<br>> appallingness of it. <br><br>Some highlights of the horror movie -<br><br> - FileList is<br>> referred to in 70 places, FileList2 in 33. Which one is meant to be our<br>> standard UI for files? No idea.<br> - When opening a default FileList (from the<br>> dock menu for example) the contents of the default directory are read and<br>> processed twice. This may not seem a big deal, unless perhaps you have a<br>> thousand or more files in a directory, or your default directory is across a<br>> network, or you machine is slow etc. It¹s stupid, whatever.<br> - A FileList2<br>> seems to double that stupidity.<br> - There are strange artefacts of what looks<br>> like partial attempts to hack in EToys support, left to bitrot.<br> - Why would a<br>> FileList be a subclass of StringHolder?<br> - A default FileList is built via the<br>> ToolBuilder. FileList2 adds a load of non-TB ways to build.<br> - The look of<br>> different variants of secondary dialogues built from FileList* vary wildly.<br>> Some have rounded blue frames. Some look like normal¹ windows.<br> - Some<br>> variants show a directory hierarchy by adding spaces in front of path<br>> elements. Others use a hierarchy displaying morph. The space-formatted list is<br>> built even when not needed.<br> - FileChooser adds yet another layer of<br>> interest¹ but appears totally unused.<br> - PluggableFileList appears to only<br>> actually get used within MVC world, which is just as well since the morph<br>> version is rather ugly; it also seems to be only referred to usefully from<br>> StandardFileMenu, which makes an especially odd thing since the code reads as<br>> asking for a menu and you get a dialogue/window. And in some places the code<br>> alternately requests a StandardFileMenu and a FileList! Talk about causing<br>> confusion. As an extra bit of fun, the fact that it got squeezed into place as<br>> if a menu means that it has to implement assorted menu messages like<br>> #startUpWithCaption:<br><br>I think we¹re probably at the point where a completely<br>> new file accessing model is needed in order to try to obsolete this nest of<br>> nightmares. Unless, of course, someone can point to a nice replacement already<br>> written and functional?<br><br><br><br><br></tim@rowledge.org>
</blockquote>
</div></body>