← Back to team overview

kicad-developers team mailing list archive

Re: m_colorsSettings in BOARD

 

On 4/12/2013 1:17 AM, Lorenzo Marcantonio wrote:
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)

I don't have anything against globals when they make sense which is very rarely. In the case of the color settings, they are manipulated and set and effectively owned by PCB_EDIT_FRAME which is probably were they should live. Everywhere else, they are only read by objects to display the user defined color. By making them a global variable, it allowed them to abused and used directly throughout the low level object code causing an huge mess.


References