Re: [Kicad-developers] Migrating old designs best practice

[Diego Herranz]

Thanks for the tip.
I'll use it to check schematics wiring.

Diego

On Sun, Nov 26, 2017 at 6:53 PM, jp charras  wrote:

> Le 26/11/2017 à 19:15, Diego Herranz a écrit :
> > It's interesting that only happen if I rescue symbols.
> >
> > Anyway, thanks for the help and I'll keep an eye on properly wired
> schematics to see if all goes OK.
> >
> > Thanks,
> > Diego
>
> To seen if your wires are OK, try to create a netlist:
>
> The first thing the netlist calculation make is to simplify wires
> (especially merge overlapping).
> This is mandatory to avoid incorrect netlists.
>
> If your issue can be seen after creating a netlist, you just have some
> incorrect (questionable?) wires.
>
> >
> > On Sun, Nov 26, 2017 at 5:23 PM, José Ignacio  >
> > wrote:
> >
> > This might be related to the wire optimizer/junction management
> code. Eeschema used to allow
> > degenerate connections like that, where an L was superimposed to a
> wire, connecting into a junction.
> >
>
> --
> 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
>
___
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] Prevent multiple item delete when routing (fixes lp:1715158)

[José Ignacio]

THANK YOU

On Wed, Dec 6, 2017 at 10:13 PM, Seth Hillbrand 
wrote:

> ​The attached patch corrects https://bugs.launchpad.net/kicad/+bug/1715158
> where pressing delete in pcbnew GAL canvas will delete _both_ a wire​ and
> the footprint underneath it.
>
> I know that this bug was marked "triaged" but it bit me on a board and I
> didn't notice the missing footprint (was zoomed in) until quite a few
> clicks later.
>
> -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

[Kicad-developers] [PATCH] Prevent multiple item delete when routing (fixes lp:1715158)

[Seth Hillbrand]

​The attached patch corrects https://bugs.launchpad.net/kicad/+bug/1715158
where pressing delete in pcbnew GAL canvas will delete _both_ a wire​ and
the footprint underneath it.

I know that this bug was marked "triaged" but it bit me on a board and I
didn't notice the missing footprint (was zoomed in) until quite a few
clicks later.

-Seth
From fc77ede4137e2426d6f086f7281bf985c24741df Mon Sep 17 00:00:00 2001
From: Seth Hillbrand 
Date: Tue, 5 Dec 2017 19:39:36 -0800
Subject: [PATCH] pcbnew: Fix multiple delete bug

Delete events when using GAL are handled by only one tool handler
instead of ROUTER_TOOL and EDIT_TOOL both deleting items.

Fixes: lp:1715158
* https://bugs.launchpad.net/kicad/+bug/1715158
---
 pcbnew/router/router_tool.cpp | 10 --
 1 file changed, 10 deletions(-)

diff --git a/pcbnew/router/router_tool.cpp b/pcbnew/router/router_tool.cpp
index 9de3b0d30..b1db25cc3 100644
--- a/pcbnew/router/router_tool.cpp
+++ b/pcbnew/router/router_tool.cpp
@@ -914,16 +914,6 @@ int ROUTER_TOOL::mainLoop( PNS::ROUTER_MODE aMode )
 {
 m_toolMgr->RunAction( PCB_ACTIONS::layerToggle, true );
 }
-else if( evt->IsAction( _ACTIONS::remove ) )
-{
-updateStartItem( *evt );
-deleteTraces( m_startItem, false );
-}
-else if( evt->IsAction( _ACTIONS::removeAlt ) )
-{
-updateStartItem( *evt );
-deleteTraces( m_startItem, true );
-}
 }
 
 frame->SetNoToolSelected();
-- 
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] spectra export filename (fixes lp:1736724)

[Seth Hillbrand]

This corrects the parameters for wxFileSelector in the ExportToSpectra()
function.

Fixes https://bugs.launchpad.net/kicad/+bug/1736724

-S
From 18bb5b432aeee47b908b0094f48490025fbfe46a Mon Sep 17 00:00:00 2001
From: Seth Hillbrand 
Date: Wed, 6 Dec 2017 17:18:35 -0800
Subject: [PATCH] pcbnew: Correct spectra output default filename

Fixes: lp:1736724
* https://bugs.launchpad.net/kicad/+bug/1736724
---
 pcbnew/specctra_export.cpp | 16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/pcbnew/specctra_export.cpp b/pcbnew/specctra_export.cpp
index 357aabb4b..b4a60ab90 100644
--- a/pcbnew/specctra_export.cpp
+++ b/pcbnew/specctra_export.cpp
@@ -74,20 +74,16 @@ static const double safetyMargin = 0.1;
 // see wxPcbStruct.h
 void PCB_EDIT_FRAME::ExportToSpecctra( wxCommandEvent& event )
 {
-wxStringfullFileName = GetBoard()->GetFileName();
-wxStringpath;
-wxStringname;
-wxStringext;
+wxStringfullFileName;
 wxStringdsn_ext = SpecctraDsnFileExtension;
 wxStringmask= SpecctraDsnFileWildcard();
+wxFileName  fn( GetBoard()->GetFileName() );
 
-wxFileName::SplitPath( fullFileName, , ,  );
+fn.SetExt( dsn_ext );
 
-name += dsn_ext;
-
-fullFileName = EDA_FILE_SELECTOR( _( "Specctra DSN file:" ),
-  path,
-  name,  // name.ext without path!
+fullFileName = EDA_FILE_SELECTOR( _( "Specctra DSN File" ),
+  fn.GetPath(),
+  fn.GetFullName(),
   dsn_ext,
   mask,
   this,
-- 
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

Re: [Kicad-developers] [PATCH 0/6] A few compatibility fixes

[Chris Pavlina]

On Wed, Dec 06, 2017 at 11:53:09PM +, Wayne Stambaugh wrote:
> On 12/06/2017 06:42 PM, Chris Pavlina wrote:
> > On Wed, Dec 06, 2017 at 11:38:21PM +, Wayne Stambaugh wrote:
> >> Simon,
> >>
> >> I'm OK with most of these patches but since when is it invalid to
> >> initialize a c array in c++ (patch 4)?  Isn't c a subset of c++
> > 
> > No, no it is not.
> 
> OK, technically but practically every c++ compiler allows you to do this
> so that is splitting hairs.

Yes, until they don't. I've been screwed by compilers deciding to change
how they handle things you're Not Supposed To Do enough times to know to
just behave.

> 
> > 
> >> or is
> >> this just a fix to get kicad to compile with msvc?  If it's the latter,
> >> the coding policy is pretty clear about that.
> >>
> >> Cheers,
> >>
> >> Wayne
> >>
> >> On 12/05/2017 09:42 PM, Simon Richter wrote:
> >>> Hi,
> >>>
> >>> these are a few things that cause build errors on MSVC, where gcc accepts
> >>> invalid code. Most of them are obvious.
> >>>
> >>> The pcb_test_window executable needs to be linked with /SUBSYSTEM:WINDOWS
> >>> on Windows because it is a GUI app, which uses different startup code than
> >>> a console application.
> >>>
> >>> The Boost.Test issue is a double definition of several symbols because 
> >>> some
> >>> objects expect that they need to bring their own definition, while others
> >>> link the shared library instead. Either is fine, but mixing is not allowed
> >>> (but ELF linking silently overrides symbols from shared libraries).
> >>>
> >>>Simon
> >>>
> >>> Simon Richter (6):
> >>>   Add missing include
> >>>   Avoid nonstandard variable length array
> >>>   Avoid initialization from non-constexpr
> >>>   Avoid C-style array member init (illegal in C++)
> >>>   Link pcb_test_window with /SUBSYSTEM:WINDOWS
> >>>   Pass -DBOOST_TEST_DYN_LINK to all parts of test
> >>>
> >>>  common/common_plotDXF_functions.cpp| 26 
> >>> --
> >>>  common/geometry/shape_poly_set.cpp |  5 +++--
> >>>  eeschema/qa/CMakeLists.txt |  3 +++
> >>>  eeschema/qa/test_module.cpp|  1 -
> >>>  eeschema/sch_line.cpp  | 21 +++--
> >>>  include/class_plotter.h|  1 -
> >>>  include/utf8.h |  4 +++-
> >>>  qa/pcb_test_window/CMakeLists.txt  |  2 +-
> >>>  .../test_polygon_triangulation.cpp |  6 ++---
> >>>  9 files changed, 41 insertions(+), 28 deletions(-)
> >>>
> >>>
> >>>
> >>> ___
> >>> 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] [PATCH] Fix artifacts on touchpad scroll (fixes lp:1735669)

[Wayne Stambaugh]

Seth,

I merged this patch so we could get some widespread testing done on it.

Thanks,

Wayne

On 12/04/2017 07:45 PM, Seth Hillbrand wrote:
> ​This fixes artifacts remaining on the screen when touchpad scrolling is
> enabled.
> https://bugs.launchpad.net/kicad/+bug/1735669
> 
> The attached patch is tested on MacOS and Linux.  Could someone with a
> Windows laptop check that the performance of touchpad scrolling is not
> affected?
> 
> Thanks!
> 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] [PATCH 0/6] A few compatibility fixes

[Wayne Stambaugh]

Simon,

I merged your patches into the development branch.

Thanks,

Wayne

On 12/05/2017 09:42 PM, Simon Richter wrote:
> Hi,
> 
> these are a few things that cause build errors on MSVC, where gcc accepts
> invalid code. Most of them are obvious.
> 
> The pcb_test_window executable needs to be linked with /SUBSYSTEM:WINDOWS
> on Windows because it is a GUI app, which uses different startup code than
> a console application.
> 
> The Boost.Test issue is a double definition of several symbols because some
> objects expect that they need to bring their own definition, while others
> link the shared library instead. Either is fine, but mixing is not allowed
> (but ELF linking silently overrides symbols from shared libraries).
> 
>Simon
> 
> Simon Richter (6):
>   Add missing include
>   Avoid nonstandard variable length array
>   Avoid initialization from non-constexpr
>   Avoid C-style array member init (illegal in C++)
>   Link pcb_test_window with /SUBSYSTEM:WINDOWS
>   Pass -DBOOST_TEST_DYN_LINK to all parts of test
> 
>  common/common_plotDXF_functions.cpp| 26 
> --
>  common/geometry/shape_poly_set.cpp |  5 +++--
>  eeschema/qa/CMakeLists.txt |  3 +++
>  eeschema/qa/test_module.cpp|  1 -
>  eeschema/sch_line.cpp  | 21 +++--
>  include/class_plotter.h|  1 -
>  include/utf8.h |  4 +++-
>  qa/pcb_test_window/CMakeLists.txt  |  2 +-
>  .../test_polygon_triangulation.cpp |  6 ++---
>  9 files changed, 41 insertions(+), 28 deletions(-)
> 
> 
> 
> ___
> 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] Fix artifacts on touchpad scroll (fixes lp:1735669)

