Re: [Kicad-developers] Lots of compile errors after recent source pull

[pjmonty]

 Very hard to find the errors among the epic amount of long warning messages.  
The full make would go a long time, then fail.  I'd start it again, it would go 
for some time, then fail again. Lather. Rinse. 
Repeat.  

Finally saw these error messages:
C:/msys64/mingw64/include/c++/10.1.0/system_error:278:10: note: 
'std::error_condition' defined as 'struct' here
  278 |   struct error_condition
  |  ^~~
In file included from C:/msys64/mingw64/x86_64-w64-mingw32/include/windows.h:71,
 from C:/msys64/mingw64/include/wx-3.0/wx/msw/wrapwin.h:65,
 from C:/msys64/mingw64/include/wx-3.0/wx/msw/init.h:19,
 from C:/msys64/mingw64/include/wx-3.0/wx/init.h:58,
 from C:/msys64/mingw64/include/wx-3.0/wx/app.h:23,
 from C:/msys64/mingw64/include/wx-3.0/wx/wx.h:25,
 from C:/msys64/home/kicad-master/kicad/include/fctsys.h:28,
 from 
C:/msys64/home/kicad-master/kicad/eeschema/dialogs/dialog_annotate.cpp:31:
C:/msys64/home/kicad-master/kicad/eeschema/erc_settings.h:70:5: error: expected 
identifier before numeric constant
   70 | ERROR,
  | ^
C:/msys64/home/kicad-master/kicad/eeschema/erc_settings.h:70:5: error: expected 
'}' before numeric constant
In file included from 
C:/msys64/home/kicad-master/kicad/eeschema/sch_edit_frame.h:40,
 from 
C:/msys64/home/kicad-master/kicad/eeschema/dialogs/dialog_annotate.cpp:32:
C:/msys64/home/kicad-master/kicad/eeschema/erc_settings.h:67:1: note: to match 
this '{'
   67 | {
  | ^
In file included from C:/msys64/mingw64/x86_64-w64-mingw32/include/windows.h:71,
 from C:/msys64/mingw64/include/wx-3.0/wx/msw/wrapwin.h:65,
 from C:/msys64/mingw64/include/wx-3.0/wx/msw/init.h:19,
 from C:/msys64/mingw64/include/wx-3.0/wx/init.h:58,
 from C:/msys64/mingw64/include/wx-3.0/wx/app.h:23,
 from C:/msys64/mingw64/include/wx-3.0/wx/wx.h:25,
 from C:/msys64/home/kicad-master/kicad/include/fctsys.h:28,
 from 
C:/msys64/home/kicad-master/kicad/eeschema/dialogs/dialog_annotate.cpp:31:
C:/msys64/home/kicad-master/kicad/eeschema/erc_settings.h:70:5: error: expected 
unqualified-id before numeric constant
   70 | ERROR,
  | ^
In file included from 
C:/msys64/home/kicad-master/kicad/eeschema/sch_edit_frame.h:40,
 from 
C:/msys64/home/kicad-master/kicad/eeschema/dialogs/dialog_annotate.cpp:32:
C:/msys64/home/kicad-master/kicad/eeschema/erc_settings.h:72:1: error: expected 
declaration before '}' token
   72 | };
  | ^

 
 
-Original Message-
To: ian.s.mciner...@ieee.org 
Cc: kicad-developers@lists.launchpad.net 
Sent: Sat, Jul 4, 2020 6:45 pm
Subject: Re: [Kicad-developers] Lots of compile errors after recent source pull

 Other headers as well.  
 
 C:/msys64/mingw64/include/c++/10.1.0/bits/localefwd.h:125:9: note: replace the 
class-key with 'struct'
  125 |   class ctype_base;

C:/msys64/mingw64/include/c++/10.1.0/x86_64-w64-mingw32/bits/ctype_base.h:42:10:
 note: 'std::ctype_base' defined as 'struct' here
   42 |   struct ctype_base
  |  ^~

