<div dir="auto">Yes, it might be worth changing PluggableListMorph to support lists of arbitrary objects. And also it might be nice to get rid of the wrappers, or instead of having many subclasses of the wrappers having only one pluggable wrapper. I think it might be good doing this for HierarchicalListMorph too, I don’t like having to make subclasses of wrappers for every use case. Maybe we can discuss this together in the list and see if we come up with a nice solution, as we did for preferences.</div><div dir="auto"><br></div><div dir="auto">One thing tho: lists can have repetitions, so we still need to use integer indices for the selections.</div><div dir="auto"><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 8 May 2022 at 9:14 PM Mariano Montone <<a href="mailto:marianomontone@gmail.com">marianomontone@gmail.com</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)">El 8/5/22 a las 11:01, Mariano Montone escribió:<br>
> I've removed the extended PluggableLists, and I'm using <br>
> PluggableListMorphs with accessors that retrieve the list of printed <br>
> representations of the model collections, like:<br>
><br>
> directoryListNames<br>
>     ^ model currentDirectoryList collect: [:dir | dir name]<br>
The downside of not having a more pluggable list morph is that I'm <br>
having to traverse the list model many times, once for fetching from <br>
disk, then for printing, then for displaying (Morphic).<br>
<br>
<br>
</blockquote></div></div>