[Andrey Kuznetsov]

Merge to get additional testing please. I can't compile source.

On Wed, Dec 6, 2017 at 4:21 PM, Wayne Stambaugh 
wrote:

> Has anyone else had a chance to test this or should I just merge it to
> get additional testing?
>
> On 12/04/2017 07:45 PM, Seth Hillbrand wrote:
> > ​This fixes artifacts remaining on the screen when touchpad scrolling is
> > enabled.
> > https://bugs.launchpad.net/kicad/+bug/1735669
> >
> > The attached patch is tested on MacOS and Linux.  Could someone with a
> > Windows laptop check that the performance of touchpad scrolling is not
> > affected?
> >
> > Thanks!
> > 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
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Fix artifacts on touchpad scroll (fixes lp:1735669)

[Wayne Stambaugh]

Has anyone else had a chance to test this or should I just merge it to
get additional testing?

On 12/04/2017 07:45 PM, Seth Hillbrand wrote:
> ​This fixes artifacts remaining on the screen when touchpad scrolling is
> enabled.
> https://bugs.launchpad.net/kicad/+bug/1735669
> 
> The attached patch is tested on MacOS and Linux.  Could someone with a
> Windows laptop check that the performance of touchpad scrolling is not
> affected?
> 
> Thanks!
> 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] Python: time_t needs mapping; tentative patch

[Wayne Stambaugh]

JP,

Would you please test this patch when you get a chance?  I took a quick
look at it and it seems correct but I don't know when I will have time
to test it.

Thanks,

Wayne

On 12/05/2017 12:00 PM, Henner Zeller wrote:
> Alright, here is a reworked patch that includes the ideas discussed here
> 
>   - Where we used to use time_t in the functions that deal with
> timestamps, this is now done with a new typedef timestamp_t that makes
> sure the c++ side and swigged Python side agree on the type.
>   - this typedef is now in common.h, close to the declaration of
> GetNewTimeStamp()
>   - The type of this type is 'long' as this makes sure that it is at
> least 32 bits. Trying to use something like int32_t did not work well
> with swig that seems to be more comfortable by default with the
> standard types (but some local Swig expert might know how to do this)
> 
> Cheers,
>   Henner.
> 

___
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 0/6] A few compatibility fixes

[Wayne Stambaugh]

On 12/06/2017 06:42 PM, Chris Pavlina wrote:
> On Wed, Dec 06, 2017 at 11:38:21PM +, Wayne Stambaugh wrote:
>> Simon,
>>
>> I'm OK with most of these patches but since when is it invalid to
>> initialize a c array in c++ (patch 4)?  Isn't c a subset of c++
> 
> No, no it is not.

OK, technically but practically every c++ compiler allows you to do this
so that is splitting hairs.

> 
>> or is
>> this just a fix to get kicad to compile with msvc?  If it's the latter,
>> the coding policy is pretty clear about that.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 12/05/2017 09:42 PM, Simon Richter wrote:
>>> Hi,
>>>
>>> these are a few things that cause build errors on MSVC, where gcc accepts
>>> invalid code. Most of them are obvious.
>>>
>>> The pcb_test_window executable needs to be linked with /SUBSYSTEM:WINDOWS
>>> on Windows because it is a GUI app, which uses different startup code than
>>> a console application.
>>>
>>> The Boost.Test issue is a double definition of several symbols because some
>>> objects expect that they need to bring their own definition, while others
>>> link the shared library instead. Either is fine, but mixing is not allowed
>>> (but ELF linking silently overrides symbols from shared libraries).
>>>
>>>Simon
>>>
>>> Simon Richter (6):
>>>   Add missing include
>>>   Avoid nonstandard variable length array
>>>   Avoid initialization from non-constexpr
>>>   Avoid C-style array member init (illegal in C++)
>>>   Link pcb_test_window with /SUBSYSTEM:WINDOWS
>>>   Pass -DBOOST_TEST_DYN_LINK to all parts of test
>>>
>>>  common/common_plotDXF_functions.cpp| 26 
>>> --
>>>  common/geometry/shape_poly_set.cpp |  5 +++--
>>>  eeschema/qa/CMakeLists.txt |  3 +++
>>>  eeschema/qa/test_module.cpp|  1 -
>>>  eeschema/sch_line.cpp  | 21 +++--
>>>  include/class_plotter.h|  1 -
>>>  include/utf8.h |  4 +++-
>>>  qa/pcb_test_window/CMakeLists.txt  |  2 +-
>>>  .../test_polygon_triangulation.cpp |  6 ++---
>>>  9 files changed, 41 insertions(+), 28 deletions(-)
>>>
>>>
>>>
>>> ___
>>> 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] [PATCH 0/6] A few compatibility fixes

[Seth Hillbrand]

Wayne-

That was my mistake.  C++ doesn't specify the C99 initialize by enum
reference.  So Simon is correct.

-S

On Wed, Dec 6, 2017 at 3:38 PM, Wayne Stambaugh 
wrote:

> Simon,
>
> I'm OK with most of these patches but since when is it invalid to
> initialize a c array in c++ (patch 4)?  Isn't c a subset of c++ or is
> this just a fix to get kicad to compile with msvc?  If it's the latter,
> the coding policy is pretty clear about that.
>
> Cheers,
>
> Wayne
>
> On 12/05/2017 09:42 PM, Simon Richter wrote:
> > Hi,
> >
> > these are a few things that cause build errors on MSVC, where gcc accepts
> > invalid code. Most of them are obvious.
> >
> > The pcb_test_window executable needs to be linked with /SUBSYSTEM:WINDOWS
> > on Windows because it is a GUI app, which uses different startup code
> than
> > a console application.
> >
> > The Boost.Test issue is a double definition of several symbols because
> some
> > objects expect that they need to bring their own definition, while others
> > link the shared library instead. Either is fine, but mixing is not
> allowed
> > (but ELF linking silently overrides symbols from shared libraries).
> >
> >Simon
> >
> > Simon Richter (6):
> >   Add missing include
> >   Avoid nonstandard variable length array
> >   Avoid initialization from non-constexpr
> >   Avoid C-style array member init (illegal in C++)
> >   Link pcb_test_window with /SUBSYSTEM:WINDOWS
> >   Pass -DBOOST_TEST_DYN_LINK to all parts of test
> >
> >  common/common_plotDXF_functions.cpp| 26
> --
> >  common/geometry/shape_poly_set.cpp |  5 +++--
> >  eeschema/qa/CMakeLists.txt |  3 +++
> >  eeschema/qa/test_module.cpp|  1 -
> >  eeschema/sch_line.cpp  | 21
> +++--
> >  include/class_plotter.h|  1 -
> >  include/utf8.h |  4 +++-
> >  qa/pcb_test_window/CMakeLists.txt  |  2 +-
> >  .../test_polygon_triangulation.cpp |  6 ++---
> >  9 files changed, 41 insertions(+), 28 deletions(-)
> >
> >
> >
> > ___
> > 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] [PATCH 0/6] A few compatibility fixes