C:/msys64/mingw64/include/c++/10.1.0/bits/valarray_array.h:396:12: note: 
'std::_Array<_Tp>' defined as 'struct' here
  396 | struct _Array

...as well as the one I originally showed...
C:/msys64/mingw64/include/c++/10.1.0/system_error:54:9: note: replace the 
class-key with 'struct'
   54 |   class error_code;

There may be more, but these are the ones I see repeating over and over.  I 
tried to do a full build a couple of days ago, and the the build crapped out 
part way through.  I don't recall the specific error message, but I can try 
again and see if it dies.  If so, I'll post the info.


-Original Message-
From: Ian McInerney 
To: pjmo...@csi.com
Cc: kicad-developers@lists.launchpad.net 
Sent: Sat, Jul 4, 2020 3:15 pm
Subject: Re: [Kicad-developers] Lots of compile errors after recent source pull

That would probably be because I enabled the warning for "-Wmismatched-tags" on 
clang/GCC. This shouldn't be an error though, only a warning. It warns about 
declaring things class/struct inconsistently (on MSVC builds this can cause 
problems, so I enabled this warning to ensure we don't have issues with this 
since we are starting to have more people use MSVC). It appears that the system 
headers in GCC don't follow that standard unfortunately, but usually warnings 
from inside system headers are ignored (apparently on the C++ headers on my 
machine it is also mismatched but I don't see all the warnings when building 
with Clang). These are supposed to be hidden when the include directories are 
system include directories though.
Do you see this for other headers, or is it just this one header? I wouldn't 
mind forwarding this upstream to cleanup their headers.
-Ian

Re: [Kicad-developers] Lots of compile errors after recent source pull

[pjmonty]

 Other headers as well.  
 
 C:/msys64/mingw64/include/c++/10.1.0/bits/localefwd.h:125:9: note: replace the 
class-key with 'struct'
  125 |   class ctype_base;

C:/msys64/mingw64/include/c++/10.1.0/x86_64-w64-mingw32/bits/ctype_base.h:42:10:
 note: 'std::ctype_base' defined as 'struct' here
   42 |   struct ctype_base
  |  ^~

C:/msys64/mingw64/include/c++/10.1.0/bits/valarray_array.h:396:12: note: 
'std::_Array<_Tp>' defined as 'struct' here
  396 | struct _Array

...as well as the one I originally showed...
C:/msys64/mingw64/include/c++/10.1.0/system_error:54:9: note: replace the 
class-key with 'struct'
   54 |   class error_code;

There may be more, but these are the ones I see repeating over and over.  I 
tried to do a full build a couple of days ago, and the the build crapped out 
part way through.  I don't recall the specific error message, but I can try 
again and see if it dies.  If so, I'll post the info.


-Original Message-
From: Ian McInerney 
To: pjmo...@csi.com
Cc: kicad-developers@lists.launchpad.net 
Sent: Sat, Jul 4, 2020 3:15 pm
Subject: Re: [Kicad-developers] Lots of compile errors after recent source pull

That would probably be because I enabled the warning for "-Wmismatched-tags" on 
clang/GCC. This shouldn't be an error though, only a warning. It warns about 
declaring things class/struct inconsistently (on MSVC builds this can cause 
problems, so I enabled this warning to ensure we don't have issues with this 
since we are starting to have more people use MSVC). It appears that the system 
headers in GCC don't follow that standard unfortunately, but usually warnings 
from inside system headers are ignored (apparently on the C++ headers on my 
machine it is also mismatched but I don't see all the warnings when building 
with Clang). These are supposed to be hidden when the include directories are 
system include directories though.
Do you see this for other headers, or is it just this one header? I wouldn't 
mind forwarding this upstream to cleanup their headers.
-Ian

___
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

Re: [Kicad-developers] Lots of compile errors after recent source pull

[Ian McInerney]

