Fwd: [Alephmodular-devel] CFileDesc landed

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

d'oh.

Begin forwarded message:

> From: "Woody Zenfell, III" <woo...@sb...>
> Date: Wed Feb 12, 2003  10:55:11  AM US/Central
> To: "Br'fin" <br...@ma...>
> Subject: Re: [Alephmodular-devel] CFileDesc landed
>
> 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.
>
>>> A1 as you probably know has code to interpret the relevant parts and 
>>> types of the resource fork straight from a raw 
>>> resource-fork-formatted file, from an AppleSingle file, or from a 
>>> MacBinary file.  I think that qualifies as a 'specific format', and 
>>> better yet doesn't really require any conversion for existing content.
>>
>> 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().
>
> 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.
>
>> I'll look into it, But there is an advantage to keeping the Resource 
>> Manager implementation separate from a more generic method. You can 
>> toggle between them between builds and confirm what things are errors 
>> in implementation instead of errors elsewhere in the code.
>
> Ok agreed, good point.
>
> Woody
>