Re: [Kicad-developers] Pcbnew file format

[hauptmech]

Not requiring DR/DRC is appreciated.

Netclasses don't work with my designs on a fundamental level and if 
there were not a way I could ignore them, I would not be able to use 
KiCAD. Likewise the new interactive router which spends most of its time 
in Highlight Collisions mode with Allow DRC Violations. I use it 
normally when I can, but that's not very often.


The knowledge of the kicad developers of leading edge and specialist 
board design has consistently been limited and if you bake in that 
limited knowledge into DR/DRC with no fallback, you will shoot some 
users in the foot.


It doesn't need to be the old system but it does need to be free of 
assumptions about what is acceptable data for the manufacturer and what 
is acceptable practice for the designer.



On 5/07/2019 11:45 AM, Jeff Young wrote:

Hi Seth,

I was thinking about a similar issue which is that we probably can’t require 
users to move to the new DR system (as it will be considerably more technical). 
 So perhaps using the old system as defaults which can be overridden by the new 
makes sense.

Cheers,
Jeff.



On 4 Jul 2019, at 22:40, Seth Hillbrand  wrote:

Hi Jeff-

Ideally, I'd like to find an option that doesn't need to move twice during v6.  
Toward that goal, what if we moved edge_clearance to the defaults section?  
Until we implement the design rules and/or polygon-specific clearance, it 
simply controls everything.  Once we integrate the new features, they are 
allowed to override the default.

Thoughts?
-Seth

On 2019-07-04 12:07, Jeff Young wrote:

Looking through our current set of board setup properties, only
solder_mask_min_width would join edge_clearance in a design_rules
section.
Most of the other properties are either most-recently-used values
(zone_clearance, via_size, etc.) or true DRC values (uvias_allowed,
trace_min, etc.).
The outlier is max_error, which is mostly a performance vs beauty
trade-off, but _does_ affect the generated board.
So,
1) leave solder_mask_min_width and edge_clearance in setup for now
2) create a design_rules section for solder_mask_min_width and
edge_clearance
3) leave edge_clearance in the project file for now
I think I’d vote for (1) simply because I don’t know how (2) will
play with Jon’s stuff.  But the only one I don’t like is (3).
Cheers,
Jeff.

On 4 Jul 2019, at 15:42, Seth Hillbrand  wrote:
On 2019-07-04 09:24, Jeff Young wrote:
Since this is DRC, can we keep it in its current place until the DRC
manager goes in
Well, there’s DRC and there’s DR.  The other options really
control
only what is *checked*, whereas this one controls stuff *on* the
board.  Granted a lot of Jon’s rules will also fit into the DR
camp,
but I feel a little more reticent to move this one out.
Thoughts?
Jeff.

That's a valid point.  Ideally, I'd like to see this in a
"DesignRules" section.  Different manufacturers will have different
requirements here, so the DRC/DFM import would need to modify this
value.  The check also needs to allow separate values for internal vs.
external layers.
If we want to separate the generation from the checking, we might want
to put this setting in the zone parameters.  In which case, we might
use a global default setting that is used for new zones.
-Seth


___
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] Pcbnew file format

[Jeff Young]

Hi Seth,

I was thinking about a similar issue which is that we probably can’t require 
users to move to the new DR system (as it will be considerably more technical). 
 So perhaps using the old system as defaults which can be overridden by the new 
makes sense.

Cheers,
Jeff.


> On 4 Jul 2019, at 22:40, Seth Hillbrand  wrote:
> 
> Hi Jeff-
> 
> Ideally, I'd like to find an option that doesn't need to move twice during 
> v6.  Toward that goal, what if we moved edge_clearance to the defaults 
> section?  Until we implement the design rules and/or polygon-specific 
> clearance, it simply controls everything.  Once we integrate the new 
> features, they are allowed to override the default.
> 
> Thoughts?
> -Seth
> 
> On 2019-07-04 12:07, Jeff Young wrote:
>> Looking through our current set of board setup properties, only
>> solder_mask_min_width would join edge_clearance in a design_rules
>> section.
>> Most of the other properties are either most-recently-used values
>> (zone_clearance, via_size, etc.) or true DRC values (uvias_allowed,
>> trace_min, etc.).
>> The outlier is max_error, which is mostly a performance vs beauty
>> trade-off, but _does_ affect the generated board.
>> So,
>> 1) leave solder_mask_min_width and edge_clearance in setup for now
>> 2) create a design_rules section for solder_mask_min_width and
>> edge_clearance
>> 3) leave edge_clearance in the project file for now
>> I think I’d vote for (1) simply because I don’t know how (2) will
>> play with Jon’s stuff.  But the only one I don’t like is (3).
>> Cheers,
>> Jeff.
>>> On 4 Jul 2019, at 15:42, Seth Hillbrand  wrote:
>>> On 2019-07-04 09:24, Jeff Young wrote:
>>> Since this is DRC, can we keep it in its current place until the DRC
>>> manager goes in
>>> Well, there’s DRC and there’s DR.  The other options really
>>> control
>>> only what is *checked*, whereas this one controls stuff *on* the
>>> board.  Granted a lot of Jon’s rules will also fit into the DR
>>> camp,
>>> but I feel a little more reticent to move this one out.
>>> Thoughts?
>>> Jeff.
>> That's a valid point.  Ideally, I'd like to see this in a
>> "DesignRules" section.  Different manufacturers will have different
>> requirements here, so the DRC/DFM import would need to modify this
>> value.  The check also needs to allow separate values for internal vs.
>> external layers.
>> If we want to separate the generation from the checking, we might want
>> to put this setting in the zone parameters.  In which case, we might
>> use a global default setting that is used for new zones.
>> -Seth


___
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] Pcbnew file format

[Seth Hillbrand]

Hi Jeff-

Ideally, I'd like to find an option that doesn't need to move twice 
during v6.  Toward that goal, what if we moved edge_clearance to the 
defaults section?  Until we implement the design rules and/or 
polygon-specific clearance, it simply controls everything.  Once we 
integrate the new features, they are allowed to override the default.


Thoughts?
-Seth

On 2019-07-04 12:07, Jeff Young wrote:

Looking through our current set of board setup properties, only
solder_mask_min_width would join edge_clearance in a design_rules
section.

Most of the other properties are either most-recently-used values
(zone_clearance, via_size, etc.) or true DRC values (uvias_allowed,
trace_min, etc.).

The outlier is max_error, which is mostly a performance vs beauty
trade-off, but _does_ affect the generated board.

So,

1) leave solder_mask_min_width and edge_clearance in setup for now

2) create a design_rules section for solder_mask_min_width and
edge_clearance

3) leave edge_clearance in the project file for now

