kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

On Thu, Apr 11, 2013 at 04:17:15PM -0400, Wayne Stambaugh wrote:

> This isn't a bad thing unless the pointer to g_colorSettings changes.
> It hides the fact the color settings in Pcbnew are a global variable (it
> seems to me that they should be a member of PCB_EDIT_FRAME or one of the
> classes it is derived from) and prevents the g_colorSettings variable
> from littering the all the objects derived from BOARD_ITEM which I
> believe use to be the case.  The color settings could reside and be

Thanks exactly what I was asking for. It wasn't clear if colours were
intended to be members or globals. This indirection would allow (for
example) different colours in the module editor. If colours were (by
design) common to the whole application then the direct global access
would have been a better choice.

> changed anywhere.  As long as the pointer to them in the BOARD object is
> valid, all is well.  Hopefully this will discourage other developers
> from added more globals in the future.

I have nothing against globals, if the stuff is actually global. For me
the current g_colorSettings is a good decision since colours are set at
the application level. Putting variables in objects just because there
should be no globals is nonsense (except in Java where you have no
choice :D)

-- 
Lorenzo Marcantonio
Logos Srl