kicad-developers team mailing list archive

[Maciej Sumiński <maciej.suminski@xxxxxxx>]

On 11/01/2013 01:48 PM, Lorenzo Marcantonio wrote:
> OK, I'm trying to follow the road to isolate GAL layers and pcbnew
> layers. Let's see if it can work:
>
> - pcbnew still uses LAYER_NUM (for layers) and PCB_VISIBLE (for other
>    stuff)
>
> - GAL *doesn't* use LAYER_NUM, because a) it wouldn't work anyway with
>    eeschema in future and b) it extends the range to contain PCB_VISIBLE
>    values (offset at the end of the layers)
>
> - PCB_VISIBLE was extended to handle more things, like the overlay and
>    the netnames; at the moment I don't see problems with that.
>
> I added a GAL_LAYER_NUM type (another enum) to be used in the GAL/View
> stuff. There was already the ITEM_GAL_LAYER macro (not function since it
> needs to 'run' at compile time for initializers) for going from
> PCB_VISIBLE to GAL_LAYER_NUM. Simply added a PCB_GAL_LAYER to do the
> LAYER_NUM to GAL_LAYER_NUM domain cross (little more than a cast,
> actually). Luckily there is (until now) need to do the reverse (which is
> impossible in the general case...).
>
> Aside note: GAL_LAYER_NUM could be a base class and PCB_VISIBLE and
> LAYER_NUM could be subclasses. It seems to me that the IS-A relationship
> holds. However in C++ that would be actually very inconvenient since you
> can't have literal instances... except maybe in C++x1; so I'm keeping
> the enum representation which works and (un)fortunately has an implicit
> conversion to int.
>
> The idea is that all the 'view' stuff shouldn't be contaminated by
> LAYER_NUM to ensure future reuse.

Seems quite interesting. As far I understand - you have already 
introduced the changes? If yes - may I have a look at them?
I was also considering using classes for storing layers information 
(name, visiblity, rendering order, always-on-top, etc), but for the time 
being I would rather not introduce too many changes to the used model.

> First strange thing I found: the ViewGetLayers seems to be a callback
> (added in EDA_ITEM, probably) to interrogate an object and schedule it's
> drawing (or something like that, didn't study the whole trip). The
> returned array seems to be of GAL_LAYER_NUM values (it make sense). The
> fact that LAYER_NUM values are valid and correct GAL_LAYER_NUM values is
> an (handy!) coincidence.

Generally, it was done on purpose. As you already know - some of items 
had to be drawn on a few separate layers (eg. THT pad is drawn on THT 
pad layer, hole is on a different layer and its label is another one). 
We did not want to prepare a totally different set of layers, parallel 
to the one that is already used (as copper layers are perfectly fine for 
drawing items that belong to those), so only a few necessary layers were 
introduced.
As far as I rememember, one of the reasons was the Cairo backend, which 
does not allow (or at least I could not find a sensible way) to move 
freely between layers. The only way to draw is layer by layer, in 
contrary to OpenGL when you can specify Z coordinate.
Besides that, it was necessary for determining which layers have to be 
updated when an item is modified.

> However in ROUTER_PREVIEW_ITEM::ViewGetLayers, the GP_OVERLAY value is
> stored back (the type is PCB_DISPLAY) which interpreted as
> a GAL_LAYER_NUM would go more or less in the via display layers...
> should it be instead ITEM_GAL_LAYER(GP_OVERLAY) or did I miss some trick
> along the way?

Nope, there is no trick - thanks for spotting this, you are quite 
watchful. Good that it works, but it should be 
ITEM_GAL_LAYER(GP_OVERLAY), soon to be changed.

> By the way I find the view machinery most interesting, good work with
> that!