I think I’d vote for (1) simply because I don’t know how (2) will
play with Jon’s stuff.  But the only one I don’t like is (3).

Cheers,
Jeff.


On 4 Jul 2019, at 15:42, Seth Hillbrand  wrote:

On 2019-07-04 09:24, Jeff Young wrote:
Since this is DRC, can we keep it in its current place until the DRC
manager goes in
Well, there’s DRC and there’s DR.  The other options really
control
only what is *checked*, whereas this one controls stuff *on* the
board.  Granted a lot of Jon’s rules will also fit into the DR
camp,
but I feel a little more reticent to move this one out.
Thoughts?
Jeff.


That's a valid point.  Ideally, I'd like to see this in a
"DesignRules" section.  Different manufacturers will have different
requirements here, so the DRC/DFM import would need to modify this
value.  The check also needs to allow separate values for internal vs.
external layers.

If we want to separate the generation from the checking, we might want
to put this setting in the zone parameters.  In which case, we might
use a global default setting that is used for new zones.

-Seth


___
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] [PATCH] Board statistics dialog

[Jeff Young]

I agree that it shouldn’t be its own tool, but PCB_EDITOR_CONTROL is getting 
too big.

Let’s just name this tool the PCB_INSPECTION_TOOL, and then I’ll move the 
highlight and list nets stuff, and the DRC dialog to it later.  That’ll nicely 
parallel the EE_INSPECTION_TOOL.

Cheers,
Jeff.