[Chris Pavlina]

On Wed, Dec 06, 2017 at 11:38:21PM +, Wayne Stambaugh wrote:
> Simon,
> 
> I'm OK with most of these patches but since when is it invalid to
> initialize a c array in c++ (patch 4)?  Isn't c a subset of c++

No, no it is not.

> or is
> this just a fix to get kicad to compile with msvc?  If it's the latter,
> the coding policy is pretty clear about that.
> 
> Cheers,
> 
> Wayne
> 
> On 12/05/2017 09:42 PM, Simon Richter wrote:
> > Hi,
> > 
> > these are a few things that cause build errors on MSVC, where gcc accepts
> > invalid code. Most of them are obvious.
> > 
> > The pcb_test_window executable needs to be linked with /SUBSYSTEM:WINDOWS
> > on Windows because it is a GUI app, which uses different startup code than
> > a console application.
> > 
> > The Boost.Test issue is a double definition of several symbols because some
> > objects expect that they need to bring their own definition, while others
> > link the shared library instead. Either is fine, but mixing is not allowed
> > (but ELF linking silently overrides symbols from shared libraries).
> > 
> >Simon
> > 
> > Simon Richter (6):
> >   Add missing include
> >   Avoid nonstandard variable length array
> >   Avoid initialization from non-constexpr
> >   Avoid C-style array member init (illegal in C++)
> >   Link pcb_test_window with /SUBSYSTEM:WINDOWS
> >   Pass -DBOOST_TEST_DYN_LINK to all parts of test
> > 
> >  common/common_plotDXF_functions.cpp| 26 
> > --
> >  common/geometry/shape_poly_set.cpp |  5 +++--
> >  eeschema/qa/CMakeLists.txt |  3 +++
> >  eeschema/qa/test_module.cpp|  1 -
> >  eeschema/sch_line.cpp  | 21 +++--
> >  include/class_plotter.h|  1 -
> >  include/utf8.h |  4 +++-
> >  qa/pcb_test_window/CMakeLists.txt  |  2 +-
> >  .../test_polygon_triangulation.cpp |  6 ++---
> >  9 files changed, 41 insertions(+), 28 deletions(-)
> > 
> > 
> > 
> > ___
> > 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] [PATCH 0/6] A few compatibility fixes

[Wayne Stambaugh]

Simon,

I'm OK with most of these patches but since when is it invalid to
initialize a c array in c++ (patch 4)?  Isn't c a subset of c++ or is
this just a fix to get kicad to compile with msvc?  If it's the latter,
the coding policy is pretty clear about that.

Cheers,

Wayne

On 12/05/2017 09:42 PM, Simon Richter wrote:
> Hi,
> 
> these are a few things that cause build errors on MSVC, where gcc accepts
> invalid code. Most of them are obvious.
> 
> The pcb_test_window executable needs to be linked with /SUBSYSTEM:WINDOWS
> on Windows because it is a GUI app, which uses different startup code than
> a console application.
> 
> The Boost.Test issue is a double definition of several symbols because some
> objects expect that they need to bring their own definition, while others
> link the shared library instead. Either is fine, but mixing is not allowed
> (but ELF linking silently overrides symbols from shared libraries).
> 
>Simon
> 
> Simon Richter (6):
>   Add missing include
>   Avoid nonstandard variable length array
>   Avoid initialization from non-constexpr
>   Avoid C-style array member init (illegal in C++)
>   Link pcb_test_window with /SUBSYSTEM:WINDOWS
>   Pass -DBOOST_TEST_DYN_LINK to all parts of test
> 
>  common/common_plotDXF_functions.cpp| 26 
> --
>  common/geometry/shape_poly_set.cpp |  5 +++--
>  eeschema/qa/CMakeLists.txt |  3 +++
>  eeschema/qa/test_module.cpp|  1 -
>  eeschema/sch_line.cpp  | 21 +++--
>  include/class_plotter.h|  1 -
>  include/utf8.h |  4 +++-
>  qa/pcb_test_window/CMakeLists.txt  |  2 +-
>  .../test_polygon_triangulation.cpp |  6 ++---
>  9 files changed, 41 insertions(+), 28 deletions(-)
> 
> 
> 
> ___
> 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] Symbol library table remapping question

[Wayne Stambaugh]

On 12/06/2017 06:21 PM, Bernhard Stegmaier wrote:
> 
> 
>> On 7. Dec 2017, at 00:10, Wayne Stambaugh  wrote:

>>>
>>> So, I guess this won’t match as you said, or do you attempt to resolve
>>> the symlink for comparison?
>>
>> No, the correct remap is to use the same library that was being used
>> prior to the remapping.  I think this makes the most sense.
> 
> Well, technically this is the same library.
> It is only reachable by 2 different paths (the real and the symlinked one).

I could check for symlinks.  I'm not sure how much trouble it would be.
I'll take a look at it as soon as I get a chance.

> 
>>
>>> If you consider this a bug, I can file a bug report for it…
>>
>> I do not consider this a bug.  The remapping algorithm selected the
>> appropriate library.  I have the same issue on all of my systems because
>> I have so many versions of kicad installed simultaneously.  I suspect
>> this will be less of an issue for users who only have a single version
>> kicad installed.
> 
> OK, fine for me - even if I can imagine that if it really chose the 
> appropriate library could be discussed.
> But, you are right… probably won’t affect many users and at least I know how 
> to deal with it in my situation.
> 
> 
> Regards,
> Bernhard
> 

___
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] Simulator towards 5.0

[Wayne Stambaugh]

ccmake is only useful when you aren't interested in scripting builds.
It is a decent tool to discover the options but I would much prefer

cmake --show-options

to having to open up a GUI app.

On 12/06/2017 06:13 PM, Jacob Schmidt wrote:
> I got frustrated a while back because people were talking about the
> spice integration like it was a real thing, but I had never seen it.
> That lead me to google how to list cmake options, and I found ccmake.
> 
> ccmake is a wrapper around cmake that was useful to me. Maybe it will be
> for someone reading this.
> 
> 
> On 12/6/2017 8:04 AM, Wayne Stambaugh wrote:
>>
>> source.  Unfortunately, cmake does not have a command line switch that
>> allows you to view the build options and their default settings.
>> Autotools is far superior in this instance.  This is one of my pet
>> peeves with cmake.  Most of the software I have built over the years
>> typically only has the build options enabled for the features that will
>> build on all platforms.
> 
> 
> ___
> 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] Symbol library table remapping question

[Bernhard Stegmaier]

> On 7. Dec 2017, at 00:10, Wayne Stambaugh  wrote:
>>> 
>> 
>> So, I guess this won’t match as you said, or do you attempt to resolve
>> the symlink for comparison?
> 
> No, the correct remap is to use the same library that was being used
> prior to the remapping.  I think this makes the most sense.

Well, technically this is the same library.
It is only reachable by 2 different paths (the real and the symlinked one).

> 
>> If you consider this a bug, I can file a bug report for it…
> 
> I do not consider this a bug.  The remapping algorithm selected the
> appropriate library.  I have the same issue on all of my systems because
> I have so many versions of kicad installed simultaneously.  I suspect
> this will be less of an issue for users who only have a single version
> kicad installed.

OK, fine for me - even if I can imagine that if it really chose the appropriate 
library could be discussed.
But, you are right… probably won’t affect many users and at least I know how to 
deal with it in my situation.


Regards,
Bernhard


___
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] macOS GUI Quirks

[Wayne Stambaugh]

On 12/06/2017 11:40 AM, Bernhard Stegmaier wrote:
> Hi all,
> 
> as some of might know, I am working on macOS and some things seem to work a 
> bit different there (wrt KiCad).
> During my last project I came across some dialogs, widgets, etc. where 
> initial sizing is not correct (so, not all content is shown), etc.
> Mostly no real showstoppers, but leaves a very unprofessional impression…
> 
> I will try to reproduce those I can remember and try to fix them.
> I guess most of them only need some wisely placed Layout(), etc. calls to fix.
> 
> So, is there any document, guidelines, dos and don’ts, etc. how to achieve 
> maximum compatibility/portability with wx?
> Something like “place a Layout() at end of each dialog constructor”?

There is a UI policy in the developer docs at
http://docs.kicad-pcb.org/doxygen/md_Documentation_development_ui-policy.html.
 If we need to add any macos specific policies, I'm fine with that.  As
for placing layout in each ctor, you need to be careful here.  No all
dialogs use the ctor to initialize the control contents nor should they.
 The wx way is to override TransferDataTo/FromWindow or use validators
to accomplish this task but few of our dialogs follow this practice.
There are some differences between the ctor and the wx way which have to
do with event timing so you may have to modify your approach depending
on the dialog.

> 
> Of course, I don’t want to fix things on macOS and break it on Linux/Windows…
> 
> 
> Regards,
> Bernhard
> ___
> 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] Simulator towards 5.0

[Jacob Schmidt]

 I got frustrated a while back because people were talking about the spice
