Hi Jon,
I would not mind changing the current way of handling the GAL layers.
They have not been put in the default layers enum, because the dedicated
GAL layers are virtual, in the sense they are only to display certain
objects (e.g. net names). I did not want to clutter the real layers set,
so t
This seem reasonable to me. I'm not sure why the gal layer enums would
be different from the actual board layer enums. You would have to ask
the author of gal layer enums as to why they are different. You may
want to wait until that person comments on it.
Cheers,
Wayne
On 3/12/2017 2:09 PM, J
It would be very nice if we could have a totally standalone (in terms of
constants used, etc) legacy loader that translates everything to the
constants used in the new code, so we didn't always have to tread so
carefully...
On Sun, Mar 12, 2017 at 02:06:01PM -0400, Wayne Stambaugh wrote:
> I canno
I would keep the enum values the same for the board layers. The GAL layer
enum values would have to change. I would just move them all to be in one
enum, and set a high starting value for the GAL layers. That way, there is
only one structure and its easy to add layers that are needed for specific
a
I cannot speak about the GAL enums but I can tell you that if you muck
up the legacy layer enums, you will almost surely break loading really
old board files. I would proceed with extreme caution here.
On 3/12/2017 12:25 PM, Jon Evans wrote:
> Hi,
>
> Can anyone explain if there is a reason why
Hi,
Can anyone explain if there is a reason why the layer definition enums are
done in the way they are?
Using multiple enums for the "normal" layers and the GAL extra layers is
complicating the code, especially now that I am using the GAL layers for
GerbView, and also working on a color theme ma
6 matches
Mail list logo