> On 4 Jul 2019, at 21:56, Ian McInerney  wrote:
> 
> This looks nice, but a few comments from my initial usage of it:
> 
> Usability:
> 1) When I use english units, your statistics dialog gives the dimensions in 
> mils. It should probably give those in inches instead, since that is what the 
> grid panel at the bottom gives.
> 2) Including the board area would also be useful, definitely the area of the 
> bounding box, and possibly the area of the actual PCB (but that is more 
> complicated). I know of several board houses that charge based on area, so 
> this could provide a quick way to estimate price for the user.
> 3) I am not sure I am a fan of the icon used for the menu item, since this 
> dialog focuses on board statistics rather than footprint statistics and that 
> icon is used mainly for footprint actions. Could a variant of the pcbnew icon 
> be used?
> 
> 
> While the code as you gave works, I think the following changes could be 
> beneficial:
> 1) It seems that this action could just be added to PCB_EDITOR_CONTROL as the 
> action "pcbnew.Control.BoardStatistics" rather than creating a new tool just 
> for this.
> 2) I think the launching of the window could be simplified if you used a 
> modal window instead (see https://docs.wxwidgets.org/3.0/classwx_dialog.html 
> , the Modal and Modeless 
> section). Then you don't have to keep track of the window pointer, and could 
> actually just make launching this a single function instead of an entire 
> class (this would go nicely with point #1).
> 3) The function to start the window should be TransferDataToWindow, not 
> TransferDataFromWindow. FromWindow is called when the window is destroyed and 
> ToWindow is called when it is created. Also, it is called automatically when 
> the window is started, so there is no need to manually call it.
> 
> 
> Other code parts:
> 1) There are some lines that are too long in dialog_board_statistics.cpp (max 
> 100 characters per line)
> 2) There are a few whitespace errors when applying it:
> Applying: added board statistics dialog, which shows info for production and 
> assembly
> /home/imcinerney/Downloads/0001-added-board-statistics-dialog-which-shows-info-for-p.patch:158:
>  trailing whitespace.
> /* if pin has drill with width==0 and height==0, we 
> /home/imcinerney/Downloads/0001-added-board-statistics-dialog-which-shows-info-for-p.patch:1612:
>  new blank line at EOF.
> +
> warning: 2 lines add whitespace errors.
> 
> Overall though it looks pretty nice.
> 
> -Ian
> 
> On Thu, Jul 4, 2019 at 3:07 PM Шуклин Александр  > wrote:
> Hi, that's first time I try to contribute to KiCad and write to Launchpad 
> mailing lists, so please, don't beat me to hard )))
> I really miss some board statistic dialog, where you can see quantity of SMD 
> pads, THT pads, board dimensions, all the stuff, you need for PCB production 
> and assembly. There was also issue in the bug tracker 
> https://bugs.launchpad.net/kicad/+bug/1817232 
> 
> And like guy from bug issue, I moved from Altium Designer and miss that 
> dialog as well. 
> Can you please look at that and commit if you think it's useful or tell me 
> what to change.
> That's my commit in the github:
> https://github.com/jasuramme/kicad-source-mirror/commit/6290375c1d41ddb89d4b08067593f170c7d344c5
>  
> 
> and branch:
> https://github.com/jasuramme/kicad-source-mirror/tree/statistic_dialog 
> 
> and there's also patch and dialogs pics in the attachment.
> 
> ___
> 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 

Re: [Kicad-developers] [PATCH] Board statistics dialog

[Ian McInerney]

This looks nice, but a few comments from my initial usage of it:

Usability:
1) When I use english units, your statistics dialog gives the dimensions in
mils. It should probably give those in inches instead, since that is what
the grid panel at the bottom gives.
2) Including the board area would also be useful, definitely the area of
the bounding box, and possibly the area of the actual PCB (but that is more
complicated). I know of several board houses that charge based on area, so
this could provide a quick way to estimate price for the user.
3) I am not sure I am a fan of the icon used for the menu item, since this
dialog focuses on board statistics rather than footprint statistics and
that icon is used mainly for footprint actions. Could a variant of the
pcbnew icon be used?


While the code as you gave works, I think the following changes could be
beneficial:
1) It seems that this action could just be added to PCB_EDITOR_CONTROL as
the action "pcbnew.Control.BoardStatistics" rather than creating a new tool
just for this.
2) I think the launching of the window could be simplified if you used a
modal window instead (see https://docs.wxwidgets.org/3.0/classwx_dialog.html,
the Modal and Modeless section). Then you don't have to keep track of the
window pointer, and could actually just make launching this a single
function instead of an entire class (this would go nicely with point #1).
3) The function to start the window should be TransferDataToWindow, not
TransferDataFromWindow. FromWindow is called when the window is destroyed
and ToWindow is called when it is created. Also, it is called automatically
when the window is started, so there is no need to manually call it.


Other code parts:
1) There are some lines that are too long in dialog_board_statistics.cpp
(max 100 characters per line)
2) There are a few whitespace errors when applying it:
Applying: added board statistics dialog, which shows info for production
and assembly
/home/imcinerney/Downloads/0001-added-board-statistics-dialog-which-shows-info-for-p.patch:158:
trailing whitespace.
/* if pin has drill with width==0 and height==0, we
/home/imcinerney/Downloads/0001-added-board-statistics-dialog-which-shows-info-for-p.patch:1612:
new blank line at EOF.
+
warning: 2 lines add whitespace errors.

Overall though it looks pretty nice.

-Ian

On Thu, Jul 4, 2019 at 3:07 PM Шуклин Александр  wrote:

> Hi, that's first time I try to contribute to KiCad and write to Launchpad
> mailing lists, so please, don't beat me to hard )))
> I really miss some board statistic dialog, where you can see quantity of
> SMD pads, THT pads, board dimensions, all the stuff, you need for PCB
> production and assembly. There was also issue in the bug tracker
> https://bugs.launchpad.net/kicad/+bug/1817232
> And like guy from bug issue, I moved from Altium Designer and miss that
> dialog as well.
> Can you please look at that and commit if you think it's useful or tell me
> what to change.
> That's my commit in the github:
>
> https://github.com/jasuramme/kicad-source-mirror/commit/6290375c1d41ddb89d4b08067593f170c7d344c5
> and branch:
> https://github.com/jasuramme/kicad-source-mirror/tree/statistic_dialog
> and there's also patch and dialogs pics in the attachment.
>
> ___
> 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] [PATCH] Board statistics dialog

[easyw]

  
Hi, 
nice addition indeed... 
You may find someone with the same
needs at the forum

https://forum.kicad.info/t/how-to-get-pin-count-and-board-size-for-assembly/17792

There is a small plugin offering this option ATM,  
listing what Mario
is asking for... 
It would be nice to have it in the main branch.

Maurice 

Il 04.07.2019 16:28 Mário Luzeiro ha scritto: 

> Hi SHuklin!
( is this the romanization of your name? :) )
> 
> This is just my user
feedback:
> That is a cool addition, another feature suggestions would
be to list the components by "Fabrication attributes" "Through
hole"/"Surface mount"/"Virtual" Each footprint has this attribute so I
guess you can easily count it.
> They are important values for
calculation costs of the assembly.
> 
> Mario Luzeiro
> 
>

> From: Kicad-developers on
behalf of Шуклин Александр 
> Sent: 04 July 2019 15:06
> To:
kicad-developers@lists.launchpad.net [3]
> Subject: [Kicad-developers]
[PATCH] Board statistics dialog
> 
> Hi, that's first time I try to
contribute to KiCad and write to Launchpad mailing lists, so please,
don't beat me to hard )))
> I really miss some board statistic dialog,
where you can see quantity of SMD pads, THT pads, board dimensions, all
the stuff, you need for PCB production and assembly. There was also
issue in the bug tracker
> https://bugs.launchpad.net/kicad/+bug/1817232
[4]
> And like guy from bug issue, I moved from Altium Designer and miss
that dialog as well.
> Can you please look at that and commit if you
think it's useful or tell me what to change.
> That's my commit in the
github:
>
https://github.com/jasuramme/kicad-source-mirror/commit/6290375c1d41ddb89d4b08067593f170c7d344c5
[5]
> and branch:
>
https://github.com/jasuramme/kicad-source-mirror/tree/statistic_dialog
[6]
> and there's also patch and dialogs pics in the attachment.
> 
>
___
> Mailing list:
https://launchpad.net/~kicad-developers [7]
> Post to :
kicad-developers@lists.launchpad.net [8]
> Unsubscribe :
https://launchpad.net/~kicad-developers [9]
> More help :
https://help.launchpad.net/ListHelp [10]
  


Con Mobile Open 7 GB a 9 euro/4 sett navighi veloce con 7 GB di Internet e hai 
200 minuti ed SMS a 15 cent. Passa a Tiscali Mobile! http://tisca.li/Open7GB0617

___
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] New package for macOS 5.1.2 stable including ngspice-30 ?

[Adam Wolf]

Based upon a bug in the tracker, it may be working or not working depending
upon external files, rather than exactly which nightly build it is.

On Wed, Jul 3, 2019, 8:16 AM Nick Østergaard  wrote:

> Cool, thank you for verifying.
>
> ons. 3. jul. 2019 14.54 skrev Seth Hillbrand :
>
>> On 2019-07-03 02:12, Nick Østergaard wrote:
>> > On Wed, 3 Jul 2019 at 06:39, Seth Hillbrand  wrote:
>> >> Hi Nick-
>> >>
>> >> Tested with latest nightly and it works nicely on 10.14.3.  I used the
>> >> simulations in the demos folder.
>> >>
>> >> Best-
>> >> Seth
>> >
>> > Cool, thank your for verifying. Did you check that it was actually
>> > running ngspice 30 with the control commands?
>>
>> Just checked now.
>>
>> .control
>> op
>> print allv
>> .enc
>>
>> Works correctly
>>
>> -Seth
>>
> ___
> 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] Pcbnew file format

[Jeff Young]

Looking through our current set of board setup properties, only 
solder_mask_min_width would join edge_clearance in a design_rules section.  

Most of the other properties are either most-recently-used values 
(zone_clearance, via_size, etc.) or true DRC values (uvias_allowed, trace_min, 
etc.).

The outlier is max_error, which is mostly a performance vs beauty trade-off, 
but does affect the generated board.

So,

1) leave solder_mask_min_width and edge_clearance in setup for now

2) create a design_rules section for solder_mask_min_width and edge_clearance

3) leave edge_clearance in the project file for now

I think I’d vote for (1) simply because I don’t know how (2) will play with 
Jon’s stuff.  But the only one I don’t like is (3).

Cheers,
Jeff.


> On 4 Jul 2019, at 15:42, Seth Hillbrand  wrote:
> 
> On 2019-07-04 09:24, Jeff Young wrote:
>>> Since this is DRC, can we keep it in its current place until the DRC 
>>> manager goes in
>> Well, there’s DRC and there’s DR.  The other options really control
>> only what is *checked*, whereas this one controls stuff *on* the
>> board.  Granted a lot of Jon’s rules will also fit into the DR camp,
>> but I feel a little more reticent to move this one out.
>> Thoughts?
>> Jeff.
> 
> That's a valid point.  Ideally, I'd like to see this in a "DesignRules" 
> section.  Different manufacturers will have different requirements here, so 
> the DRC/DFM import would need to modify this value.  The check also needs to 
> allow separate values for internal vs. external layers.
> 
> If we want to separate the generation from the checking, we might want to put 
> this setting in the zone parameters.  In which case, we might use a global 
> default setting that is used for new zones.
> 
> -Seth

___
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] [PATCH v2 3/8] Set _USE_MATH_DEFINES on Windows

[Simon Richter]

All compilers need this in standards-compliant mode.
---
 CMakeLists.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index ee43d9eb98..c73c86a291 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -245,6 +245,10 @@ if( WIN32 )
 # define UNICODE and_UNICODE definition on Windows. KiCad uses unicode.
 # Both definitions are required
 add_definitions(-DUNICODE -D_UNICODE)
+
+# In fully standards-compliant mode, M_PI et al. are defined only if
+# _USE_MATH_DEFINES is set.
+add_definitions( -D_USE_MATH_DEFINES )
 endif()
 
 
___
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] [PATCH v2 8/8] Define compiler flags for MSVC

[Simon Richter]

Defines:
 - inhibit generation of #pragma comment(lib, ...) from boost
 - inhibit warnings about "unsafe" containers
 - inhibit warnings about "unsafe" C functions
 - inhibit warnings about "deprecated" POSIX functions
 - suppress min/max macros from windows.h

Flags:
 - source and execution charsets are UTF-8
 - suppress warnings about throw() not being fully supported in the compiler
 - suppress warnings about values being explicitly cast to bool
 - enable string pooling
 - enable unreferenced code removal
 - enable COMDAT folding
 - generate PDB debug information
---
 CMakeLists.txt | 40 
 1 file changed, 40 insertions(+)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index c73c86a291..c64d752c2e 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -108,6 +108,10 @@ option( KICAD_SPICE
 "Build KiCad with internal Spice simulator."
 ON )
 
+option( KICAD_BUILD_PARALLEL_CL_MP
+"Build in parallel using the /MP compiler option (default OFF for safety reasons)"
+OFF )
+
 # when option KICAD_SCRIPTING OR KICAD_SCRIPTING_MODULES is enabled:
 # PYTHON_EXECUTABLE can be defined when invoking cmake
 # ( use -DPYTHON_EXECUTABLE=/python.exe or python2 )
@@ -361,6 +365,42 @@ if( CMAKE_COMPILER_IS_GNUCXX OR CMAKE_CXX_COMPILER_ID MATCHES "Clang" )
 
 endif( CMAKE_COMPILER_IS_GNUCXX OR CMAKE_CXX_COMPILER_ID MATCHES "Clang" )
 
+if( MSVC )
+# Disallow implicit linking for Boost
+add_definitions( -DBOOST_ALL_NO_LIB )
+# Disable MSVC's deprecation warnings
+add_definitions( -D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS )
+# Hide Windows's min() and max() macros
+add_definitions( -DNOMINMAX )
+# source and execution charset are UTF-8
+string( APPEND CMAKE_CXX_FLAGS " /UTF-8" )
+# C4290: throw() is interpreted as declspec(nothrow)
+string( APPEND CMAKE_CXX_FLAGS " /wd4290" )
+# C4800: non-bool is explicitly cast to bool, forcing value of 0 or 1
+string( APPEND CMAKE_CXX_FLAGS " /wd4800" )
+# /Zi: create PDB
+string( APPEND CMAKE_CXX_FLAGS " /Zi" )
+# /GF: enable string pooling
+string( APPEND CMAKE_CXX_FLAGS_RELEASE " /GF" )
+foreach( type EXE SHARED MODULE)
+# /DEBUG: create PDB
+string( APPEND CMAKE_${type}_LINKER_FLAGS " /DEBUG" )
+# /OPT:REF: omit unreferenced code
+string( APPEND CMAKE_${type}_LINKER_FLAGS_RELEASE " /OPT:REF" )
+# /OPT:ICF: fold common data
+string( APPEND CMAKE_${type}_LINKER_FLAGS_RELEASE " /OPT:ICF" )
+endforeach()
+
+# Let cl.exe parallelize builds
+if( KICAD_BUILD_PARALLEL_CL_MP )
+string( APPEND CMAKE_CXX_FLAGS " /MP" )
+endif()
+endif()
+
+if( USE_WX_OVERLAY OR APPLE )
+add_definitions( -DUSE_WX_OVERLAY )
+endif()
+
 if( KICAD_SCRIPTING )
 add_definitions( -DKICAD_SCRIPTING )
 endif()
___
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] [PATCH v2 1/8] pcbnew: can't return a copy of ptr_vector if items are polymorphic and have no clone() methods. Work it around.

[Simon Richter]

---
 pcbnew/pcb_edit_frame.h  |  3 ++-
 pcbnew/pcbnew_config.cpp | 12 ++--
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/pcbnew/pcb_edit_frame.h b/pcbnew/pcb_edit_frame.h
index 705f5f7f4c..dadb6cba0e 100644
--- a/pcbnew/pcb_edit_frame.h
+++ b/pcbnew/pcb_edit_frame.h
@@ -93,6 +93,7 @@ protected:
 PCB_LAYER_WIDGET* m_Layers;
 
 PARAM_CFG_ARRAY   m_configParams; ///< List of Pcbnew configuration settings.
+PARAM_CFG_ARRAY   m_projectFileParams;
 
 wxString  m_lastNetListRead;///< Last net list read with relative path.
 
@@ -379,7 +380,7 @@ public:
  * @return PARAM_CFG_ARRAY - it is only good until SetBoard() is called, so
  *   don't keep it around past that event.
  */
