kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 04/11/2013 03:17 PM, Wayne Stambaugh wrote:
> On 4/11/2013 2:26 PM, Lorenzo Marcantonio wrote:
>> I'm fixing #1167884 (pretty trivial) and I noticed a curious thing:
>>
>> BOARD has it's own m_colorsSettings, with accessors and simply
>> initialized with a pointer to the global g_colorsSettings. After that
>> it's never changed.
> 
> 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
> 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.
> 
>>
>> Other stuff in pcbnew instead goes directly to the g_colorsSettings.
>>
>> What is the meaning for the BOARD member? If there are plan to (for
>> example) giving customized colors to the module editor/viewer then they
>> should get their own m_colorsSettings member (then in the future it
>> would point maybe somewhere else).
>>
>> Otherwise if colors in pcbnew are truly global, I think that the BOARD
>> member is only confusing the code.


No, I don't agree, since it is behind an interface and only accessors use it.

Its the guy in the stair well walking on his hands, allowed to do weird stuff as long as
it is not public.

The important thing to discuss first is the interface, then we don't be bashful about the
implementation since nobody is allowed to know.

So let's talk about the color interface first, then the implementation will fall out
naturally.

The needed interface is a blend between a layer access interface, plus feature specific
associations (i.e. non-layers, such as "front pads").

Because we are talking about supporting more than one board in the editor *concurrently*
in the foreseeable future, we have to be careful about what is done here on improving the
color "interface".


I think the color interface should be BOARD specific, because when you send someone a
complex board, their favorite KiCad colors, although they may like them because they may
be reminded of their third grade girlfriend, these colors may simply not be able to show
all the features of the board in the same way that you outfitted the board with colors
before you sent it.

If you buy this theory, then the interface should go in the BOARD.  If you want to be
reminded of your third grade girlfriend in any case, then you argue for putting the colors
elsewhere.  I would think that with my scheme (colors in the BOARD), the colors that go
into a *new* board can come from a "user specific" configuration area like now.  And you
put your third grade memories in that config area.  But when loading an existing board,
the colors come in with it.

Then you have to ask, to what extent then are colors bound to layers within the board and
within the board file.

>From where we are, simply copying the colors into the board is easy.  Editing them gets
harder, and that is why we are where we are.  You have to know when editing board colors
vs. global favorites.

Go figure.






>>
>> What do you think of that?
>>
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>