[PD] [getfilenames] alpha test release

[Hans-Christoph Steiner]

Claude Heiland-Allen wrote:
> On 26/07/10 17:14, Mathieu Bouchard wrote:
>> On Thu, 15 Jul 2010, Hans-Christoph Steiner wrote:
>>> On Jul 15, 2010, at 11:59 AM, Mathieu Bouchard wrote:
>>>> Oops, right. I looked at my auto-screenshot tool, which uses
>>>> [folder_list], and it's using a messagebox with "add2", to build a
>>>> list from the output of [folder_list]. But I only remembered using
>>>> the list, not how I got to have a list in the first place.
>>> Seems like [folder_list] should probably output a proper list... can
>>> anyone shed any light on the advantages of the two approaches?
> 
> Getting a folder listing is not an atomic operation, and interfaces that
> try present it as atomic are made of fail (for example, try using GIMP's
> file open dialog in a directory containing 10000+ files - I ended up
> having to kill GIMP from the console because I couldn't wait for the
> "cancel" button to be operable).

That sounds like an argument against the "one big list" interface.  I
wonder if a glob would similarly barf, because globbing is one big
operation, then you iterate thru it.  So representing that as a list
isn't so far off.  But maybe globbing is quite efficient... I don't know
I haven't tested it tho.

.hc

> 
>> the list output approach allows to use [list split] on it in any way you
>> want... go back and forth... access items by index.
>>
>> First-next and start-next approaches are good when you're really thin on
>> memory and have lots of files, which is very relative, considering how
>> much RAM we have to waste these days.
>>
>> The latter would have more of an advantage if you needed to output
>> multi-element entries, especially when those entries have variable
>> number of elements, but that typically doesn't happen with something
>> like [folder_list] (it could happen for some other classes for which
>> you'd ask yourself that question). It's related to the lack of
>> nested-lists in Pd.
> 
> 
> Claude