-PARAM_CFG_ARRAY GetProjectFileParameters();
+PARAM_CFG_ARRAY& GetProjectFileParameters();
 
 /**
  * Function SaveProjectSettings
diff --git a/pcbnew/pcbnew_config.cpp b/pcbnew/pcbnew_config.cpp
index ff1cb57420..8b577538ef 100644
--- a/pcbnew/pcbnew_config.cpp
+++ b/pcbnew/pcbnew_config.cpp
@@ -125,21 +125,21 @@ void PCB_EDIT_FRAME::SaveProjectSettings( bool aAskForSave )
 }
 
 
-PARAM_CFG_ARRAY PCB_EDIT_FRAME::GetProjectFileParameters()
+PARAM_CFG_ARRAY& PCB_EDIT_FRAME::GetProjectFileParameters()
 {
-PARAM_CFG_ARRAY pca;
+m_projectFileParams.clear();
 
 // This one cannot be cached because some settings are going to/from the BOARD,
 // so pointers into that cannot be saved for long.
 
-pca.push_back( new PARAM_CFG_FILENAME( wxT( "PageLayoutDescrFile" ),
+m_projectFileParams.push_back( new PARAM_CFG_FILENAME( wxT( "PageLayoutDescrFile" ),
   _SCREEN::m_PageLayoutDescrFileName ) );
 
-pca.push_back( new PARAM_CFG_FILENAME( wxT( "LastNetListRead" ), _lastNetListRead ) );
+m_projectFileParams.push_back( new PARAM_CFG_FILENAME( wxT( "LastNetListRead" ), _lastNetListRead ) );
 
-GetBoard()->GetDesignSettings().AppendConfigs( GetBoard(),  );
+GetBoard()->GetDesignSettings().AppendConfigs( GetBoard(), _projectFileParams);
 
-return pca;
+return m_projectFileParams;
 }
 
 
___
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] [PATCH v2 6/8] MSVC support for libcontext

[Simon Richter]

This uses the Windows native Fiber API.
---
 common/system/libcontext.cpp | 66 
 include/system/libcontext.h  | 16 ++-
 include/tool/coroutine.h |  8 --
 3 files changed, 87 insertions(+), 3 deletions(-)

diff --git a/common/system/libcontext.cpp b/common/system/libcontext.cpp
index f6f83ceaef..57478f12c2 100644
--- a/common/system/libcontext.cpp
+++ b/common/system/libcontext.cpp
@@ -13,6 +13,8 @@
 http://www.boost.org/LICENSE_1_0.txt)
 
 */