That would probably be because I enabled the warning for
"-Wmismatched-tags" on clang/GCC. This shouldn't be an error though, only a
warning. It warns about declaring things class/struct inconsistently (on
MSVC builds this can cause problems, so I enabled this warning to ensure we
don't have issues with this since we are starting to have more people
use MSVC). It appears that the system headers in GCC don't follow that
standard unfortunately, but usually warnings from inside system headers are
ignored (apparently on the C++ headers on my machine it is also mismatched
but I don't see all the warnings when building with Clang). These are
supposed to be hidden when the include directories are system include
directories though.

Do you see this for other headers, or is it just this one header? I
wouldn't mind forwarding this upstream to cleanup their headers.

-Ian

On Sat, Jul 4, 2020 at 11:00 PM  wrote:

> I did a pull yesterday and suddenly I'm getting just a ton of errors
> during compiling.  I'm on Windows 10 under minGW.  My setup was working
> great up until this recent pull, and then everything fell apart.
>
> The problems seem to begin when compiling the "common" directory,
> specifically when it hits "gal".  This is a sample of gcc's output when the
> problem first starts:
>
> Scanning dependencies of target gal
> [ 60%] Building CXX object common/CMakeFiles/gal.dir/basic_gal.cpp.obj
> [ 60%] Building CXX object common/CMakeFiles/gal.dir/draw_panel_gal.cpp.obj
> [ 60%] Building CXX object common/CMakeFiles/gal.dir/gl_context_mgr.cpp.obj
> [ 60%] Building CXX object common/CMakeFiles/gal.dir/newstroke_font.cpp.obj
> [ 60%] Building CXX object common/CMakeFiles/gal.dir/painter.cpp.obj
> In file included from
> C:/msys64/mingw64/include/c++/10.1.0/bits/ios_base.h:46,
>  from C:/msys64/mingw64/include/c++/10.1.0/streambuf:41,
>  from
> C:/msys64/mingw64/include/c++/10.1.0/bits/streambuf_iterator.h:35,
>  from C:/msys64/mingw64/include/c++/10.1.0/iterator:66,
>  from C:/msys64/mingw64/include/wx-3.0/wx/arrstr.h:116,
>  from C:/msys64/mingw64/include/wx-3.0/wx/filefn.h:15,
>  from C:/msys64/mingw64/include/wx-3.0/wx/utils.h:20,
>  from C:/msys64/mingw64/include/wx-3.0/wx/cursor.h:69,
>  from C:/msys64/mingw64/include/wx-3.0/wx/event.h:21,
>  from C:/msys64/mingw64/include/wx-3.0/wx/app.h:19,
>  from C:/msys64/mingw64/include/wx-3.0/wx/glcanvas.h:18,
>  from
> C:/msys64/home/kicad-master/kicad/include/gl_context_mgr.h:28,
>  from
> C:/msys64/home/kicad-master/kicad/common/gl_context_mgr.cpp:26:
> C:/msys64/mingw64/include/c++/10.1.0/system_error:54:9: note: replace the
> class-key with 'struct'
>54 |   class error_code;
>   | ^~
> C:/msys64/mingw64/include/c++/10.1.0/system_error:180:10: note:
> 'std::error_code' defined as 'struct' here
>   180 |   struct error_code
>   |  ^~
> C:/msys64/mingw64/include/c++/10.1.0/system_error:55:9: note: replace the
> class-key with 'struct'
>55 |   class error_condition;
>   | ^~~
> C:/msys64/mingw64/include/c++/10.1.0/system_error:278:10: note:
> 'std::error_condition' defined as 'struct' here
>   278 |   struct error_condition
>
> It goes on and on and on like this with all these errors about "struct
> error code" and "class error code" and the like.
>
> I have a local branch that is only up to date with
> 2cfd6ba978caee591a6ae2a1f920d96c31717f2f from July 2, and I was able just
> now to compile it again without any errors.
>
> I created a brand new clone repo of the latest commit  (
> 9e669db5b4bdeff7f057614a6c93067f7a8c7024 ) and I still get the same compile
> errors.
>
> Has anyone else noticed this?  Is this a problem on my end or is there a
> bad push that started this problem somewhere between July 2 and today?
> ___
> 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
>
___
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

[Kicad-developers] Lots of compile errors after recent source pull

[pjmonty]

I did a pull yesterday and suddenly I'm getting just a ton of errors during 
compiling.  I'm on Windows 10 under minGW.  My setup was working great up until 
this recent pull, and then everything fell apart.
The problems seem to begin when compiling the "common" directory, specifically 
when it hits "gal".  This is a sample of gcc's output when the problem first 
starts:
Scanning dependencies of target gal
[ 60%] Building CXX object common/CMakeFiles/gal.dir/basic_gal.cpp.obj
[ 60%] Building CXX object common/CMakeFiles/gal.dir/draw_panel_gal.cpp.obj
[ 60%] Building CXX object common/CMakeFiles/gal.dir/gl_context_mgr.cpp.obj
[ 60%] Building CXX object common/CMakeFiles/gal.dir/newstroke_font.cpp.obj
[ 60%] Building CXX object common/CMakeFiles/gal.dir/painter.cpp.obj
In file included from C:/msys64/mingw64/include/c++/10.1.0/bits/ios_base.h:46,
 from C:/msys64/mingw64/include/c++/10.1.0/streambuf:41,
 from 
C:/msys64/mingw64/include/c++/10.1.0/bits/streambuf_iterator.h:35,
 from C:/msys64/mingw64/include/c++/10.1.0/iterator:66,
 from C:/msys64/mingw64/include/wx-3.0/wx/arrstr.h:116,
 from C:/msys64/mingw64/include/wx-3.0/wx/filefn.h:15,
 from C:/msys64/mingw64/include/wx-3.0/wx/utils.h:20,
 from C:/msys64/mingw64/include/wx-3.0/wx/cursor.h:69,
 from C:/msys64/mingw64/include/wx-3.0/wx/event.h:21,
 from C:/msys64/mingw64/include/wx-3.0/wx/app.h:19,
 from C:/msys64/mingw64/include/wx-3.0/wx/glcanvas.h:18,
 from 
C:/msys64/home/kicad-master/kicad/include/gl_context_mgr.h:28,
 from 
C:/msys64/home/kicad-master/kicad/common/gl_context_mgr.cpp:26:
C:/msys64/mingw64/include/c++/10.1.0/system_error:54:9: note: replace the 
class-key with 'struct'
   54 |   class error_code;
  | ^~
C:/msys64/mingw64/include/c++/10.1.0/system_error:180:10: note: 
'std::error_code' defined as 'struct' here
  180 |   struct error_code
  |  ^~
C:/msys64/mingw64/include/c++/10.1.0/system_error:55:9: note: replace the 
class-key with 'struct'
   55 |   class error_condition;
  | ^~~
C:/msys64/mingw64/include/c++/10.1.0/system_error:278:10: note: 
'std::error_condition' defined as 'struct' here
  278 |   struct error_condition
It goes on and on and on like this with all these errors about "struct error 
code" and "class error code" and the like.

I have a local branch that is only up to date with 
2cfd6ba978caee591a6ae2a1f920d96c31717f2f from July 2, and I was able just now 
to compile it again without any errors.  

I created a brand new clone repo of the latest commit  ( 
9e669db5b4bdeff7f057614a6c93067f7a8c7024 ) and I still get the same compile 
errors.

Has anyone else noticed this?  Is this a problem on my end or is there a bad 
push that started this problem somewhere between July 2 and today? ___
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

Re: [Kicad-developers] Improve detection of silkscreen over vias

[Greg Smith]

One way to do this is through Python. I had developed a few years ago (for 
KiCAD 4.0.x) KiPadCheck[1] to run some additional basic checks on a board. 
Included were some silk screen checks. I haven’t updated it in a while, but it 
might be an option to consider Python to cover some areas prior to the DRC 
overhaul is complete.

[1] https://github.com/HiGregSmith/KiPadCheck

Greg S.

> On Jul 4, 2020, at 10:56 AM, Jon Evans  wrote:
> 
> I think 1 and 2 (I assume you mean the OpenGL renderer of the 3D
> viewer) are good ways forward for the short term.
> 
> The DRC system is in a period of heavy change right now so it's
> probably best to wait until the dust settles a bit before adding new
> checks to it.
> 
> Best,
> Jon
> 
>> On Sat, Jul 4, 2020 at 11:31 AM Joshua Redstone  wrote:
>> 
>> Hi,
>> I was thinking of looking into making KiCad better at alerting when 
>> silkscreen markings are over a via (since it won't show up when fab'd), and 
>> was wondering where might be a good place to start.
>> 
>> I also heard from one fab to not silkscreen over annular rings, so was 
>> thinking of adding a config option to filter those intersections out as well.
>> 
>> Some options, perhaps in increasing order of difficulty:
>> 
>> 1. Add an option to the raytracer to clip silkscreen over annular rings (it 
>> already can filter out silkscreen over vias).
>> 
>> 2. Improve the OpenGL renderer to clip text over vias & annular rings.
>> 
>> 3. Add a DRC check to detect silkscreen intersecting vias / annular rings.
>> 
>> Any thoughts or recommendations?
>> 
>> -Josh
>> 
>> ___
>> 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
> 
> ___
> 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
___
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

Re: [Kicad-developers] Assumptions about EDA_DRAW_FRAME in pcbnew

[Wayne Stambaugh]

On 7/3/20 7:31 PM, Reece R. Pollack wrote:
> On 7/3/20 5:42 PM, Jeff Young wrote:
>> Hi Reece,
>>
>>> On 3 Jul 2020, at 21:32, Reece R. Pollack >> > wrote:
>>>
>>> Noting that the PCB_BASE_FRAME class is derived from the
>>> EDA_DRAW_FRAME class, is it acceptable to assume that the
>>> EDA_DRAW_FRAME pointer parameters passed to functions in Pcbnew
>>> classes are actually pointers to a PCB_BASE_FRAME?
>>
>> Yes, but it would be considered bad practice.
> 
> I would argue that it could easily be defined that code in the pcbnew
> directory is dealing with a PCB_BASE_FRAME rather than an
> EDA_DRAW_FRAME. Common code should not make that assumption, of course,
> and would not use anything beyond the base class.

Why not just provide a virtual method in the EDA_DRAW_FRAME and override
the method in the derived frame objects to do implement the frame
specific behavior?  This way you don't have to care about the draw frame
type

> 
>>>
>>> Specifically:
>>>
>>>   * The UNIT_BINDER class constructor
>>>   * The classes implementing the GetMsgPanelInfo function
>>>   * The classes implementing the GetSelectMenuText function
>>>
>>> The reason I'm asking is that to implement origin transforms these
>>> functions need access to the user's display option that chooses the
>>> display origin. This needs access to a function defined in the
>>> PCB_BASE_FRAME class. I can make that a common function defined in
>>> EDU_DRAW_FRAME and overridden in PCB_BASE_FRAME, or the code needs to
>>> know that parameter is really a pointer to a PCB_BASE_FRAME object.
>>>
>> Ask yourself this: is there anything PCB-specific about a settable
>> origin?  Is there any reason a settable origin wouldn’t also be
>> useful, say, a schematic?  If the answer is “no”, then you should push
>> the origin (along with its getters and setters) down in to EDA_DRAW_FRAME.
> 
> My submission last year was intended to allow any or all of the KiCad
> subsystems (eeschema, pcbnew, gerbview, etc.) make use of origin
> transforms. Gerbview could benefit, because if you set the place and
> drill origin to the lower left of you design when you generate Gerbers,
> Gerbview displays the page border below the displayed board. I'd thought
> about how to do this in eeschema, considering an origin at any of the
> four corners or at the aux origin (which is defined in eeschema but is
> not settable). But I did a full implementation on pcbnew because that
> was what I felt really needed it.That  implementation added a parameter
> to the functions I mentioned above, which resulted in the eeschema
> functions also having that parameter even though they didn't use it.
> 
> When Wayne sent out his last call for comments before he merged the
> changes, Seth complained that since I didn't implement support in
> eeschema then these changes should not affect any code in the eeschema
> directory. His suggestion was to use function overloading, but that
> would result in having two interfaces visible in the both eeschema and
> pcbnew, one that worked in that context and one that didn't. You
> wouldn't know that the code called the wrong function until you noticed
> broken behavior. I don't consider that an acceptable situation just to
> avoid a trivial parameter list change.
> 
> My approach this year is that code in the pcbnew directory knows it's
> dealing with a PCB_BASE_FRAME because it's PCB-specific code in the
> first place. Then it's easy to access the PCB-specific interfaces and
> data. Rather than changing the UNIT_BINDER class I've implemented a
> PCB_UNIT_BINDER class derived from UNIT_BINDER. It knows that it's
> getting a PCB_BASE_FRAME rather than an EDA_DRAW_FRAME, and passes that
> to the base class constructor. It's more tricky with the functions that
> are called indirectly through the EDA_DRAW_FRAME, such as
> GetMsgPanelInfo and GetSelectMenuText. The implementations are specific
> to pcbnew and live in the pcbnew directory.
> 
> I can do it with dynamic casts, but I'm an embedded systems guy and I
> hate to waste CPU cycles checking things that are defined to be true.
> And dynamic_cast is slow: my tests of the Icarus Verilog simulator
> appear to show VVP spends about 20% of its CPU cycles just resolving
> dynamic casts.
> 
>> If this really is PCB-specific, then you can either push just the
>> origin getters/setters down into EDA_DRAW_FRAME and override them in
>> PCB_BASE_FRAME, or do a dynamic_cast to PCB_BASE_FRAME and if non-null
>> call the getters/setters.
> 
> I believe there will need to be subsystem-specific implementations of
> portions of the origin transform code, based on what display options we
> offer to the user. However, I think a lot of the interfaces can be
> common. I'm willing to do either a PCB-only version or one that has
> support for pcbnew and latent support for the other subsystems. What I'm
> not willing to do is invest a lot of effort, only for someone to veto it
> at the last minute over a stylistic 

Re: [Kicad-developers] Improve detection of silkscreen over vias

[Jon Evans]

I think 1 and 2 (I assume you mean the OpenGL renderer of the 3D
viewer) are good ways forward for the short term.

The DRC system is in a period of heavy change right now so it's
probably best to wait until the dust settles a bit before adding new
checks to it.

Best,
Jon

On Sat, Jul 4, 2020 at 11:31 AM Joshua Redstone  wrote:
>
> Hi,
> I was thinking of looking into making KiCad better at alerting when 
> silkscreen markings are over a via (since it won't show up when fab'd), and 
> was wondering where might be a good place to start.
>
> I also heard from one fab to not silkscreen over annular rings, so was 
> thinking of adding a config option to filter those intersections out as well.
>
> Some options, perhaps in increasing order of difficulty:
>
> 1. Add an option to the raytracer to clip silkscreen over annular rings (it 
> already can filter out silkscreen over vias).
>
> 2. Improve the OpenGL renderer to clip text over vias & annular rings.
>
> 3. Add a DRC check to detect silkscreen intersecting vias / annular rings.
>
> Any thoughts or recommendations?
>
> -Josh
>
> ___
> 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

___
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

[Kicad-developers] Improve detection of silkscreen over vias

[Joshua Redstone]

Hi,
I was thinking of looking into making KiCad better at alerting when
silkscreen markings are over a via (since it won't show up when fab'd), and
was wondering where might be a good place to start.

I also heard from one fab to not silkscreen over annular rings, so was
thinking of adding a config option to filter those intersections out as
well.

Some options, perhaps in increasing order of difficulty:

1. Add an option to the raytracer to clip silkscreen over annular rings (it
already can filter out silkscreen over vias).

2. Improve the OpenGL renderer to clip text over vias & annular rings.

3. Add a DRC check to detect silkscreen intersecting vias / annular rings.

Any thoughts or recommendations?

-Josh
___
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