bug-gnubg
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]