← Back to team overview

kicad-developers team mailing list archive

Re: layer setup


jean-pierre.charras@... wrote:
Dick Hollenbeck a écrit :

jean-pierre. charras@gipsa- lab.inpg. fr <mailto:jean-pierre.charras%40gipsa-lab.inpg.fr> wrote:

Dick Hollenbeck a écrit :

What happened to my nice green copper layers?

I am afraid I was the culprit, but here is the reason:
* the layer order for the inner layers (using the old pcbnew layer
order) was the reverser order the new layer order used in the layer
manager and the layer box.
* So tho match the new layer order I reversed the inner layers order
Matching the layer manager order is important also to avoid
mistakes when selecting layers types (this was mainly my motivation).
* but after doing this, the active layers were located to the bottom
of the window, and, for 2 or 4 layers board and not visible without
This minor problem also could create mistakes because when changing
layers count from 2 to 4, nothing seems happen.
* Easy workaround: hide not active layers (this is what I do), so only
really active layers are shown, and no need to scrolling the layer list.
Alas! calling wxPanel->Show( false) or wxPanel->Show( true) to

items *crashes* pcbnew (I do not know why), at least under Windows,
and I was unable to solve this problem.
So I made an ugly change: remove the wxPanels having your nice green
copper layers background.
* Of course your original file is not removed: this is
"dialog_layers_ setup_base_ previous_ version.fbp. unused".

Maybe we can support the old code and new code under two sets of file
names. That means restoring the *.cpp files as before. This way you
only have to make an edit to your CMakeLists.txt file to select the new
set while you iron out our daily Windows problems.

I now use the original dialog_layers_ setup_base.fbp without problem.
(I am thinking I had a bug when I tested my code)
Just added 2 define to select the way the inner copper layers are displayed, at compilation time. (One relative to the inners layers order, and one to show or hide unused inner copper layers)
There is very few new code (only few lines) in dialog_layers_ setup.cpp

Each option has advantage and drawback, and is mainly a matter of taste.
Try them.

I had orginally assumed that the layer flipping was going to take place
sooner than it has. And that due to scarce resources we would not have
the time to re-do this dialog over and over again. I was leading a
moving target. The target did not move, and I overshot it. So we can
take another shot, or we can move the target.

All I can say is that I spent a LOT of time on that dialog, and don't
want to see that time go to waste. This would be intensely de-motivating.

You are finding out now how much time I spent on it. :)

I easily believe it.
But your code is fully welcome and used. Nothing is removed.

Is there a FINAL solution ? No, there are two solutions, one for each
layer order, now and future.

I hate to say it, but what I learned from this dialog I applied later to
the LAYER_WIDGET, and one of those things I learned was that using
wxFormBuilder was not practical. Having a concise, TABLE driven data
definition proved to be easier. You have used the LAYER_WIDGET: :ROW()
structure, and see how powerful it has been.

The danger in adding and removing layer rows on the fly is that the user
may spend time editing names, if he accidentally changes the layer
count, he (meaning I) do not want to have to re-enter those names once I
increase the layer count back to what they should be.

when using HIDE_INACTIVE_LAYERS option, widgets are just hidden, not removed, therefore widgets data is not lost.

One thought, not a request, just a thought, is to go table driven. In
the mean time we might want to restore the old code as a default and
plan on a source file name change for the new code.


I fully agree, for this kind of dialog, wxFormBuilder is not practical.
When extending the maximum copper layer count, using table will be mandatory. Mixing wxFormBuilder to create the very basic dialog, and adding widgets using tables could be a good way.
Enhancement code will be welcome but we have time to do that.
By the way, a coworker (aboard designer) is starting a large board (16 coppers layers expected), using a 1200 pins BGA package.
This will be an interesting test bench for Pcbnew.

For my BGA I defined through hole pads as part of the footprint, next to the ball landings. You have to mess with the through hole pad settings to turn them into "via" functionality. This way the vias can be precisely located in advance and they are part of a predetermined net. Downside is you end up with a few more than you need, but they can be deleted using the footprint instantiation editor.

And of course freeroute to do the routing, manually.

These are 2 things which might provide him a shorter effort.

Sounds like you have been selling the software, hopefully he will not ask for his money back.


Follow ups