RE: [Bug-gnubg] Setting default board colour scheme

[Ian Shaw]

> From: Joern Thyssen [mailto:address@hidden
> 
> On Fri, Dec 13, 2002 at 10:15:27AM -0000, Ian Shaw wrote
> > 
> > 
> > > On Fri, Dec 13, 2002 at 09:37:59AM -0000, Ian Shaw wrote
> > > > I wrote in another post that it would be nice to be 
> able to save the
> > > > current colour scheme as the default without disrupting all 
> > > the other
> > > > default settings. It was pointed out that .gnubgautorc stored
> > > > everything when do Save Settings.
> > > > 
> > > > Now that \.gnubg\boards.xml exists and allows the user to save
> > > > settings, would it be possible to save the default 
> board in here,
> > > > instead of in .gnbgautorc? You could add a button to 
> the popup "Save
> > > > as default" and overwrite the "Default" entry in boards.xml.
> > > 
> > > I'm not sure what you mean.
> > > 
> > > If you delete your settings file .gnubgautorc gnubg will 
> revert to 
> > > some hard-coded board settings -- it won't use the 
> "default" settings
> > > from the board.xml file! Maybe that's confusing you?!
> > > 
> > I realise that gnubg currently loads board settings from 
> .gnubgautorc,
> > and doesn't use Default settings from \.gnubg\boards.xml. I'm
> > suggesting that it should. Then there would be no need to 
> store board
> > settings in .gnubgautorc. This would allow users to change their
> > preferred board setting without disrupting any other stored 
> settings. 
> > 
> > At present, if you use a new board and then Save Settings, all your
> > default analysis, rollout and eval settings also get overwritten, if
> > you have modified them during the session. I think this is
> > undesirable.
> 
> The problem is that you can extend these arguments: we want a seperate
> file for evaluation settings, and a seperate one for rollout settings,
> and a separate one for paths etc. We may end up with tens 
> or hundreds
> of different settings files, so setting X can be stored 
> independently from
> setting Y.
> 
True; it would open up a whole can of worms, which you probably want to avoid 
at this time. OTOH, this is how most Windows programs operate, so a lot of 
users are used to it. I don't see any need to create hundreds of different 
files. You could retain one file, but only edit the relevant entries. This 
seems to be the case with many Windows programs that use an .ini file. 

It should be noted that one of the main differences is that in the Windows 
world, the .ini file is automatically updated when the setting is changed. I.e. 
the setting applies thenceforward; not just for the session. There is therefore 
no need for a Save Settings at all.

This may or may not be desirable for gnubg, nor do I have any idea about the 
Unix world standard. I suppose this is a matter of design philosophy.

--Ian