[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-gnubg] Setting default board colour scheme
From: |
Joern Thyssen |
Subject: |
Re: [Bug-gnubg] Setting default board colour scheme |
Date: |
Fri, 13 Dec 2002 08:50:57 +0000 |
User-agent: |
Mutt/1.4i |
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