Re: [Alephmodular-devel] CFileDesc landed

[Br'fin <br...@ma...>]

On Wednesday, February 12, 2003, at 11:55  AM, Woody Zenfell, III wrote:

> On Wednesday, February 12, 2003, at 06:13  AM, Br'fin wrote:
>
>> It's doable to setup something that has an innerclass that changes 
>> when it hits that point, but seems somehow... annoying.
>
> Right, this is what I was picturing.  Maybe feels annoying in the 
> implementation half, but then you have a clean consistent interface 
> from the outside that has the capabilities you need on all platforms.  
> Well, I suppose there is an argument to be made for "good enough for 
> now" though; even having a navigate_up() that tops out at the volume 
> root (and won't let you switch volumes) would probably let a 
> from-scratch file browser cover most users' needs.

Well here are my choices in the matter, as I see it:

Implement navigate_up to include a meta-root for volumes and which 
increases the object hierarchy complexity for most platforms. (Adding 
one method to CFileDesc now requires changes to THREE classes for a 
specific platform... basic CFileDesc, and then volume and file 
delegates.)

Or implement an incomplete navigate_up. (It may not be able to back up 
past the current volume) or no navigate_up at all. (But I'm close 
enough now that the incomplete one is doable) And implement a 
get_volumes method on CFileDescFactory that returns a vector with 
CFileDesc that point to each existing volume's root. This doesn't alter 
the object hierarchy and it adds everything that I would think you 
would need. (Well, excluding the directory perusal stuff that isn't yet 
implemented either :))

I'm inclined to go with the latter approach considering the tradeoffs 
that I see.

>> Ah, I didn't realize that that processing was a feature of AlephOne 
>> specifically. I'll have to look into it. Does A1 deal with a 
>> MacBinary of a map file too? Or does that still need to be explicitly 
>> split out into two files?
>
> It looks like (though I have not tested this myself) that it should 
> indeed be able to read both forks from the single MacBinary file, no 
> need to split.
>
> Resource fork: look in resource_manager.cpp for the 
> resource-fork-parsing routines... see e.g. around line 124, in 
> res_file_t::read_map() (which reads a resource-fork-map, not a Map 
> file :) ).  (Since my resource forks are in files on my Windows 
> machine, and I can play... well this code seems to work.)
>
> Data fork: look in FileHandler_SDL.cpp, e.g. line 363 
> FileSpecifier::Open().

That's just cute. Insanely cute :)

Hsm. I'm not sure how on earth I would do that with iostreams. I mean, 
I know how I might do it, but I honestly have no idea as to whether I 
can do it that way, I don't know which kinds of methods I can override 
safely. Durn C++.

-Jeremy Parsons

> Yeah A1/SDL (not SDL itself) also does things like interpreting  'snd 
> ' resources (as long as they're of a specific subtype of course) and 
> 'PICT's (again, not the fully general case of course)... it had to to 
> be able to work with the existing data files as-is.
>