+#include 
+#include 
 #include 
 
 #if defined(LIBCONTEXT_PLATFORM_windows_i386) && defined(LIBCONTEXT_COMPILER_gcc)
@@ -1268,3 +1270,67 @@ __asm (
 );
 
 #endif
+
+#if defined(LIBCONTEXT_PLATFORM_msvc_x86_64) || defined(LIBCONTEXT_PLATFORM_msvc_i386)
+
+#include 
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include 
+
+namespace libcontext
+{
+
+static int threadHasFibers = 0;
+
+struct FiberData
+{
+	intptr_t inValue;
+	intptr_t outValue;
+	void(*entry)(intptr_t);
+};
+
+static std::map fiberParams;
+
+static void fiberEntry(LPVOID params)
+{
+	auto ctx = (fcontext_t) GetCurrentFiber();
+	auto& d = fiberParams[ctx];
+	d.entry(d.inValue);
+}
+
+fcontext_t LIBCONTEXT_CALL_CONVENTION make_fcontext(void* sp, size_t size, void(*fn)(intptr_t))
+{
+	if (!threadHasFibers)
+	{
+		ConvertThreadToFiber(nullptr);
+		threadHasFibers = 1;
+	}
+
+	fcontext_t ctx = CreateFiber(size, (LPFIBER_START_ROUTINE) fiberEntry, nullptr );
+	fiberParams[ctx].entry = fn;
+
+	return ctx;
+}
+
+intptr_t LIBCONTEXT_CALL_CONVENTION jump_fcontext(fcontext_t* ofc, fcontext_t nfc,
+	intptr_t vp, bool preserve_fpu)
+{
+	auto current = (void*)GetCurrentFiber();
+	fiberParams[current].outValue = vp;
+	*ofc = GetCurrentFiber();
+	fiberParams[nfc].inValue = vp;
+	SwitchToFiber(nfc);
+	return fiberParams[*ofc].outValue;
+}
+
+}; // namespace libcontext
+
+#ifdef __cplusplus
+};
+#endif
+
+#endif
diff --git a/include/system/libcontext.h b/include/system/libcontext.h
index 8045fa2b78..dfa323dcd3 100644
--- a/include/system/libcontext.h
+++ b/include/system/libcontext.h
@@ -24,6 +24,8 @@
 
 #if defined(__GNUC__) || defined(__APPLE__) || defined(__FreeBSD__)
 
+#undef LIBCONTEXT_HAS_OWN_STACK
+
 #define LIBCONTEXT_COMPILER_gcc
 
 #if defined(__linux__) || defined(__FreeBSD__)
@@ -46,7 +48,8 @@
 #ifdef _ARCH_PPC64
 #define LIBCONTEXT_PLATFORM_linux_ppc64
 #define LIBCONTEXT_CALL_CONVENTION
-#elif defined _ARCH_PPC
+#endif
+#ifdef _ARCH_PPC
 #define LIBCONTEXT_PLATFORM_linux_ppc32
 #define LIBCONTEXT_CALL_CONVENTION
 #endif
@@ -73,6 +76,17 @@
 #define LIBCONTEXT_CALL_CONVENTION
 #endif
 #endif
+#elif defined (_MSC_VER)
+
+#define LIBCONTEXT_HAS_OWN_STACK
+
+#define LIBCONTEXT_CALL_CONVENTION __cdecl
+
+#if defined(_WIN64)
+	#define LIBCONTEXT_PLATFORM_msvc_x86_64
+#elif defined(_WIN32)
+	#define LIBCONTEXT_PLATFORM_msvc_i386
+#endif
 #endif
 
 #ifdef __cplusplus
diff --git a/include/tool/coroutine.h b/include/tool/coroutine.h
index 7be173adb1..60144ebc0b 100644
--- a/include/tool/coroutine.h
+++ b/include/tool/coroutine.h
@@ -294,15 +294,19 @@ private:
 
 assert( m_stack == nullptr );
 
-// fixme: Clean up stack stuff. Add a guard
 size_t stackSize = c_defaultStackSize;
+void* sp = nullptr;
+
+#ifndef LIBCONTEXT_HAS_OWN_STACK
+// fixme: Clean up stack stuff. Add a guard
 m_stack.reset( new char[stackSize] );
 
 // align to 16 bytes
-void* sp = (void*)ptrdiff_t) m_stack.get()) + stackSize - 0xf) & (~0x0f));
+sp = (void*)ptrdiff_t) m_stack.get()) + stackSize - 0xf) & (~0x0f));
 
 // correct the stack size
 stackSize -= size_t( ( (ptrdiff_t) m_stack.get() + stackSize ) - (ptrdiff_t) sp );
+#endif
 
 m_callee = libcontext::make_fcontext( sp, stackSize, callerStub );
 m_running = true;
___
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] [PATCH v2 5/8] Work around missing min/max in Windows headers

[Simon Richter]

Windows headers assume min/max to be macros, but we set NOMINMAX to hide
the macro definitions. This pulls in an alternative implementation.
---
 common/gal/cairo/cairo_print.cpp | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/common/gal/cairo/cairo_print.cpp b/common/gal/cairo/cairo_print.cpp
index 0204c69701..6cef33e9bd 100644
--- a/common/gal/cairo/cairo_print.cpp
+++ b/common/gal/cairo/cairo_print.cpp
@@ -25,6 +25,12 @@
 #include 
 #include 
 
+#ifdef NOMINMAX /* workaround for gdiplus.h */
+#include 
+using std::min;
+using std::max;
+#endif
+
 #ifdef __WXMSW__
 #include 
 #include 
___
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] [PATCH v2 4/8] Remove own copy of FindOpenSSL.cmake

[Simon Richter]

