Re: [Alephmodular-devel] CFileDesc landed

[Woody Z. I. <woo...@sb...>]

On Tuesday, February 11, 2003, at 09:22  PM, Br'fin wrote:

> On Tuesday, February 11, 2003, at 08:52  PM, Woody Zenfell, III wrote:
>
>> Is there any compelling reason to _not_ have it in the interface?
>
> Probably because a 'from-scratch' file browser never occurred to me. 
> Possibly assuming that even SDL had its methods.

Nope sorry, SDL doesn't try to abstract filesystem navigation.

> Essentially I was implementing navigate_up, was wondering how to deal 
> with the case of a volume root. (I'm not at all clear how the CFileDesc 
> stuff would handle volume switching) and then I remembered that the 
> code sample I was using had things in front of it along the lines of "I 
> promise I won't use this stuff for evil" or some such.

navigate_up() from a volume root would probably return an instance 
(oops, no wait, we can't do that - hmm maybe internally there's an 
indirection, a little along the lines of a State or Strategy pattern?) 
of a related (but different) class that's some sort of 
pseudo-master-root thing whose children are the roots of the various 
volumes available.  (?)

> I'm waffling between trying to look into the details of screen 
> management, and being tugged by some file bastions that need some kind 
> of stamping. While I haven't committed to a resource handling API yet, 
> there seems little reason for shapes and sounds to generally be roaming 
> completely free of the portable_files.h API.

Does resource-handling stuff include support for a stronger notion of 
"scenario"?

Woody