integration like it was a real thing, but I had never seen it. That lead me
to google how to list cmake options, and I found ccmake.

ccmake is a wrapper around cmake that was useful to me. Maybe it will be
for someone reading this.


On 12/6/2017 8:04 AM, Wayne Stambaugh wrote:


source.  Unfortunately, cmake does not have a command line switch that
allows you to view the build options and their default settings.
Autotools is far superior in this instance.  This is one of my pet
peeves with cmake.  Most of the software I have built over the years
typically only has the build options enabled for the features that will
build on all platforms.
___
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] Symbol library table remapping question

[Wayne Stambaugh]

On 12/06/2017 04:15 PM, Bernhard Stegmaier wrote:
> Hi Wayne,
> 
> Thanks for the explanation.
> 
>> On 6. Dec 2017, at 21:47, Wayne Stambaugh > > wrote:
>>
>> This all depends on the symbol library list and symbol library path
>> configuration of the project being remapped.  Here is how the remapping
>> works:
>>
>> Attempt to find the symbol in a library from the project library list.
>> This is the list of symbol libraries stored in the project file found
>> using the project and default lookup paths.
>>
>> If the symbol is found in any library but the cache, reconstruct the
>> full path to the symbol library.
>>
>> Search the global footprint library table for an entry matching the full
>> path.
> 
> OK, I might have found the problem.
> 
> In the *.pro file there was:
> <<<
> LibDir=/Users/bstegmaier/10 - Projekte/KiCad/Library
> [eeschema/libraries]
> LibName1=AtmelCorporation
> LibName2=Connectors
> LibName3=Devices
> LibName4=Displays
> LibName5=Power

> 
> I have 3 different machines, but with slightly different folder setup.
> To keep things simple, I used symlinks to make the library folder look
> the same.
> The path
>   /Users/bstegmaier/10 - Projekte/KiCad/Library
> Is what is used in all project files.
> It will be great to get rid of this by means of symbols-lib-table...
> 
> For the machine I used to test the remap the folder
>   /Users/bstegmaier/10 - Projekte/KiCad/Library
> Is actually a symlink to
>   /Volumes/OSXData/bstegmaier/10 - Projekte/KiCad
> 
> For the Devices library the remap-generated project table entry is
> <<<
> …
> (lib (name Devices1)(type Legacy)(uri "/Users/bstegmaier/10 -
> Projekte/KiCad/Library/Devices.lib")(options "")(descr ""))
> …

> 
> My global table has
> <<<
> …
> (lib (name Displays)(type Legacy)(uri
> ${KICAD_SYMBOL_DIR}/Displays.lib)(options "")(descr "Display devices"))
> …

> with ${KICAD_SYMBOL_DIR} being
>   /Volumes/OSXData/bstegmaier/10 - Projekte/KiCad/Library
> 
>> There a several reasons why this could happen depending your environment
>> variables, global system library table configuration, project symbol
>> library list, and any symbol library lookup paths added to the project.
> 
> So, I guess this won’t match as you said, or do you attempt to resolve
> the symlink for comparison?

No, the correct remap is to use the same library that was being used
prior to the remapping.  I think this makes the most sense.

> 
>> Is the full path and file name for Devices in the global symbol library
>> table the same as Devices1 in the project symbol library table?  If not,
>> then it's your configuration and the remapping is correct.  If the paths
>> are the same, then there is a bug in the remapping algorithm that I
>> missed.  If it's the latter, please file a bug report so I can fix it.
> 
> I did a quick check and set ${KICAD_SYMBOL_DIR} to
>   /Users/bstegmaier/10 - Projekte/KiCad/Library
> => the symlink to the real folder, the same as used in the *.pro file.
> 
> Remapping did work without problems then and didn’t create a project table.
> 
> If you consider this a bug, I can file a bug report for it…

I do not consider this a bug.  The remapping algorithm selected the
appropriate library.  I have the same issue on all of my systems because
I have so many versions of kicad installed simultaneously.  I suspect
this will be less of an issue for users who only have a single version
kicad installed.

> 
> 
> Thanks,
> Bernhard
> 
> 

___
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] Symbol library table remapping question

[Bernhard Stegmaier]

Hi Wayne,

Thanks for the explanation.

> On 6. Dec 2017, at 21:47, Wayne Stambaugh  wrote:
> 
> This all depends on the symbol library list and symbol library path
> configuration of the project being remapped.  Here is how the remapping
> works:
> 
> Attempt to find the symbol in a library from the project library list.
> This is the list of symbol libraries stored in the project file found
> using the project and default lookup paths.
> 
> If the symbol is found in any library but the cache, reconstruct the
> full path to the symbol library.
> 
> Search the global footprint library table for an entry matching the full
> path.

OK, I might have found the problem.

In the *.pro file there was:
<<<
LibDir=/Users/bstegmaier/10 - Projekte/KiCad/Library
[eeschema/libraries]
LibName1=AtmelCorporation
LibName2=Connectors
LibName3=Devices
LibName4=Displays
LibName5=Power
>>>

I have 3 different machines, but with slightly different folder setup.
To keep things simple, I used symlinks to make the library folder look the same.
The path
  /Users/bstegmaier/10 - Projekte/KiCad/Library
Is what is used in all project files.
It will be great to get rid of this by means of symbols-lib-table...

For the machine I used to test the remap the folder
  /Users/bstegmaier/10 - Projekte/KiCad/Library
Is actually a symlink to
  /Volumes/OSXData/bstegmaier/10 - Projekte/KiCad

For the Devices library the remap-generated project table entry is
<<<
…
(lib (name Devices1)(type Legacy)(uri "/Users/bstegmaier/10 - 
Projekte/KiCad/Library/Devices.lib")(options "")(descr ""))
…
>>>

My global table has
<<<
…
(lib (name Displays)(type Legacy)(uri ${KICAD_SYMBOL_DIR}/Displays.lib)(options 
"")(descr "Display devices"))
…
>>>
with ${KICAD_SYMBOL_DIR} being
  /Volumes/OSXData/bstegmaier/10 - Projekte/KiCad/Library

> There a several reasons why this could happen depending your environment
> variables, global system library table configuration, project symbol
> library list, and any symbol library lookup paths added to the project.

So, I guess this won’t match as you said, or do you attempt to resolve the 
symlink for comparison?

> Is the full path and file name for Devices in the global symbol library
> table the same as Devices1 in the project symbol library table?  If not,
> then it's your configuration and the remapping is correct.  If the paths
> are the same, then there is a bug in the remapping algorithm that I
> missed.  If it's the latter, please file a bug report so I can fix it.

I did a quick check and set ${KICAD_SYMBOL_DIR} to
  /Users/bstegmaier/10 - Projekte/KiCad/Library
=> the symlink to the real folder, the same as used in the *.pro file.

Remapping did work without problems then and didn’t create a project table.

If you consider this a bug, I can file a bug report for it…


Thanks,
Bernhard


___
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] Symbol library table remapping question

[Wayne Stambaugh]

On 12/6/2017 3:11 PM, Bernhard Stegmaier wrote:
> Hi Wayne,
> 
> Well, just think of me as a dumb user… :)
> First time that I updated to a version with sym-lib-table support (fresh from 
> git some hours ago).
> And yes, I read the blog post.
> Maybe I didn’t understand it… might be another story… :)
> 
> I decided to create a global sym-lib-table with all my libraries, just like 
> for fp-lib-table.
> Then, I created a new project and played around a bit.
> Everything fine.
> 
> Then, I decided to update an old project.
> Went through the remapping dialog, schematic looked to be fine afterwards.
> No missing symbols or bad things like that.
> 
> Then I saw that a project specific sym-lib-table has been created with a “1” 
> added to the end of (almost) all libraries used in that schematic.
> E.g., I now have “Devices” in my global table and “Devices1” in the local 
> table.
> The symbols have been remapped to e.g. “Devices1:Resistor”.
> 
> Is this really as expected?

This all depends on the symbol library list and symbol library path
configuration of the project being remapped.  Here is how the remapping
works:

Attempt to find the symbol in a library from the project library list.
This is the list of symbol libraries stored in the project file found
using the project and default lookup paths.

If the symbol is found in any library but the cache, reconstruct the
full path to the symbol library.

Search the global footprint library table for an entry matching the full
path.

If an entry in the global symbol library table matches this patch, remap
the symbol to the library nickname.

If the entry is not found in the global symbol library table, create a
new project specific symbol library table entry with a unique library
nickname.  This is why you see the number appended to the original
library file name.

Once all of the symbols are remapped, save the project library table if
any entries were added to the table.

There a several reasons why this could happen depending your environment
variables, global system library table configuration, project symbol
library list, and any symbol library lookup paths added to the project.

