Hi all,

maybe it's not a rational thing. I also follow Chris "everything in one
folder" approach. On Windows it's super portable. I just opened a 3.6
which somehow has made it through the decades to this Win10 laptop and
everything worked out of the box. And I assume that's true for all
Squeak installations I have.

And I would also consider the thought "Where should this go?" an
annoyance. I remember having lost data because I was too eager to leave
the computer to wait for success. :-)

Squeak lends itself to so many different ways of using it. I'd love if
it stays that way.

Cheers,

Herbert

Am 29.12.2019 um 23:35 schrieb tim Rowledge:
>
>> On 2019-12-29, at 12:45 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>>
>> That's not a valid comparison.  You're looking at a small machine with a very small file system.  You need o run it on a large machine with a very full filesystem.  The time taken isn't dependent on the speed of the machine, but dominated by the amount of files and directories examined.
> Mmm... ok, the file directory scanning for the tree view is certainly horribly horrible. The most complex one I have to hand is my iMac, using an image within a bundle; that's a bunch of layers down in some relatively big directories and is essentially instant.
>
> The current algorithm for generating the directory tree does some extraordinary hoop-jumping that must surely be improvable.
>   - it gets a listing of the root directory's subdirectories and wraps each one in a complex Morph
>   - it builds a list of the directories in the path to the current image directory keeping the full pathname of each for some reason
>   - it finds the first root directory subdirectory morph and scans from there through its siblings to find the first one with a name suitably matching the first thing in the above directory pathname list
>   - which it expands
>   - which causes it to list all the subdirectories  and so on until the list of directory pathnames is exhausted
>
> So at least it doesn't read the name and path of every file in the entire universe.
> It *does* add in the names of any cached known servers (which I've mentioned several times is very out of date and in need of flushing). It does use the possibly wasteful FileDirectory>>#directoryNames that reads every name in the directory and test every one for directory-ness; surely there are faster approaches for most OSs? It does rely on assumptions about root directories, which we can blame on the generally inadequate filesystem code. Some OS (I'm giving you the stink-eye here, Windows 10) having very strange ideas about directory layouts and names and so forth.
>
> A very deep directory tree above your image directory will add time, as will any of those directories being very large. We could certainly design a faster approach to building a useful directory display for the typical purposes a FileDialog is useful for; the current one simply reuses the stuff in the FileBrowser.
>
> But I claim that for occasional use UI such as finding a new place/name to save you image, or your preferences, or  whatever, that anything less than half a second is effectively instant to human perception. Unless perhaps you are a dyed in the wool twitch-gamer with perceptual reflexes tuned to microseconds in preparation for being beamed up by the alien visitors that need your mind to fight a galactic war.
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Klingon Code Warrior:- 2) "My program has just dumped Stova Core!"
>
>
>