---
 CMakeModules/FindOpenSSL.cmake | 342 -
 1 file changed, 342 deletions(-)
 delete mode 100644 CMakeModules/FindOpenSSL.cmake

diff --git a/CMakeModules/FindOpenSSL.cmake b/CMakeModules/FindOpenSSL.cmake
deleted file mode 100644
index de91787c18..00
--- a/CMakeModules/FindOpenSSL.cmake
+++ /dev/null
@@ -1,342 +0,0 @@
-#.rst:
-# FindOpenSSL
-# ---
-#
-# Try to find the OpenSSL encryption library
-#
-# Once done this will define
-#
-# ::
-#
-#   OPENSSL_ROOT_DIR - Set this variable to the root installation of OpenSSL
-#
-#
-#
-# Read-Only variables:
-#
-# ::
-#
-#   OPENSSL_FOUND - system has the OpenSSL library
-#   OPENSSL_INCLUDE_DIR - the OpenSSL include directory
-#   OPENSSL_LIBRARIES - The libraries needed to use OpenSSL
-#   OPENSSL_VERSION - This is set to $major.$minor.$revision$path (eg. 0.9.8s)
-
-#=
-# Copyright 2006-2009 Kitware, Inc.
-# Copyright 2006 Alexander Neundorf 
-# Copyright 2009-2011 Mathieu Malaterre 
-#
-# Distributed under the OSI-approved BSD License (the "License");
-# see accompanying file Copyright.txt for details.
-#
-# This software is distributed WITHOUT ANY WARRANTY; without even the
-# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
-# See the License for more information.
-#=
-# (To distribute this file outside of CMake, substitute the full
-#  License text for the above reference.)
-
-if (UNIX)
-  find_package(PkgConfig QUIET)
-  pkg_check_modules(_OPENSSL QUIET openssl)
-endif ()
-
-if (WIN32)
-  # http://www.slproweb.com/products/Win32OpenSSL.html
-  set(_OPENSSL_ROOT_HINTS
-${OPENSSL_ROOT_DIR}
-"[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\OpenSSL (32-bit)_is1;Inno Setup: App Path]"
-"[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\OpenSSL (64-bit)_is1;Inno Setup: App Path]"
-ENV OPENSSL_ROOT_DIR
-)
-  file(TO_CMAKE_PATH "$ENV{PROGRAMFILES}" _programfiles)
-  set(_OPENSSL_ROOT_PATHS
-"${_programfiles}/OpenSSL"
-"${_programfiles}/OpenSSL-Win32"
-"${_programfiles}/OpenSSL-Win64"
-"C:/OpenSSL/"
-"C:/OpenSSL-Win32/"
-"C:/OpenSSL-Win64/"
-)
-  unset(_programfiles)
-else ()
-  set(_OPENSSL_ROOT_HINTS
-${OPENSSL_ROOT_DIR}
-ENV OPENSSL_ROOT_DIR
-)
-endif ()
-
-set(_OPENSSL_ROOT_HINTS_AND_PATHS
-HINTS ${_OPENSSL_ROOT_HINTS}
-PATHS ${_OPENSSL_ROOT_PATHS}
-)
-
-find_path(OPENSSL_INCLUDE_DIR
-  NAMES
-openssl/ssl.h
-${_OPENSSL_ROOT_HINTS_AND_PATHS}
-  HINTS
-${_OPENSSL_INCLUDEDIR}
-  PATH_SUFFIXES
-include
-)
-
-if(WIN32 AND NOT CYGWIN)
-  if(MSVC)
-# /MD and /MDd are the standard values - if someone wants to use
-# others, the libnames have to change here too
-# use also ssl and ssleay32 in debug as fallback for openssl < 0.9.8b
-# TODO: handle /MT and static lib
-# In Visual C++ naming convention each of these four kinds of Windows libraries has it's standard suffix:
-#   * MD for dynamic-release
-#   * MDd for dynamic-debug
-#   * MT for static-release
-#   * MTd for static-debug
-
-# Implementation details:
-# We are using the libraries located in the VC subdir instead of the parent directory eventhough :
-# libeay32MD.lib is identical to ../libeay32.lib, and
-# ssleay32MD.lib is identical to ../ssleay32.lib
-find_library(LIB_EAY_DEBUG
-  NAMES
-libeay32MDd
-libeay32d
-${_OPENSSL_ROOT_HINTS_AND_PATHS}
-  PATH_SUFFIXES
-"lib"
-"VC"
-"lib/VC"
-)
-
-find_library(LIB_EAY_RELEASE
-  NAMES
-libeay32MD
-libeay32
-${_OPENSSL_ROOT_HINTS_AND_PATHS}
-  PATH_SUFFIXES
-"lib"
-"VC"
-"lib/VC"
-)
-
-find_library(SSL_EAY_DEBUG
-  NAMES
-ssleay32MDd
-ssleay32d
-${_OPENSSL_ROOT_HINTS_AND_PATHS}
-  PATH_SUFFIXES
-"lib"
-"VC"
-"lib/VC"
-)
-
-find_library(SSL_EAY_RELEASE
-  NAMES
-ssleay32MD
-ssleay32
-ssl
-${_OPENSSL_ROOT_HINTS_AND_PATHS}
-  PATH_SUFFIXES
-"lib"
-"VC"
-"lib/VC"
-)
-
-set(LIB_EAY_LIBRARY_DEBUG "${LIB_EAY_DEBUG}")
-set(LIB_EAY_LIBRARY_RELEASE "${LIB_EAY_RELEASE}")
-set(SSL_EAY_LIBRARY_DEBUG "${SSL_EAY_DEBUG}")
-set(SSL_EAY_LIBRARY_RELEASE "${SSL_EAY_RELEASE}")
-
-include(${CMAKE_CURRENT_LIST_DIR}/SelectLibraryConfigurations.cmake)
-select_library_configurations(LIB_EAY)
-select_library_configurations(SSL_EAY)
-
-mark_as_advanced(LIB_EAY_LIBRARY_DEBUG LIB_EAY_LIBRARY_RELEASE
- SSL_EAY_LIBRARY_DEBUG SSL_EAY_LIBRARY_RELEASE)
-set( OPENSSL_LIBRARIES ${SSL_EAY_LIBRARY} ${LIB_EAY_LIBRARY} )
-  elseif(MINGW)
-message( STATUS "Searching 

[Kicad-developers] [PATCH v2 0/8] MSVC Build

[Simon Richter]

Hi,

another attempt at getting the MSVC patchset merged. :)

The mails with the patches are for commenting, this branch should probably
be merged from the "msvc" branch under https://git.launchpad.net/~sjr/kicad
in order to preserve author/date information properly.

   Simon