> The blog post states that “During the remapping process, symbol libraries not 
> found in the global symbol library table will be used to create a project 
> specific symbol library table.”
> I would have expected that symbols get remapped to the global table, i.e. to 
> “Devices:Resistor”.
> Note, that I didn’t change any library (file)name. 
> Maybe I chose another nickname here and there, but it obviously also didn’t 
> work with libraries with same nickname (like Devices).
> 
> If it is as expected, how would I go on with the project?
> Keep the local table?
> Looks pretty bad, because I also have duplicate entries in the component 
> selector then (e.g., a “Devices” and “Devices1”).

Is the full path and file name for Devices in the global symbol library
table the same as Devices1 in the project symbol library table?  If not,
then it's your configuration and the remapping is correct.  If the paths
are the same, then there is a bug in the remapping algorithm that I
missed.  If it's the latter, please file a bug report so I can fix it.

> 
> If not, rewrite everything by hand to use the global table?
> I wouldn’t have needed the remapping at all then… ?

Everything has to be remapped.  All symbol library links are required to
be fully qualified (LIB_NICKNAME:SYMBOL_NAME) in the schematic.  It will
fall back to the cache but you should *not* depend this unless you like
living dangerously.  If you don't believe me, delete the cache library
and don't remap your project.  Every symbol will be the lovely square
with two question marks indicating a missing symbol.

> 
> 
> Another thing:
> The remapping dialog has a “Cancel” button.
> In my opinion it doesn’t cancel anything, it just closes the window - 
> especially if you already had hit the “Remap Symbols” button.
> Users might be confused by this.
> Wouldn’t a “Close” make more sense?
> But, that’s something that is like that in more places with an “Apply” 
> button, e.g. the “Update PCB from Schematic” dialog in pcbnew.
> 
> 
> Regards,
> Bernhard
> ___
> 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] Symbol library table remapping question

[Bernhard Stegmaier]

Hi Wayne,

Well, just think of me as a dumb user… :)
First time that I updated to a version with sym-lib-table support (fresh from 
git some hours ago).
And yes, I read the blog post.
Maybe I didn’t understand it… might be another story… :)

I decided to create a global sym-lib-table with all my libraries, just like for 
fp-lib-table.
Then, I created a new project and played around a bit.
Everything fine.

Then, I decided to update an old project.
Went through the remapping dialog, schematic looked to be fine afterwards.
No missing symbols or bad things like that.

Then I saw that a project specific sym-lib-table has been created with a “1” 
added to the end of (almost) all libraries used in that schematic.
E.g., I now have “Devices” in my global table and “Devices1” in the local table.
The symbols have been remapped to e.g. “Devices1:Resistor”.

Is this really as expected?
The blog post states that “During the remapping process, symbol libraries not 
found in the global symbol library table will be used to create a project 
specific symbol library table.”
I would have expected that symbols get remapped to the global table, i.e. to 
“Devices:Resistor”.
Note, that I didn’t change any library (file)name. 
Maybe I chose another nickname here and there, but it obviously also didn’t 
work with libraries with same nickname (like Devices).

If it is as expected, how would I go on with the project?
Keep the local table?
Looks pretty bad, because I also have duplicate entries in the component 
selector then (e.g., a “Devices” and “Devices1”).

If not, rewrite everything by hand to use the global table?
I wouldn’t have needed the remapping at all then… ?


Another thing:
The remapping dialog has a “Cancel” button.
In my opinion it doesn’t cancel anything, it just closes the window - 
especially if you already had hit the “Remap Symbols” button.
Users might be confused by this.
Wouldn’t a “Close” make more sense?
But, that’s something that is like that in more places with an “Apply” button, 
e.g. the “Update PCB from Schematic” dialog in pcbnew.


Regards,
Bernhard
___
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] macOS GUI Quirks

[jp charras]

Le 06/12/2017 à 17:40, Bernhard Stegmaier a écrit :
> Hi all,
> 
> as some of might know, I am working on macOS and some things seem to work a 
> bit different there (wrt KiCad).
> During my last project I came across some dialogs, widgets, etc. where 
> initial sizing is not correct (so, not all content is shown), etc.
> Mostly no real showstoppers, but leaves a very unprofessional impression…
> 
> I will try to reproduce those I can remember and try to fix them.
> I guess most of them only need some wisely placed Layout(), etc. calls to fix.
> 
> So, is there any document, guidelines, dos and don’ts, etc. how to achieve 
> maximum compatibility/portability with wx?
> Something like “place a Layout() at end of each dialog constructor”?
> 
> Of course, I don’t want to fix things on macOS and break it on Linux/Windows…
> 
> 
> Regards,
> Bernhard

Hi Bernhard,

Most of our dialogs are (or should be) derived from DIALOG_SHIM class.

You should have a look at:
void DIALOG_SHIM::FinishDialogSettings()

that is (or should be) called in each dialog, and see if adding the call to 
Layout() fix these issues.

The call to Layout() should be automatically made be wxWidgets, so I am not 
sure adding the call to
Layout() fix issues, but it should not break Windows and Linux builds when 
explicitly calling it (it
will be just called twice).

Some dialogs use TransferDataToWindow() to initialize data in dialogs (this is 
the right way to
initialize user data), so perhaps Layout() must be called from this method.


-- 
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] [PATCH] Add double-click handling to disambiguation menu

[Chris Pavlina]

Every once in a while, someone submits a fix for a bug that I didn't
even remember existed, but that makes me want to hug them when it's
fixed.

On Wed, Dec 06, 2017 at 06:05:58PM +, Seth Hillbrand wrote:
> ​The attached patch fixes https://bugs.launchpad.net/kicad/+bug/1154020
> 
> The current double-click handler in draw_panel​ gets overridden by the
> disambiguation menu, preventing double-clicks from being properly handled.
> This patch introduces a delay between the mouse up and handling the
> single-click.  If the double-click arrives in this time, the double-click
> is handled.  Otherwise, the normal single-click is processed.
> 
> Of note, we only introduce this delay in cases where the disambiguation
> menu is needed.  Otherwise, single-clicks are immediately processed.
> 
> Tested on MacOS and Linux.  The current delay is set to 250ms.  We might
> slow this down to 400-500ms but that felt a bit clunky to me.
> 
> -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] Add double-click handling to disambiguation menu

[Seth Hillbrand]

​The attached patch fixes https://bugs.launchpad.net/kicad/+bug/1154020

The current double-click handler in draw_panel​ gets overridden by the
disambiguation menu, preventing double-clicks from being properly handled.
This patch introduces a delay between the mouse up and handling the
single-click.  If the double-click arrives in this time, the double-click
is handled.  Otherwise, the normal single-click is processed.

Of note, we only introduce this delay in cases where the disambiguation
menu is needed.  Otherwise, single-clicks are immediately processed.

Tested on MacOS and Linux.  The current delay is set to 250ms.  We might
slow this down to 400-500ms but that felt a bit clunky to me.

-Seth
From f81476ff706626adf461fedfb348c1656a887eaa Mon Sep 17 00:00:00 2001
From: Seth Hillbrand 
Date: Tue, 5 Dec 2017 21:25:52 -0800
Subject: [PATCH] wx: Add double-click handling in disambiguation cases

Fixes: lp:1154020
* https://bugs.launchpad.net/kicad/+bug/1154020
---
 common/draw_panel.cpp| 36 +++-
 eeschema/lib_collectors.cpp  | 12 
 eeschema/lib_collectors.h|  5 +
 eeschema/libedit_onleftclick.cpp |  2 +-
 eeschema/onleftclick.cpp |  2 +-
 eeschema/sch_collectors.cpp  | 14 ++
 eeschema/sch_collectors.h|  5 +
 include/class_drawpanel.h| 16 
 include/id.h |  2 ++
 9 files changed, 91 insertions(+), 3 deletions(-)

diff --git a/common/draw_panel.cpp b/common/draw_panel.cpp
index 716c1e0d2..bce9376fc 100644
--- a/common/draw_panel.cpp
+++ b/common/draw_panel.cpp
@@ -28,6 +28,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -87,6 +88,7 @@ BEGIN_EVENT_TABLE( EDA_DRAW_PANEL, wxScrolledWindow )
 EVT_ERASE_BACKGROUND( EDA_DRAW_PANEL::OnEraseBackground )
 EVT_SCROLLWIN( EDA_DRAW_PANEL::OnScroll )
 EVT_ACTIVATE( EDA_DRAW_PANEL::OnActivate )
+EVT_TIMER( ID_MOUSE_DOUBLECLICK, EDA_DRAW_PANEL::OnTimer )
 EVT_MENU_RANGE( ID_PAN_UP, ID_PAN_RIGHT, EDA_DRAW_PANEL::OnPan )
 END_EVENT_TABLE()
 
@@ -155,6 +157,9 @@ EDA_DRAW_PANEL::EDA_DRAW_PANEL( EDA_DRAW_FRAME* parent, int id,
 
 m_cursorLevel = 0;
 m_PrintIsMirrored = false;
+
+m_ClickTimer = (wxTimer*) NULL;
+m_doubleClickInterval = 250;
 }
 
 
