On Fri, 2005-11-04 at 12:20 +0000, Peter Howkins wrote: > The spec looks good, but does it allow for multiple configurations? I > dunno if you've had a chance to use red squirrel on Windows, but that > allows for the setting up of many different 'machines', eg machines with > differnt OS ROMs, hardware types and hard disc locations.
It could be trivially extended to allow this, I suppose. (Add a --config option, or similar, as many applications have.) > I had thought that the simplest way to achieve this would be to add > command line arguments for various options. <snip> > Then build a small gui app, that matches the host OS in normal apearance, > that lets you choose from lists of options and lets you save complete > 'machines' (set of config options). Or on linux you could just have a set > of shell scripts that launched different machines, or write a program in > GTK (or whatever) This does of course actually mean writing a great deal more code, and having to build two binaries. And it leaves Unix as a bit of a second-class citizen. > Here's a few advantages > > Splits apart the config file management from the main program. Why is this an advantage? All this stuff still has to be written. I would have thought a more logical split would be emulator and GUI/output/input. > Add commandline options for the stuff that is expected for unix progs. Command line options aren't *expected*, and we can still do this anyway (for example, stuff I've done in the past, if you set a configurable option *after* specifying which config file to use, the command line overrided the config file, otherwise it didn't.) > Allows a nice gui frontend on Windows (where that is expected) The current arrangement doesn't disallow for that. What's stopping it is somebody skilled enough to be bothered. > Allows the choice of where to store and the format of the 'machine' > config to be entirely host OS specified. It could still be the registry > on windows or in the 'thingy' on Mac OS X. Same advantage exists with my suggestion. > Doesn't require each OS to impliment extra config file functions. Yes, it does. Even if it's just via Vim editing a shell script. > Backwards compatible with current operation (due to the defaults being > what we currently do) Same advantage exists with my suggestion. Your suggestion also has one serious pitfall: the emulator can't write back to the config file. Which means you can't store the CMOS RAM in it, which is fairly essential if you wanted different machine shapes. And storing it in a separate file is just plain ugly anyway. Some nice ideas though - I'll look into how best to allow multiple configurations nicely, and providing default values for things. But I feel command line options is another issue entirely. -- Rob Kendrick <[EMAIL PROTECTED]> ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ arcem-devel mailing list arcem-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/arcem-devel