Simon Richter (5):
  Set _USE_MATH_DEFINES on Windows
  Remove own copy of FindOpenSSL.cmake
  Work around missing min/max in Windows headers
  Pull in macro definition for strncasecmp on MSVC
  Define compiler flags for MSVC

Tomasz Wlostowski (3):
  pcbnew: can't return a copy of ptr_vector if items are polymorphic and
have no clone() methods. Work it around.
  Export LIB_TREE_ITEM
  MSVC support for libcontext

 CMakeLists.txt   |  44 +
 CMakeModules/FindOpenSSL.cmake   | 342 ---
 common/gal/cairo/cairo_print.cpp |   6 +
 common/system/libcontext.cpp |  66 
 eeschema/sim/ngspice.cpp |   1 +
 include/lib_tree_item.h  |   4 +-
 include/system/libcontext.h  |  16 +-
 include/tool/coroutine.h |   8 +-
 pcbnew/pcb_edit_frame.h  |   3 +-
 pcbnew/pcbnew_config.cpp |  12 +-
 10 files changed, 148 insertions(+), 354 deletions(-)
 delete mode 100644 CMakeModules/FindOpenSSL.cmake

-- 
2.11.0

___
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] [PATCH v2 7/8] Pull in macro definition for strncasecmp on MSVC

[Simon Richter]

---
 eeschema/sim/ngspice.cpp | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eeschema/sim/ngspice.cpp b/eeschema/sim/ngspice.cpp
index fa1d3e3a97..4b173ef7af 100644
--- a/eeschema/sim/ngspice.cpp
+++ b/eeschema/sim/ngspice.cpp
@@ -28,6 +28,7 @@
 #include "ngspice.h"
 #include "spice_reporter.h"
 
+#include 
 #include  // LOCALE_IO
 #include 
 #include 
___
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] [PATCH v2 2/8] Export LIB_TREE_ITEM

[Simon Richter]

---
 include/lib_tree_item.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/lib_tree_item.h b/include/lib_tree_item.h
index 5ad5ef4bd8..28f69b7c03 100644
--- a/include/lib_tree_item.h
+++ b/include/lib_tree_item.h
@@ -27,7 +27,7 @@
 
 #include 
 #include 
-
+#include 
 
 /**
  * A mix-in to provide polymorphism between items stored in libraries (symbols, aliases
@@ -36,7 +36,7 @@
  * It is used primarily to drive the component tree for library browsing and editing.
  */
 
-class LIB_TREE_ITEM
+class APIEXPORT LIB_TREE_ITEM
 {
 public:
 virtual LIB_ID GetLibId() const = 0;
___
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] Pcbnew file format

[Seth Hillbrand]

On 2019-07-04 09:24, Jeff Young wrote:
Since this is DRC, can we keep it in its current place until the DRC 
manager goes in


Well, there’s DRC and there’s DR.  The other options really control
only what is *checked*, whereas this one controls stuff *on* the
board.  Granted a lot of Jon’s rules will also fit into the DR camp,
but I feel a little more reticent to move this one out.

Thoughts?

Jeff.


That's a valid point.  Ideally, I'd like to see this in a "DesignRules" 
section.  Different manufacturers will have different requirements here, 
so the DRC/DFM import would need to modify this value.  The check also 
needs to allow separate values for internal vs. external layers.


If we want to separate the generation from the checking, we might want 
to put this setting in the zone parameters.  In which case, we might use 
a global default setting that is used for new zones.


-Seth

___
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] [PATCH] Board statistics dialog

[Mário Luzeiro]

Hi SHuklin! ( is this the romanization of your name? :) )

This is just my user feedback:
That is a cool addition, another feature suggestions would be to list the 
components by "Fabrication attributes" "Through hole"/"Surface mount"/"Virtual" 
Each footprint has this attribute so I guess you can easily count it.
They are important values for calculation costs of the assembly.

Mario Luzeiro


From: Kicad-developers 
 on behalf of 
Шуклин Александр 
Sent: 04 July 2019 15:06
To: kicad-developers@lists.launchpad.net
Subject: [Kicad-developers] [PATCH] Board statistics dialog

Hi, that's first time I try to contribute to KiCad and write to Launchpad 
mailing lists, so please, don't beat me to hard )))
I really miss some board statistic dialog, where you can see quantity of SMD 
pads, THT pads, board dimensions, all the stuff, you need for PCB production 
and assembly. There was also issue in the bug tracker
https://bugs.launchpad.net/kicad/+bug/1817232
And like guy from bug issue, I moved from Altium Designer and miss that dialog 
as well.
Can you please look at that and commit if you think it's useful or tell me what 
to change.
That's my commit in the github:
https://github.com/jasuramme/kicad-source-mirror/commit/6290375c1d41ddb89d4b08067593f170c7d344c5
and branch:
https://github.com/jasuramme/kicad-source-mirror/tree/statistic_dialog
and there's also patch and dialogs pics in the attachment.

___
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] Pcbnew file format

[Jeff Young]

> Since this is DRC, can we keep it in its current place until the DRC manager 
> goes in

Well, there’s DRC and there’s DR.  The other options really control only what 
is *checked*, whereas this one controls stuff *on* the board.  Granted a lot of 
Jon’s rules will also fit into the DR camp, but I feel a little more reticent 
to move this one out.

Thoughts?

Jeff.


> On 4 Jul 2019, at 00:48, Seth Hillbrand  wrote:
> 
> That was [1], right?  I completely missed that fix!  I can deal with not 
> having this option.  Keepout works as well for most applications.  
> [1] https://bugs.launchpad.net/kicad/+bug/1797787
> 
> On 2019-07-03 19:27, Jeff Young wrote:
>> Bug fix.  Many of our customers consider the edge cuts having width to be a 
>> bug.
>> I suppose we could put a clearance property on a segment….
>>> On 4 Jul 2019, at 00:05, Seth Hillbrand  wrote:
>>> I hadn't in a while.  I just did.
>>> That's problematic for me.  Is it required for some other feature?
>>> -S
>>> On 2019-07-03 18:36, Jeff Young wrote:
 Hi Seth,
 Have you tried opening one of these boards? ;)
 (There’s code in there that sets the edge clearance to 1/2 the edge
 thickness if they’re consistent, and puts up a warning if they’re not
 consistent.)
 Cheers,
 Jeff.