@@ -168,6 +173,8 @@ EDA_DRAW_PANEL::~EDA_DRAW_PANEL()
 cfg->Write( ENBL_ZOOM_NO_CENTER_KEY, m_enableZoomNoCenter );
 cfg->Write( ENBL_AUTO_PAN_KEY, m_enableAutoPan );
 }
+
+wxDELETE( m_ClickTimer );
 }
 
 
@@ -404,6 +411,14 @@ void EDA_DRAW_PANEL::OnActivate( wxActivateEvent& event )
 }
 
 
+void EDA_DRAW_PANEL::OnTimer( wxTimerEvent& event )
+{
+INSTALL_UNBUFFERED_DC( DC, this );
+DC.SetBackground( *wxBLACK_BRUSH );
+GetParent()->OnLeftClick( , m_CursorClickPos );
+}
+
+
 void EDA_DRAW_PANEL::OnScroll( wxScrollWinEvent& event )
 {
 int id = event.GetEventType();
@@ -1145,6 +1160,11 @@ void EDA_DRAW_PANEL::OnMouseEvent( wxMouseEvent& event )
 // Calling Double Click and Click functions :
 if( localbutt == (int) ( GR_M_LEFT_DOWN | GR_M_DCLICK ) )
 {
+if( m_ClickTimer )
+{
+m_ClickTimer->Stop();
+wxDELETE( m_ClickTimer );
+}
 GetParent()->OnLeftDClick( , GetParent()->RefPos( true ) );
 
 // inhibit a response to the mouse left button release,
@@ -1162,7 +1182,21 @@ void EDA_DRAW_PANEL::OnMouseEvent( wxMouseEvent& event )
 m_ignoreNextLeftButtonRelease = false;
 
 if( screen->m_BlockLocate.GetState() == STATE_NO_BLOCK && !ignoreEvt )
-GetParent()->OnLeftClick( , GetParent()->RefPos( true ) );
+{
+EDA_ITEM* item = screen->GetCurItem();
+m_CursorClickPos = GetParent()->RefPos( true );
+
+// If we have an item already selected, or we are using a tool,
+// we won't use the disambiguation menu so process the click immediately
+if( ( item && item->GetFlags() ) || GetParent()->GetToolId() != ID_NO_TOOL_SELECTED )
+GetParent()->OnLeftClick( , m_CursorClickPos );
+else
+{
+wxDELETE( m_ClickTimer );
+m_ClickTimer = new wxTimer(this, ID_MOUSE_DOUBLECLICK);
+m_ClickTimer->StartOnce( m_doubleClickInterval );
+}
+}
 
 }
 else if( !event.LeftIsDown() )
diff --git a/eeschema/lib_collectors.cpp b/eeschema/lib_collectors.cpp
index 88af9d8f7..2a7f1750a 100644
--- a/eeschema/lib_collectors.cpp
+++ b/eeschema/lib_collectors.cpp
@@ -92,6 +92,18 @@ const KICAD_T LIB_COLLECTOR::RotatableItems[] = {
 };
 
 
+const KICAD_T LIB_COLLECTOR::DoubleClickItems[] = {
+LIB_PIN_T,
+LIB_ARC_T,
+LIB_CIRCLE_T,
+LIB_RECTANGLE_T,
+LIB_POLYLINE_T,
+LIB_TEXT_T,
+LIB_FIELD_T,
+EOT
+};
+
+
 SEARCH_RESULT LIB_COLLECTOR::Inspect( EDA_ITEM* aItem, void* testData )
 {
 LIB_ITEM* item = (LIB_ITEM*) 

Re: [Kicad-developers] Signal integrity simulation within Kicad

[Jon Evans]

Cool! I took a brief look at your code and looks like a good starting point
although I have not compiled it.

Unfortunately the legacy canvas cannot use the same draw call, as the
architecture is completely different.
To be honest, I would not worry about supporting the legacy canvas if I
were you -- we already have a number of features that are GAL-only, and I
think (project leaders can chime in here if I'm wrong) that it is fine to
propose GAL-only features (just not the other way around, meaning legacy
only).  The only reason the legacy canvas is still an option is because not
all features have been implemented in the GAL canvases yet.

Best,
Jon

On Wed, Dec 6, 2017 at 12:38 PM, Andreas Buhr 
wrote:

> Hi Jon,
>
> thanks a lot for your help.
>
> On 12/05/2017 03:51 PM, Jon Evans wrote:
> > For (2), the PCB_BASE_FRAME methods are for the legacy canvas, so I
> > wouldn't worry about implementing your feature there if I were you,
> > since it will eventually be removed.
> > The RATSNEST_VIEWITEM is what is used on the GAL (OpenGL/Cairo) canvases.
> >
> > Regarding the layer, you could use LAYER_GP_OVERLAY for prototyping, but
> > you are right that (at the moment) you can't add layers at runtime.
> > If you think that all of the simulation outputs can be drawn with a
> > single graphics layer, I think it is perfectly reasonable for you to
> > expand the enum with another layer definition.
> > You could use this new layer for your triangle mesh drawing, and then
> > use LAYER_GP_OVERLAY if you wanted to add any annotations to the
> > graphics perhaps? (meaning: measurements, etc, as is done with the
> > RULER_ITEM)
>
> Following the structure of the RATSNEST_VIEWITEM, I created a
> SI_MESH_VIEWITEM which should display the triangle mesh used in
> simulation. At the moment, my SI_MESH_VIEWITEM only displays a cross at
> position (0,0). It works fine for Cairo and OpenGL canvas.
> Is it possible to make the legacy canvas also use the
> VIEW_ITEM::ViewDraw() function?
>
> You can find my source code at
> https://github.com/andreasbuhr/kicad/commits/add_triangle_meshing
>
> thanks and best regards,
> Andreas
>
> >
> > -Jon
> >
> > On Tue, Dec 5, 2017 at 9:42 AM, Andreas Buhr  > > wrote:
> >
> > Dear Kicad developers,
> >
> > I am browsing the Kicad source code to get an idea how to integrate a
> > simulation tool.
> >
> > I'd like the following:
> >
> > 1. The plugin should be informed whenever something changes. It
> would be
> > great to get a bounding box of the change.
> > 2. The plugin should be able to draw on the canvas. I'd like to
> register
> > a new layer (for example to show the triangle mesh). The user should
> > then be able to enable/disable this layer.
> >
> > These two requirements are in some sense similar to the requirements
> of
> > "ratsnest", so I followed "ratsnest" through the code.
> >
> > Concerning (1):
> > I got the impression that it is not easy to be informed about all
> > changes in a BOARD. Is this correct?
> >
> > Concerning (2):
> > And I got the impression that there is not one way to draw to the
> > canvas. I found two drawing methods for ratsnest, one in
> PCB_BASE_FRAME,
> > the other in RATSNEST_VIEWITEM::ViewDraw. Is it necessary to
> implement
> > two drawing methods for each feature?
> >
> > And it seems that the layers are organized in an enum
> (GAL_LAYER_ID), so
> > adding a layer at runtime seems impossible without larger
> infrastructure
> > changes. Is this correct?
> >
> > What would you propose? How can a plugin be informed about all
> changes
> > to the board? And how could a plugin draw on the canvas?
> >
> > thanks a lot in advance,
> > Cheers,
> > Andreas
> >
> >
> > On 11/30/2017 12:18 AM, Wayne Stambaugh wrote:
> > > Hi Andreas,
> > >
> > > Per our previous conversation, if you want to write your solver in
> > C++,
> > > then I would prefer that you do it as part of a solver plugin
> rather
> > > than a command event handler in Pcbnew.  I image there would be
> other
> > > uses for a solver plugin object such as a thermal mapping solver
> which
> > > has been proposed in the past.  The other option would be to use
> the
> > > Python action object and write the entire solver in Python rather
> than
> > > C++.  That may make your life a bit easier.
> > >
> > > Cheers,
> > >
> > > Wayne
> > >
> > > On 11/29/2017 01:09 PM, Andreas Buhr wrote:
> > >> Dear Kicad developers,
> > >>
> > >> I'm new to Kicad development. Maybe you could give me some
> > starting tips?
> > >>
> > >> I am a 5th year PhD student at the university of Münster in
> Germany,
> > >> website:
> > >>
> > https://www.uni-muenster.de/AMM/en/ohlberger/team/andreas_buhr.shtml
> > 

Re: [Kicad-developers] Signal integrity simulation within Kicad

[Andreas Buhr]

Hi Jon,

thanks a lot for your help.

On 12/05/2017 03:51 PM, Jon Evans wrote:
> For (2), the PCB_BASE_FRAME methods are for the legacy canvas, so I
> wouldn't worry about implementing your feature there if I were you,
> since it will eventually be removed.
> The RATSNEST_VIEWITEM is what is used on the GAL (OpenGL/Cairo) canvases.
> 
> Regarding the layer, you could use LAYER_GP_OVERLAY for prototyping, but
> you are right that (at the moment) you can't add layers at runtime.
> If you think that all of the simulation outputs can be drawn with a
> single graphics layer, I think it is perfectly reasonable for you to
> expand the enum with another layer definition.
> You could use this new layer for your triangle mesh drawing, and then
> use LAYER_GP_OVERLAY if you wanted to add any annotations to the
> graphics perhaps? (meaning: measurements, etc, as is done with the
> RULER_ITEM)

Following the structure of the RATSNEST_VIEWITEM, I created a
SI_MESH_VIEWITEM which should display the triangle mesh used in
simulation. At the moment, my SI_MESH_VIEWITEM only displays a cross at
position (0,0). It works fine for Cairo and OpenGL canvas.
Is it possible to make the legacy canvas also use the
VIEW_ITEM::ViewDraw() function?

You can find my source code at
https://github.com/andreasbuhr/kicad/commits/add_triangle_meshing

thanks and best regards,
Andreas

> 
> -Jon
> 
> On Tue, Dec 5, 2017 at 9:42 AM, Andreas Buhr  > wrote:
> 
> Dear Kicad developers,
> 
> I am browsing the Kicad source code to get an idea how to integrate a
> simulation tool.
> 
> I'd like the following:
> 
> 1. The plugin should be informed whenever something changes. It would be
> great to get a bounding box of the change.
> 2. The plugin should be able to draw on the canvas. I'd like to register
> a new layer (for example to show the triangle mesh). The user should
> then be able to enable/disable this layer.
> 
> These two requirements are in some sense similar to the requirements of
> "ratsnest", so I followed "ratsnest" through the code.
> 
> Concerning (1):
> I got the impression that it is not easy to be informed about all
> changes in a BOARD. Is this correct?
> 
> Concerning (2):
> And I got the impression that there is not one way to draw to the
> canvas. I found two drawing methods for ratsnest, one in PCB_BASE_FRAME,
> the other in RATSNEST_VIEWITEM::ViewDraw. Is it necessary to implement
> two drawing methods for each feature?
> 
> And it seems that the layers are organized in an enum (GAL_LAYER_ID), so
> adding a layer at runtime seems impossible without larger infrastructure
> changes. Is this correct?
> 
> What would you propose? How can a plugin be informed about all changes
> to the board? And how could a plugin draw on the canvas?
> 
> thanks a lot in advance,
> Cheers,
> Andreas
> 
> 
> On 11/30/2017 12:18 AM, Wayne Stambaugh wrote:
> > Hi Andreas,
> >
> > Per our previous conversation, if you want to write your solver in
> C++,
> > then I would prefer that you do it as part of a solver plugin rather
> > than a command event handler in Pcbnew.  I image there would be other
> > uses for a solver plugin object such as a thermal mapping solver which
> > has been proposed in the past.  The other option would be to use the
> > Python action object and write the entire solver in Python rather than
> > C++.  That may make your life a bit easier.
> >
> > Cheers,
> >
> > Wayne
> >
> > On 11/29/2017 01:09 PM, Andreas Buhr wrote:
> >> Dear Kicad developers,
> >>
> >> I'm new to Kicad development. Maybe you could give me some
> starting tips?
> >>
> >> I am a 5th year PhD student at the university of Münster in Germany,
> >> website:
> >>
> https://www.uni-muenster.de/AMM/en/ohlberger/team/andreas_buhr.shtml
> 
> >>
> >> I am doing mathematical research targeted at developing solvers
> for 3D
> >> Maxwell's equations in highly complex structures, such as PCBs. While
> >> being in an early stage, the goal is to develop a signal integrity
> >> solver which does a full-wave simulation of the electromagnetic
> fields
> >> and calculates S-parameters within a very short time.
> >>
> >> I would love to develop and test my algorithms within KiCad.
> >>
> >> The input which my solver needs would be an array of polygons,
> >> representing the copper-filled areas on each layer.
> >> I then want to create a 2D triangle mesh and based on that a 3D prism
> >> mesh for finite element analysis.
> >>
> >> What would you recommend? How to I get polygons, representing the
> copper
> >> filled areas of each layer?
> >> I do have some 

[Kicad-developers] macOS GUI Quirks

[Bernhard Stegmaier]

Hi all,

as some of might know, I am working on macOS and some things seem to work a bit 
different there (wrt KiCad).
During my last project I came across some dialogs, widgets, etc. where initial 
sizing is not correct (so, not all content is shown), etc.
Mostly no real showstoppers, but leaves a very unprofessional impression…

I will try to reproduce those I can remember and try to fix them.
I guess most of them only need some wisely placed Layout(), etc. calls to fix.

So, is there any document, guidelines, dos and don’ts, etc. how to achieve 
maximum compatibility/portability with wx?
Something like “place a Layout() at end of each dialog constructor”?

Of course, I don’t want to fix things on macOS and break it on Linux/Windows…


Regards,
Bernhard
___
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] Simulator towards 5.0

[Kristoffer Ödmark]

Are we not in feature freeze, the features that I enabled by default is 
from my understanding the ones that will be built into the official 
ones. And yes, the people that are compiling a non-standard install 
shuld be savvy enough to be change the compilation settings. That is why 
i think the default build should reflect the ones being run by the less 
savvy users.


 -Kristoffer

On 12/06/2017 11:31 AM, Simon Richter wrote:

Hi,

On 06.12.2017 11:12, Kristoffer Ödmark wrote:


I do not see why anyone is even objecting to this? Where is the logic at
having a default build that does not correspond to any of the official
packages?!


That usually happens because the nightly builds enable all the
experimental features to allow people to test them, but the default is
still "disabled" because they introduce extra dependencies and make life
difficult for people compiling from source.

The default for new options needs to be decided before the release, I
think, and "release" packages should go with that.

Simon



___
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] Zone filling

[Maciej Sumiński]

Hi Heikki,

I might have not understood the question, would you please rephrase it?
I assumed you are asking why your code has not been merged and Tom's has
been accepted.

Regards,
Orson

On 12/06/2017 11:45 AM, Heikki Pulkkinen wrote:
> Hi Maciej
> 
> You did not answer my question, and those are only excuses.
> 
> Regards
> 
> Heikki
> 
> 
> On Wed, Dec 6, 2017 at 12:12 PM, Maciej Sumiński 
> wrote:
> 
>> Hi Heikki,
>>
>> Your branch contains a lot of code that is not in the official
>> repository and should not be merged (different connectivity algorithm,
>> alternative way for via stitching interleaved with numerous #ifdef).
>> There is no easy way to apply your changes to the master branch, as they
>> have diverged too much. We could not simply copy viastitching_pcbnew.cpp
>> to the master branch and have fast zone filling algorithm. What did you
>> expect us to do in such case?
>>
>> Regards,
>> Orson
>>
>> On 12/06/2017 10:47 AM, Heikki Pulkkinen wrote:
>>> Hi,
>>>
>>> I tested that new filling, and there is no improvement against with my
>>> parallel filling algo witch idea Tomasz copied.
>>>
>>> olinuxino A64,my 13s, new 12s.
>>> WRS, my 1min 43s, new 1min 44s.
>>>
>>> What is the meaning of rules?
>>>
>>>
>>> Regards
>>>
>>>
>>> Heikki
>>>
>>>
>>>
>>> ___
>>> 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
>>
>>
> 




signature.asc
Description: OpenPGP digital signature
___
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] Simulator towards 5.0

[Wayne Stambaugh]

On 12/5/2017 12:31 PM, Simon Richter wrote:
> Hi,
> 
> On 05.12.2017 17:30, Maciej Sumiński wrote:
> 
>> When you build a program, do you always go through its build manual or
>> do you start with 'cmake .. && make'? I think there is no point
>> enforcing an optional dependency. Another good solution would be to
>> autodetect libngspice and enable the simulator if it is available.
> 
> With my packaging hat on: please don't. It is really annoying to find
> out that a build dependency changed when users complain about entire
> features going missing.
> 
>Simon

This is why I have not turned these build options on.  From my
experience, most package devs would prefer not having every option
turned on and then fail to build.  The kicad project cannot know what
dependencies will be available on every platform so it is the
responsibility of the package dev to determine this and configure their
kicad build accordingly.  As for developers, if you are savvy enough to
build kicad from source, you should be more than capable of looking up
the build options.  If not, you shouldn't be compiling kicad from
source.  Unfortunately, cmake does not have a command line switch that
allows you to view the build options and their default settings.
Autotools is far superior in this instance.  This is one of my pet
peeves with cmake.  Most of the software I have built over the years
typically only has the build options enabled for the features that will
build on all platforms.

___
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] Component table view initial columns sizing

