[Scummvm-devel] 0.7.0 release schedule

[Max Horn]

Am 05.12.2004 um 19:04 schrieb Jerome Fisher:

> Max Horn wrote:
>
>> Things to do till 2004-12-11 (next Saturday):
>> - get any last "major" changes in (only stuff you consider important)
>
> I consider this important: Doing something about the MT-32 waveform 
> cache being saved in the current directory. We could do this properly 
> (using directory IDs in File as discussed), or we could hack something 
> up. I got the impression that you wanted to do the File changes, but 
> I'm happy to do this if we go the "proper" route.

I am not yet sure that "directory IDs" are really the way to go. I did 
a prototype implementation over here, and there were really only two 
uses for it in the whole code base: the MT32 waveform cache, and the 
config file location.

Determining the proper config file location can easily be encapsulated 
into a function. I am aware that this might be not ideal for PalmOS, 
Dreamcast, maybe other systems; however, I am reluctant to design a 
solution for their hypothetical problems without having talked to the 
resp. maintainers (and before knowing what the problem is, exactly ;-).

Determining the waveform cache location is something which doesn't 
interest those two system anyway, they have not nearly enough CPU power 
-- right now, it's only of concern to high end systems, all running an 
OS which has paths.
For those systems, the waveform cache should be stored at the global 
extrapath, if any is specified; if none is specified, we have multiple 
choices:
  * something OS specific: e.g. on Mac OS X, "~/Application 
Support/ScummVM";
    not sure what that could be on a unix system (this approach is 
problematic on unix anyway,
    since normal users tend not to have write access to stuff outside 
their home dir)
  * the (global) savepath
  * the current dir
  * the ScummVM app dir
  * the extrapath of the current game target, if any
  * the "path" of the current game target"

It's not immediately clear which one is best, though. We'll have to 
pick one and live with that.
But note that this choice and the implementation of it, can easily be 
done w/o touching the File class.

I'd rather not add directory IDs at this point, because I don't exactly 
see them solving any actual problems, and as for the hypothetical 
problems they might solve: I don't like jumping for one out of several 
possible solutions w/o knowing more about the actual real problem (e.g. 
for Dreamcast/PalmOS, it might be more fitting to offer a File 
*OSystem::getConfigFile() method, which could even return an instance 
of a subclass of File).


Cheers,

Max