> On 3 Jul 2019, at 22:47, Seth Hillbrand  wrote:
> Thanks Jeff!
> One remaining concern is that a global edge clearance setting removes the 
> ability to choose the clearance based on the edge.  Usually I'll have 
> different widths to account for whether the edge is routed, a v-score or 
> mouse-bite disconnect.  I don't usually have multiple on one design but 
> every now and again, I need a close-packed board and want to have larger 
> clearance only where the mousebite is.
> Can we keep that with DRC also?  It kind of fits with the additional 
> rules (minimum hole to edge, minimum component to edge, etc) and the 
> logical evaluation system would still allow us to keep the variable 
> clearance feature.
> Best-
> Seth
> On 2019-07-03 17:21, Jeff Young wrote:
>> Here’s one with a (defaults…) section and no DRC settings:
>> https://git.launchpad.net/~jeyjey/kicad/commit/?id=fa24a991830610dcba84f97f0e5c58be2754ef4e
>> Cheers,
>> Jeff.
>>> On 3 Jul 2019, at 19:46, Wayne Stambaugh 
>>> wrote:
>>> We should definitely coordinate this work.  I thought Jon's drc work
>>> saves the drc settings in a separate drc file for portability
>>> between
>>> projects.  If that is the case, we should avoid adding new drc
>>> settings
>>> to the board file.
>>> On 7/3/2019 1:46 PM, Seth Hillbrand wrote:
>>> Hi Jeff-
>>> Can we split out the DRC things?  I'm pretty sure that these are
>>> included in Jon's DRC rework, so it would be nice to avoid a
>>> temporary
>>> file format that we supersede shortly.
>>> -S
>>> On 2019-07-03 06:23, Jeff Young wrote:
>>> Please see
>> https://git.launchpad.net/~jeyjey/kicad/commit/?id=a2c2d9f5d9b37576ec72cd0d4c64652cfddeb8df
>>> for board file changes for:
>>> 1) min-hole-to-hole distance
>>> 2) courtyard DRC flags (require courtyards and prohibit overlapping
>>> courtyards)
>>> 3) default layer line widths and text dimensions
>>> Cheers,
>>> Jeff.
>>> On 2 Jul 2019, at 16:58, Wayne Stambaugh 
>>> wrote:
>>> On 7/2/2019 11:11 AM, jp charras wrote:
>>> Le 02/07/2019 à 16:55, Jeff Young a écrit :
>>> I was testing 5.1 and noticed that it can no longer open 6.0 files.
>>> Was this accidental, or have we now diverged?
>>> (I ask only because I have a bunch of fixes waiting for file format
>>> changes which I could go ahead and make if we have officially
>>> diverged.)
>>> Cheers,
>>> Jeff.
>>> There is at least a change: "max_error" param in "setup" section.
>>> I have myself some other changes waiting in file format to support
>>> zones
>>> filled without outline thickness, and a support for board stackup
>>> info
>>> (for manufacturing purposes)
>>> Since the board file format in the master branch is no longer
>>> compatible
>>> with the 5.1 branch, I don't see any issues with pushing file format
>>> changes.  I only ask that before you push commits that affect the
>>> file
>>> format, please post your changes so we can take a look at them so we
>>> can
>>> review the file format changes before we merge them.  Please be sure
>>> to
>>> keep the file version up to date correctly as you push your
>>> individual
>>> changes to prevent any user issues.
>>> Cheers,
>>> Wayne
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : 

Re: [Kicad-developers] [PATCH] Crash Reporter

[Tomasz Wlostowski]

On 01/07/2019 23:49, Nick Østergaard wrote:
> Hello Tomasz
> 
> Do you have any comments on the wxwidgets version?

Hi Nick,

I have 3.1.1 in my MSYS environment, probably manually built.

We have two options:
- ask MSYS folks to update wxWidgets in the package repository,
- factor out stack trace implementation from newer wx version and
maintain it within kicad tree...

Cheers,
Tom

___
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] Pcbnew file format

[jp charras]

Le 04/07/2019 à 11:28, Jeff Young a écrit :
> A general-purpose way to solve this occurred to me:
> 
> 1) we’ve talked about having user-defined attributes on footprints — but
> they should really be on all items
> 2) then in Jon’s new DRC language we could define a clearance: * to
> *[@mousebite] (using XPath syntax ‘cause I can’t remember what Jon’s
> looked like)
> 
> Cheers,
> Jeff.
> 

The Margin layer (existing since a long time) was primarily intended to
define a clearance area on all layers.

Its purpose is to define a clearance area similar to a edge cut item,
but without the constrains of a edge cut item, that is used primarily to
define the board outline.
It is similar to a keepout zone, but in many cases more easy create and
edit, for basic shapes like segments

This layer is not activated in code but this is easy:
- This is a matter of a few lines of change.
- does not modify the file format.
- items are perfectly visible on board and easily editable.

Some other ECAD tools have this kind of feature.

Of course one can add attributes to any board item.
But they are invisible, and are easily removed when editing the board.

So they are less than ideal, and if exists, must me carefully used, and
rarely.


-- 
Jean-Pierre CHARRAS

___
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] Pcbnew file format

[Jeff Young]

A general-purpose way to solve this occurred to me:

1) we’ve talked about having user-defined attributes on footprints — but they 
should really be on all items
2) then in Jon’s new DRC language we could define a clearance: * to 
*[@mousebite] (using XPath syntax ‘cause I can’t remember what Jon’s looked 
like)

Cheers,
Jeff.

> On 4 Jul 2019, at 07:34, Eeli Kaikkonen  wrote:
> 
> 
> 
> to 4. heinäk. 2019 klo 2.27 Jeff Young (j...@rokeby.ie 
> ) kirjoitti:
> Bug fix.  Many of our customers consider the edge cuts having width to be a 
> bug.
> 
> 
> It's feels clumsy but it works. On the other hand I saw at least one 
> manufacture state that you should have only one width in edge outline layer 
> or give a note, otherwise they may ask confirmation. Different line widths 
> certainly isn't the best solution.
>  
> I suppose we could put a clearance property on a segment….
> 
> If you do, make it clear in the UI what it does. For example "Clearance from 
> mid-line to copper". It may be confusing that other clearances are edge to 
> edge.
> 
> Eeli Kaikkonen
> ___
> 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] Pcbnew file format

[Eeli Kaikkonen]

to 4. heinäk. 2019 klo 2.27 Jeff Young (j...@rokeby.ie) kirjoitti:

> Bug fix.  Many of our customers consider the edge cuts having width to be
> a bug.
>
>
It's feels clumsy but it works. On the other hand I saw at least one
manufacture state that you should have only one width in edge outline layer
or give a note, otherwise they may ask confirmation. Different line widths
certainly isn't the best solution.


> I suppose we could put a clearance property on a segment….
>

If you do, make it clear in the UI what it does. For example "Clearance
from mid-line to copper". It may be confusing that other clearances are
edge to edge.

Eeli Kaikkonen
___
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