[Wayne Stambaugh]

Bernhard,

I tested your patch on windows and linux and everything looked fine so I
merged it into the development branch.

Thanks,

Wayne

On 12/5/2017 3:37 PM, Bernhard Stegmaier wrote:
> Wayne,
> 
> No problem… never used it before, but always good to learn something new… :)
> Attached.
> 
> 
> Regards,
> Bernhard
> 
> 
> 
> 
> 
>> On 5. Dec 2017, at 20:47, Wayne Stambaugh > > wrote:
>>
>> Bernhard,
>>
>> Please resend the patch using `git format-patch`.  This makes it a lot
>> easier to apply patches and push to master if they are ready to go.
>>
>> Thanks,
>>
>> Wayne
>>
>> On 12/5/2017 2:16 PM, Bernhard Stegmaier wrote:
>>> Wayne,
>>>
>>> I created it just by directing a “git show” to a file.
>>> I could apply it to master using “patch -p1 < xxx.patch”.
>>> Of course, I can also try to use “git formal-patch” and resend…
>>>
>>>
>>> Regards,
>>> Bernhard
>>>
 On 5. Dec 2017, at 19:45, Wayne Stambaugh 
 > wrote:

 Bernhard,

 I just tried to merge this patch using `git am` and I'm getting this
 error:

 fatal: empty ident name (for <>) not allowed

 It looks like you didn't create this patch using `git format-patch`
 and/or you do not have your user name and/or user email set in your git
 config.

 Cheers,

 Wayne

 T
 On 12/5/2017 8:02 AM, Bernhard Stegmaier wrote:
