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

[Nardy Pillards]

----- Original Message -----
From: "Joern Thyssen" <address@hidden>
To: "Ian Shaw" <address@hidden>
Cc: "GnuBg Bug (E-mail)" <address@hidden>
Sent: Friday, December 13, 2002 9:50 AM
Subject: Re: [Bug-gnubg] Setting default board colour scheme


> On Fri, Dec 13, 2002 at 10:15:27AM -0000, Ian Shaw wrote
> >
> >
> > > -----Original Message-----
> > > From: Joern Thyssen [mailto:address@hidden
> > > Sent: 13 December 2002 08:15
> > > To: Ian Shaw
> > > Cc: GnuBg Bug (E-mail)
> > > Subject: Re: [Bug-gnubg] Setting default board colour scheme
> > >
> > >
> > > 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 etc. We may end up with tens or hundreds
> of different settings files, so setting X can be stored independently from
> setting Y.
>
> Jørn
>
Yes. I agree with this.
Yet: there is already a seperate boards.xml and a .\gnubg\boards.xml (if
user saved own design)

But... I agree

Nardy