Re: [Alephmodular-devel] CFileDesc landed

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

On Tuesday, February 11, 2003, at 08:52  PM, Woody Zenfell, III wrote:

> Just so you don't think all your text is going to /dev/null or 
> something... I've been reading your notes with interest, and wanted to 
> say it sounds like things are going very well.  Congratulations and 
> keep up the good work :)

Thank you, I must say that the quiet had been getting to me :)


> A couple questions:
>
> Is there a way to change one's mind with the safe-save business?  i.e. 
> can I open a file for writing, do some stuff, then say "oops never 
> mind!" and get rid of the file without it actually going through with 
> the swap?

The swap won't occur if the stream is in a bad state. So the following 
will keep a file from swapping:

	fileref->setstate(std::ios::badbit);

If someone has a pointer to something that says that doing this is a 
bad thing, tm, then I'll try and make more of the COFileRef's interface 
available to the rest of the system. (To the rest of the system, even 
with safe saving, OFileRef is still just viewed as a std::ostream*)

> Also, I know you keep saying file browsing is a platform-specific 
> thing, but... a from-scratch file browser would probably quite benefit 
> from the ability to navigate_up() (and then could browse using your 
> FileDesc stuff directly rather than having to implement a parallel set 
> of routines on the platform).  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.

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.

So, as of the current time, navigate_up is if'def'd out as it would 
need more work, and navigate_sibling is protected. With caveats along 
the lines that its only used by safe save.

You could label me as ambiguous on navigate_up. I'm a little hazy on 
how to best implement its details mac-wise, and it wasn't needed for 
the current line of work.

> What's next?  :)  Whatever it is, looking forward to it...  :)
>
Thanks. :)

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.

-Jeremy Parsons