> Hi,
>
> attached patch fixes initial sizing of “Fields” table columns of
> component table view.
>
> Only tested on macOS.
> Please check also on Linux/Windows as I removed some IMHO
> unneeded/duplicate Update() (and other) calls.
>
> Before:
>
>
>
>
>
> After:
>
>
>
>
>
>
> Regards,
> Bernhard
>
>
>
> ___
> 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] Simulator towards 5.0

[Simon Richter]

Hi,

On 06.12.2017 11:12, Kristoffer Ödmark wrote:

> I do not see why anyone is even objecting to this? Where is the logic at
> having a default build that does not correspond to any of the official
> packages?!

That usually happens because the nightly builds enable all the
experimental features to allow people to test them, but the default is
still "disabled" because they introduce extra dependencies and make life
difficult for people compiling from source.

The default for new options needs to be decided before the release, I
think, and "release" packages should go with that.

   Simon



signature.asc
Description: OpenPGP digital signature
___
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] Simulator towards 5.0

[Maciej Sumiński]

The subtle difference is your resolve wx dependency with 'apt-get
install libwxgtk' and to get libngspice you need to cast a few spells
when there is no package.

On 12/05/2017 06:02 PM, Nick Østergaard wrote:
> But it would also fail to build if you did not install wx.
> 
> Den 5. dec. 2017 5.21 PM skrev "Kevin Cozens" :
> 
> On 2017-12-05 09:05 AM, Kristoffer Ödmark wrote:
> 
>> Here I attach a small patch that changes the default compile-flags to the
>> ones in the released packages.
>>
> 
> Enabling SPICE support by default will break my build unless I turn it off.
> 
> Seeing a recent message about SPICE support I wanted to have a look at the
> feature. I found out I needed to install ngspice. I then found out that the
> copy of ngspice available in the standard repos for Linux Mint doesn't
> include the lib file needed to compile and link KiCad with SPICE support.
> 
> 
> 
> ___
> 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
> 




signature.asc
Description: OpenPGP digital signature
___
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] Zone filling

[Maciej Sumiński]

Hi Heikki,

Your branch contains a lot of code that is not in the official
repository and should not be merged (different connectivity algorithm,
alternative way for via stitching interleaved with numerous #ifdef).
There is no easy way to apply your changes to the master branch, as they
have diverged too much. We could not simply copy viastitching_pcbnew.cpp
to the master branch and have fast zone filling algorithm. What did you
expect us to do in such case?

Regards,
Orson

On 12/06/2017 10:47 AM, Heikki Pulkkinen wrote:
> Hi,
> 
> I tested that new filling, and there is no improvement against with my
> parallel filling algo witch idea Tomasz copied.
> 
> olinuxino A64,my 13s, new 12s.
> WRS, my 1min 43s, new 1min 44s.
> 
> What is the meaning of rules?
> 
> 
> Regards
> 
> 
> Heikki
> 
> 
> 
> ___
> 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
> 




signature.asc
Description: OpenPGP digital signature
___
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] Simulator towards 5.0

[Kristoffer Ödmark]

I sent the wrong patch before attached the correct now. Silently 
compiling something else then what was expected is much much worse than 
failing.


I do not see why anyone is even objecting to this? Where is the logic at 
having a default build that does not correspond to any of the official 
packages?!


If i build a software I expect to get the same as the official version, 
unless i specify some custom options, currently I am not even getting 
the same version as the official by reading the compilation steps in the 
docs currently.


The error message for spice even details how to get the correct spice 
library and with this even tells how to disable it if you wish to build 
without it.


 -Kristoffer

On 12/05/2017 06:31 PM, Simon Richter wrote:

Hi,

On 05.12.2017 17:30, Maciej Sumiński wrote:


When you build a program, do you always go through its build manual or
do you start with 'cmake .. && make'? I think there is no point
enforcing an optional dependency. Another good solution would be to
autodetect libngspice and enable the simulator if it is available.


With my packaging hat on: please don't. It is really annoying to find
out that a build dependency changed when users complain about entire
features going missing.

Simon



___
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

>From c993c2df02b1402099cc2999c75f554f860da91a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Kristoffer=20=C3=96dmark?= 
Date: Tue, 5 Dec 2017 14:33:10 +0100
Subject: [PATCH] Changed default compile-flags to match released packages This
 makes it easier to build like in the the official packages added a message on
 how to compile without spice support if needed

---
 CMakeLists.txt | 28 +---
 Documentation/development/compiling.md | 18 +++---
 2 files changed, 24 insertions(+), 22 deletions(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index c70a34237..90dd8f99d 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -54,24 +54,24 @@ option( USE_WX_OVERLAY
 "Use wxOverlay: Always ON for MAC (default OFF).  Warning, this is experimental" )
 
 option( KICAD_SCRIPTING
-"Build the Python scripting support inside KiCad binaries (default OFF)."
-)
+"Build the Python scripting support inside KiCad binaries (default ON)."
+ON )
 
 option( KICAD_SCRIPTING_MODULES
 "Build native portion of the pcbnew Python module: _pcbnew.{pyd,so} for OS command line use of Python."
-)
+ON )
 
 option( KICAD_SCRIPTING_WXPYTHON
-"Build wxPython implementation for wx interface building in Python and py.shell (default OFF)."
-)
+"Build wxPython implementation for wx interface building in Python and py.shell (default ON)."
+ON )
 
 option( KICAD_SCRIPTING_ACTION_MENU
-"Build a tools menu with registred python plugins: actions plugins (default OFF)."
-)
+"Build a tools menu with registred python plugins: actions plugins (default ON)."
+ON )
 
 option( KICAD_USE_OCE
-"Build tools and plugins related to OpenCascade Community Edition (default OFF)"
-)
+"Build tools and plugins related to OpenCascade Community Edition (default ON)"
+ON )
 
 option( KICAD_INSTALL_DEMOS
 "Install kicad demos and examples (default ON)"
@@ -97,7 +97,7 @@ endif()
 
 option( BUILD_GITHUB_PLUGIN "Build the GITHUB_PLUGIN for pcbnew." ON )
 
-option( KICAD_SPICE "Build Kicad with internal Spice simulator." OFF )
+option( KICAD_SPICE "Build Kicad with internal Spice simulator." ON )
 
 # Global setting: exports are explicit
 set( CMAKE_CXX_VISIBILITY_PRESET "hidden" )
@@ -554,7 +554,13 @@ endif()
 
 # Find ngspice library, required for integrated circuit simulator
 if( KICAD_SPICE )
-find_package( ngspice REQUIRED )
+find_package( ngspice )
+
+if( NOT NGSPICE_FOUND )
+message( FATAL_ERROR "Required ngspice library not found, to \
+compile kicad without integrated circuit simulator, run cmake with \
+-DKICAD_SPICE=OFF" )
+endif()
 endif()
 
 # Find OpenCascade Community Edition, required for STEP plugin and tools
diff --git a/Documentation/development/compiling.md b/Documentation/development/compiling.md
index 43d388235..2646eb5e6 100644
--- a/Documentation/development/compiling.md
+++ b/Documentation/development/compiling.md
@@ -132,17 +132,17 @@ on macOS.  This is enabled on macOS by default and disabled on all other platfor
 ## Scripting Support ## {#scripting_opt}
 
 The KICAD_SCRIPTING option is used to enable building the Python scripting support into Pcbnew.
-This options is disabled by default.
+This options is enabled by default.
 
 ## Scripting Module Support ## {#scripting_mod_opt}
 
 The KICAD_SCRIPTING_MODULES option is used to enable building and installing 

[Kicad-developers] Zone filling

[Heikki Pulkkinen]

Hi,

I tested that new filling, and there is no improvement against with my
parallel filling algo witch idea Tomasz copied.

olinuxino A64,my 13s, new 12s.
WRS, my 1min 43s, new 1min 44s.

What is the meaning of rules?


Regards


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