<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Hi Luciano,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">El 8/5/22 a las 04:00, Luciano
Notarfrancesco escribió:<br>
</div>
<blockquote type="cite"
cite="mid:CAL5GDyqBim81SwqH+wks+qe3tJ2hG4-aWDRL3LQOBNtKTrJSXQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div>
<div dir="auto">Hi Mariano,</div>
<div dir="auto"><br>
</div>
<div dir="auto">Do you know why exactly the original file list
was slow and why this is faster? Can we improve the
performance of the current file list or the
HierarchicalListMorph in general?</div>
</div>
</blockquote>
<p>I have not strictly measured, so I'm not sure if the problem is
the widget or the disk access, or a bit of both. Also, I've
noticed that my flat file browser is a bit slower for some of my
directories than others. I guess it has to do with directory size.</p>
<p>Also, my machine is quite slow, and with a quite deep file
structure; perhaps not everybody has this problem.<br>
</p>
<blockquote type="cite"
cite="mid:CAL5GDyqBim81SwqH+wks+qe3tJ2hG4-aWDRL3LQOBNtKTrJSXQ@mail.gmail.com">
<div>
<div dir="auto">And why did you find the need to subclass
InnerListMorph and PluggableListMorph and add the instance
variable itemPrinter? Originally PluggableListMorph is
designed to get a list of strings from the model, and on
selection it tells the model the selected index in the list.
It seems that so far we didn’t have the need to allow
arbitrary objects in the lists and using just strings was
enough. I wonder if we can do the same here, and otherwise if
we should make the PluggableListMorph “even more pluggable” by
allowing arbitrary objects as items and avoid adding those two
special subclasses with itemPrinting.</div>
</div>
</blockquote>
<p>Yes. I've done this many times. I really, really want to work
with the underlying objects, not the strings. For example, the
flat file browser displays only the name of the file entries, not
the full path. Also, I'm considering using something like
<filename> - <date> - <size> .. I wouldn't want
to have to parse FileEntries back from those string
representations..<br>
</p>
<p>Now that I think about it, I could use PluggableListMorph with
some ItemWrapper with the custom printing, instead of subclassing
the list morph, but still, it would be another inconvenience
having to wrap/unwrap. <br>
</p>
<p>I have an extension of PluggableListMorph in another package that
supports both itemPrinting and icons. I often use that in my
projects; not this time, as I didn't want to introduce a package
dependency.<br>
</p>
<p>So, yes, making PluggableListMorph more pluggable would be
something worth considering IMO.</p>
<p>Cheers,<br>
</p>
<p>Mariano<br>
</p>
<blockquote type="cite"
cite="mid:CAL5GDyqBim81SwqH+wks+qe3tJ2hG4-aWDRL3LQOBNtKTrJSXQ@mail.gmail.com">
<div>
<div dir="auto"><br>
</div>
<div><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sun, 8 May 2022 at 8:52
AM Mariano Montone via Cuis-dev <<a
href="mailto:cuis-dev@lists.cuis.st" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">cuis-dev@lists.cuis.st</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">Hello,<br>
<br>
I've started a FlatFileList tool, a file browser that uses
a flat <br>
directory list instead of a directory tree as the default
Cuis file <br>
browser does.<br>
<br>
<a
href="https://bitbucket.org/mmontone/mold/raw/master/FlatFileList.pck.st"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://bitbucket.org/mmontone/mold/raw/master/FlatFileList.pck.st</a><br>
<br>
Open via world menu: "open" -> "Flat File List".<br>
<br>
Use double click to open a directory, and visualize files.<br>
<br>
Right click for changing sort order, and file specific
functions (file <br>
in, install, etc).<br>
<br>
You can also enter a directory path directly in the text
input on the <br>
upper-left.<br>
<br>
It is very incomplete and haven't decided on its final
form yet, but .. <br>
it is very fast and useful already for loading code.<br>
<br>
Also, I hope that a file selection tool comes out of this
too, as I <br>
think that'd be useful for other Cuis applications.<br>
<br>
If you want to take a peek and give me some feedback,
that's welcomed.<br>
<br>
Cheers,<br>
<br>
Mariano<br>
<br>
<br>
-- <br>
Cuis-dev mailing list<br>
<a href="mailto:Cuis-dev@lists.cuis.st" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">Cuis-dev@lists.cuis.st</a><br>
<a href="https://lists.cuis.st/mailman/listinfo/cuis-dev"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.cuis.st/mailman/listinfo/cuis-dev</a><br>
</blockquote>
</div>
</div>
</div>
</blockquote>
<p><br>
</p>
</body>
</html>