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!
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
