Re: [Kicad-developers] [PATCH] Show message panel info for highlighted net in GAL (Fixes lp:1518626)

[jp charras]

Le 28/11/2017 à 03:08, Jon Evans a écrit :
> Hi all,
> 
> Another quick fix for a behavior difference between GAL and legacy.
> 
> -Jon
> 

Hi Jon,
I committed your patch. Thanks.


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

[Kicad-developers] [PATCH] Preserve color scheme when switching to legacy (Fixes lp:1670669)

[Jon Evans]

Hi all,

This patch changes the color scheme behavior when switching between GAL and
legacy canvases.  Previously, the switch would cause all colors to be
mutated to "legacy safe" versions.  Now, switching to legacy just sets a
flag that causes the colors to be returned from the COLORS_DESIGN_SETTINGS
as "legacy safe" while preserving the underlying colors.

-Jon
From f5ce890d7538aeaafb3bfde19eae71e933ed7616 Mon Sep 17 00:00:00 2001
From: Jon Evans 
Date: Mon, 27 Nov 2017 22:12:31 -0500
Subject: [PATCH] Preserve color scheme when switching to legacy (Fixes
 lp:1670669)

Instead of modifying the colors when switching to legacy canvas,
they will now be preserved and only returned as the "legacy" colors.
---
 common/class_colors_design_settings.cpp |  7 +--
 common/gal/color4d.cpp  |  2 +-
 gerbview/gerbview_frame.cpp | 17 -
 gerbview/gerbview_frame.h   |  3 ---
 include/class_colors_design_settings.h  | 16 
 include/draw_frame.h|  6 --
 include/gal/color4d.h   |  7 ++-
 pcbnew/pcbframe.cpp | 23 ++-
 pcbnew/wxPcbStruct.h|  3 ---
 9 files changed, 38 insertions(+), 46 deletions(-)

diff --git a/common/class_colors_design_settings.cpp b/common/class_colors_design_settings.cpp
index b030c072b..749ecfbc2 100644
--- a/common/class_colors_design_settings.cpp
+++ b/common/class_colors_design_settings.cpp
@@ -96,6 +96,7 @@ static const EDA_COLOR_T default_items_color[] = {
 COLORS_DESIGN_SETTINGS::COLORS_DESIGN_SETTINGS( FRAME_T aFrameType )
 {
 m_frameType = aFrameType;
+m_legacyMode = false;
 
 for( unsigned src = 0, dst = 0; dst < DIM( m_LayersColors ); ++dst )
 {
@@ -124,7 +125,8 @@ COLOR4D COLORS_DESIGN_SETTINGS::GetLayerColor( LAYER_NUM aLayer ) const
 {
 if( (unsigned) aLayer < DIM( m_LayersColors ) )
 {
-return m_LayersColors[aLayer];
+return m_legacyMode ? m_LayersColors[aLayer].AsLegacyColor()
+: m_LayersColors[aLayer];
 }
 return COLOR4D::UNSPECIFIED;
 }
@@ -143,7 +145,8 @@ COLOR4D COLORS_DESIGN_SETTINGS::GetItemColor( int aItemIdx ) const
 {
 if( (unsigned) aItemIdx < DIM( m_LayersColors ) )
 {
-return m_LayersColors[aItemIdx];
+return m_legacyMode ? m_LayersColors[aItemIdx].AsLegacyColor()
+: m_LayersColors[aItemIdx];
 }
 
 return COLOR4D::UNSPECIFIED;
diff --git a/common/gal/color4d.cpp b/common/gal/color4d.cpp
index 4af7003fd..11b4366e3 100644
--- a/common/gal/color4d.cpp
+++ b/common/gal/color4d.cpp
@@ -144,7 +144,7 @@ COLOR4D::COLOR4D( EDA_COLOR_T aColor )
 }
 
 
-EDA_COLOR_T COLOR4D::GetNearestLegacyColor( COLOR4D &aColor )
+EDA_COLOR_T COLOR4D::GetNearestLegacyColor( const COLOR4D &aColor )
 {
 // Cache layer implemented here, because all callers are using wxColour
 static std::map< unsigned int, unsigned int > nearestCache;
diff --git a/gerbview/gerbview_frame.cpp b/gerbview/gerbview_frame.cpp
index d938237e0..a6abcc558 100644
--- a/gerbview/gerbview_frame.cpp
+++ b/gerbview/gerbview_frame.cpp
@@ -221,7 +221,7 @@ GERBVIEW_FRAME::GERBVIEW_FRAME( KIWAY* aKiway, wxWindow* aParent ):
 }
 else
 {
-forceColorsToLegacy();
+m_colorsSettings->SetLegacyMode( true );
 m_canvas->Refresh();
 }
 
@@ -1039,17 +1039,6 @@ void GERBVIEW_FRAME::unitsChangeRefresh()
 }
 
 
-void GERBVIEW_FRAME::forceColorsToLegacy()
-{
-for( int i = 0; i < LAYER_ID_COUNT; i++ )
-{
-COLOR4D c = m_colorsSettings->GetLayerColor( i );
-c.SetToNearestLegacyColor();
-m_colorsSettings->SetLayerColor( i, c );
-}
-}
-
-
 void GERBVIEW_FRAME::UseGalCanvas( bool aEnable )
 {
 EDA_DRAW_FRAME::UseGalCanvas( aEnable );
@@ -1065,6 +1054,8 @@ void GERBVIEW_FRAME::UseGalCanvas( bool aEnable )
 if( m_toolManager )
 m_toolManager->ResetTools( TOOL_BASE::GAL_SWITCH );
 
+m_colorsSettings->SetLegacyMode( false );
+
 galCanvas->GetGAL()->SetGridColor( GetLayerColor( LAYER_GERBVIEW_GRID ) );
 
 galCanvas->GetView()->RecacheAllItems();
@@ -1081,7 +1072,7 @@ void GERBVIEW_FRAME::UseGalCanvas( bool aEnable )
 // Redirect all events to the legacy canvas
 galCanvas->SetEventDispatcher( NULL );
 
-forceColorsToLegacy();
+m_colorsSettings->SetLegacyMode( true );
 m_canvas->Refresh();
 }
 
diff --git a/gerbview/gerbview_frame.h b/gerbview/gerbview_frame.h
index d35ea8f1e..c0d8ecd0f 100644
--- a/gerbview/gerbview_frame.h
+++ b/gerbview/gerbview_frame.h
@@ -173,9 +173,6 @@ protected:
 /// The last filename chosen to be proposed to the user
 wxStringm_lastFileName;
 
-///> @copydoc EDA_DRAW_FRAME::forceColorsToLegacy()
-virtual void forceColorsToLegacy() override;
-
 public:
 wxChoice* m_SelComponentBox;// a c

[Kicad-developers] [PATCH] Show message panel info for highlighted net in GAL (Fixes lp:1518626)

[Jon Evans]

Hi all,

Another quick fix for a behavior difference between GAL and legacy.

-Jon
From b293e78f3a67a4ffaf86a3834c8cf9c24a23471e Mon Sep 17 00:00:00 2001
From: Jon Evans 
Date: Mon, 27 Nov 2017 21:07:59 -0500
Subject: [PATCH] Show message panel info for highlighted net in GAL (Fixes
 lp:1518626)

---
 pcbnew/tools/pcb_editor_control.cpp | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/pcbnew/tools/pcb_editor_control.cpp b/pcbnew/tools/pcb_editor_control.cpp
index 28c060298..f19a0e874 100644
--- a/pcbnew/tools/pcb_editor_control.cpp
+++ b/pcbnew/tools/pcb_editor_control.cpp
@@ -1069,9 +1069,23 @@ static bool highlightNet( TOOL_MANAGER* aToolMgr, const VECTOR2D& aPosition )
 
 // Store the highlighted netcode in the current board (for dialogs for instance)
 if( enableHighlight && net >= 0 )
+{
 board->SetHighLightNet( net );
+
+NETINFO_ITEM* netinfo = board->FindNet( net );
+
+if( netinfo )
+{
+MSG_PANEL_ITEMS items;
+netinfo->GetMsgPanelInfo( items );
+frame->SetMsgPanel( items );
+}
+}
 else
+{
 board->ResetHighLight();
+frame->SetMsgPanel( board );
+}
 
 return true;
 }
-- 
2.14.1

___
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] Allow changing LAYER_PADS color and visibility (Fixes lp:1672646)

[Jon Evans]

Hi all,

This adds LAYER_PADS to the render settings that are accessible to the
user, meaning you can change the color or hide this layer now.

Best,
Jon
From f4fe87ffcbfaed7a0a23cba54d3e126dfe5c Mon Sep 17 00:00:00 2001
From: Jon Evans 
Date: Mon, 27 Nov 2017 20:20:00 -0500
Subject: [PATCH] Allow changing LAYER_PADS color and visibility (Fixes
 lp:1672646)

---
 common/class_colors_design_settings.cpp | 6 --
 pcbnew/class_pcb_layer_widget.cpp   | 1 +
 pcbnew/pcb_painter.cpp  | 3 +--
 3 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/common/class_colors_design_settings.cpp b/common/class_colors_design_settings.cpp
index b030c072b..4060ce163 100644
--- a/common/class_colors_design_settings.cpp
+++ b/common/class_colors_design_settings.cpp
@@ -85,8 +85,10 @@ static const EDA_COLOR_T default_items_color[] = {
 DARKGRAY,  // LAYER_GRID
 LIGHTRED,  // LAYER_GRID_AXES
 BLUE,  // LAYER_NO_CONNECTS
-LIGHTGRAY, LIGHTGRAY,
-LIGHTGRAY, LIGHTGRAY, LIGHTGRAY, LIGHTGRAY,
+LIGHTGRAY, LIGHTGRAY,   // LAYER_MOD_FR, LAYER_MOD_BK
+LIGHTGRAY, LIGHTGRAY,   // LAYER_MOD_VALUES, LAYER_MOD_REFERENCES
+LIGHTGRAY, // LAYER_TRACKS
+YELLOW,// LAYER_PADS
 LIGHTGRAY, LIGHTGRAY, LIGHTGRAY, LIGHTGRAY,
 LIGHTGRAY, LIGHTGRAY, LIGHTGRAY, LIGHTGRAY,
 LIGHTGRAY, LIGHTGRAY, LIGHTGRAY
diff --git a/pcbnew/class_pcb_layer_widget.cpp b/pcbnew/class_pcb_layer_widget.cpp
index a5b44b163..bfc473734 100644
--- a/pcbnew/class_pcb_layer_widget.cpp
+++ b/pcbnew/class_pcb_layer_widget.cpp
@@ -63,6 +63,7 @@ const LAYER_WIDGET::ROW PCB_LAYER_WIDGET::s_render_rows[] = {
 RR( _( "Bl/Buried Via" ),   LAYER_VIA_BBLIND, WHITE,_( "Show blind or buried vias" )  ),
 RR( _( "Micro Via" ),   LAYER_VIA_MICROVIA,   WHITE,_( "Show micro vias") ),
 RR( _( "Non Plated Holes" ),LAYER_NON_PLATED, WHITE,_( "Show non plated holes in specific color") ),
+RR( _( "Plated Holes" ),LAYER_PADS,   YELLOW,   _( "Show plated holes in specific color") ),
 RR( _( "Ratsnest" ),LAYER_RATSNEST,   WHITE,_( "Show unconnected nets as a ratsnest") ),
 
 RR( _( "No-Connects" ), LAYER_NO_CONNECTS,BLUE, _( "Show a marker on pads which have no net connected" ) ),
diff --git a/pcbnew/pcb_painter.cpp b/pcbnew/pcb_painter.cpp
index d4a86c332..8f56d1baa 100644
--- a/pcbnew/pcb_painter.cpp
+++ b/pcbnew/pcb_painter.cpp
@@ -90,13 +90,12 @@ void PCB_RENDER_SETTINGS::ImportLegacyColors( const COLORS_DESIGN_SETTINGS* aSet
 // Default colors for specific layers (not really board layers).
 m_layerColors[LAYER_VIAS_HOLES] = COLOR4D( 0.5, 0.4, 0.0, 0.8 );
 m_layerColors[LAYER_PADS_HOLES] = COLOR4D( 0.0, 0.0, 0.0, 1.0 );
-m_layerColors[LAYER_PADS]   = COLOR4D( 0.6, 0.6, 0.0, 0.8 );
 m_layerColors[LAYER_PADS_NETNAMES]  = COLOR4D( 1.0, 1.0, 1.0, 0.9 );
 m_layerColors[LAYER_PAD_FR_NETNAMES]= COLOR4D( 1.0, 1.0, 1.0, 0.9 );
 m_layerColors[LAYER_PAD_BK_NETNAMES]= COLOR4D( 1.0, 1.0, 1.0, 0.9 );
 m_layerColors[LAYER_DRC]= COLOR4D( 1.0, 0.0, 0.0, 0.8 );
 
-// LAYER_NON_PLATED, LAYER_ANCHOR],LAYER_RATSNEST,
+// LAYER_PADS, LAYER_NON_PLATED, LAYER_ANCHOR],LAYER_RATSNEST,
 // LAYER_VIA_THROUGH], LAYER_VIA_BBLIND, LAYER_VIA_MICROVIA
 // are initialized from aSettings
 
-- 
2.14.1

___
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

[Tomasz Wlostowski]

On 27/11/17 21:18, Wayne Stambaugh wrote:
> On 11/27/2017 2:56 PM, jp charras wrote:
>> Le 27/11/2017 à 20:18, Tomasz Wlostowski a écrit :
>>> On 27/11/17 17:05, Henner Zeller wrote:
 Yes, I know about the time_t being different type situation,
>>>
>>> Why not just use uint64_t instead of time_t? It's identical on every
>>> platform.
>>>
>>> Tom
>>>
>>
>> Looks good to me.
>>
>>
> 
> Will this cause issues on platforms where time_t is 32 bits?
> 
These platforms have a serious issue anyway if they'll live long enough
to reach year 2038 ;-)

IIRC the timestamp is just an unique ID of the item in Kicad, right?
It's never propagated to the system time, so 64-bits IMHO 64-bits should
be safe everywhere.

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] Tweaks to about dialog

[Wayne Stambaugh]

Oliver,

I merged your patch in the development branch.

Thanks,

Wayne

On 11/26/2017 06:07 AM, Oliver Walters wrote:
> I'm not opposed to a
> contributors list on the website although I personally am not terribly
> interested in maintaining this list.
> 
> 
> And yet we have an outdated list _compiled into a binary_ which does not
> reflect the great contributions made by the new 3D modelling team. I am
> not suggesting that we add everyone (quite the opposite), but just
> offload this to somewhere it can be updated without recompiling KiCad.
> 
> In any case, please find attached an updated patch which only fixes the
> links on the first tab, removing the outdated smisoto links.
> 
> 
> On Sun, Nov 26, 2017 at 2:20 AM, Wayne Stambaugh  > wrote:
> 
> On 11/24/2017 04:01 PM, Oliver Walters wrote:
> > Can we have a link to a page on the website where we have a long form
> > list? Updating a binary file with a fluid list of contributors seems 
> hokey.
> 
> I know it's a bit dated but I think having credits in the application is
> a nice reward for folks who have contributed.  I'm not opposed to a
> contributors list on the website although I personally am not terribly
> interested in maintaining this list.
> 
> >
> > The 3D models for example are now script generated using Maurice's tools
> > but contributed by various people. 
> >
> > On 25 Nov 2017 06:37, "Simon Wells"  
> > >> wrote:
> >
> >     Well if you want to keep that panel it should represent all those
> >     people who have provided artistry to kicad, as such for those non
> >     programmers maybe there needs to be a script or similar that someone
> >     can just put their name in and it will spit out a patch that can be
> >     submitted to the mailing list
> >
> >
> >
> >     > On 25/11/2017, at 3:44 AM, Wayne Stambaugh  
> >     >> wrote:
> >     >
> >     > Oliver,
> >     >
> >     > I would rather not remove the artists panel from the about 
> dialog.  I
> >     > know some of those folks haven't contributed recently but many of 
> them
> >     > contributed a lot of bitmaps and icons over the years so they 
> deserve
> >     > credit for the efforts.  The remaining changes are fine.
> >     >
> >     > Cheers,
> >     >
> >     > Wayne
> >     >
> >     > On 11/23/2017 08:31 AM, Oliver Walters wrote:
> >     >> As mentioned in previous thread, I have made some slight changes
> >     to the
> >     >> About dialog.
> >     >>
> >     >> 1. Wording / link tweaks
> >     >> 2. Removed references to outdated links (now better served from 
> the
> >     >> kicad-pcb.org  
>  site)
> >     >> 3. Removed "artists" tab - very outdated, 3D models are now 
> community
> >     >> contributed
> >     >>
> >     >> I have also added myself as a developer credit - if this is an
> >     >> acceptable indulgence.
> >     >>
> >     >> Patch attached.
> >     >>
> >     >> Regards,
> >     >>
> >     >>
> >     >> ___
> >     >> 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
> 
> > 

Re: [Kicad-developers] [PATCH] Eeschema automatic manage junctions

[Seth Hillbrand]

Hi Orson-

Thanks for the pointer.  I found and corrected the issue and updated the
commit messages to remove the NEW/CHANGED tags that didn't reflect
user-visible changes.

Since we're now in feature freeze, this may be too late for 5.0.  However,
this does address a number of bug reports so I'm attaching the minimized
patchset in case Wayne would like to merge it.  If Wayne decides that this
more feature/less bugfix, I'll hold onto the patchset until we have a 6-dev
branch.

Best-
Seth

On Sat, Nov 25, 2017 at 7:37 AM, Maciej Suminski 
wrote:

> Hi Seth,
>
> I tried this with interf_u demo shipped with the source code. There are
> four capacitors in the left bottom corner - try dragging one of the
> middle ones out. If you cannot reproduce the problem, I will try to
> shoot a video.
>
> Cheers,
> Orson
>
> On 11/25/2017 03:58 PM, Seth Hillbrand wrote:
> > Hi Orson-
> >
> > Thanks for the test and the clarification of the documentation.
> >
> > On the schematic, I can't seem to recreate the issue you document in the
> > image.  Is the example schematic one you can share?
> >
> > Best-
> > Seth
> >
> > On Fri, Nov 24, 2017 at 6:50 AM, Maciej Sumiński <
> maciej.sumin...@cern.ch>
> > wrote:
> >
> >> Hi Seth,
> >>
> >> I tested the branch and I consider it a significant improvement to the
> >> way junctions are handled. I confirm it fixes the four bugs mentioned in
> >> patch 0011, apart from a single case when a parallel component is
> >> dragged out. In this case junctions are not still not auto deleted (see
> >> [1], the rightmost picture "Junction is not auto deleted"), but at least
> >> the overlapping wires are merged. It is not a big deal IMHO, especially
> >> the patch set fixes a lot of other issues.
> >>
> >> It has not been stated explicitly, but I thought we will use
> >> NEW/REMOVE/CHANGE tags for listing changes that are perceived by the
> >> user. Therefore:
> >>
> >>   CHANGE: DeleteItem removes junctions that are no longer needed.
> >>
> >> informs the user about an improvement, but:
> >>
> >>   CHANGE: DeleteItemsInList shares the code for DeleteItem.
> >>
> >> seems to be too detailed and does not need to be reflected in the user
> >> documentation.
> >>
> >> What do you think? I will try to come up with a short paragraph that can
> >> be added to the website to make things clear.
> >>
> >> Regards,
> >> Orson
> >>
> >> 1.
> >> https://launchpadlibrarian.net/213748651/KICAD%20-%20BUG%
> >> 20REPORT%20-%20EESCHEMA%20-%20SOME%20DRAG%20ISSUES.jpg
> >>
> >> On 11/22/2017 09:07 PM, Seth Hillbrand wrote:
> >>> Updated patchset for this proposal, rebased to master.  I've also
> updated
> >>> the commit messages to match the CHANGE:/NEW: format and added one new
> >> bug
> >>> from launchpad that this addresses.
> >>>
> >>> -Seth
> >>>
> >>> On Wed, Nov 8, 2017 at 3:59 AM, Nick Østergaard 
> >> wrote:
> >>>
>  For that specific issue with the junction drawing, there is a patch in
> >> the
>  thread "[Kicad-developers] [PATCH] Draw junctions last"
> 
>  2017-11-03 13:12 GMT+01:00 Jon Evans :
> 
> > I looked at fixing this and some other related things, and decided to
> > just wait for the GAL port. There will need to be huge refactoring of
> >> the
> > eeschema draw code as part of that effort, so putting much effort
> into
> > making the wxDC drawing better seems not worth it.
> >
> > -Jon
> >
> > On Nov 3, 2017 00:08, "Kevin Cozens"  wrote:
> >
> > On 2017-11-02 06:31 PM, Seth Hillbrand wrote:
> >
> >> Please let me know if there are any additional issues or suggestions
> >> for
> >> improvement.
> >>
> >
> > How difficult would it be to have junctions draw last on schematics?
> > There is a minor negative visual effect when you have a component
> with
> >> one
> > end joined to a wire by a junction and you replace the component.
> >
> > When you replace the component the pin of the component is now seen
> > extending through the round disc of the junction to the center of the
> > junction. I prefer to always see just the full round disc of a
> junction
> > mark even if I have replaced a component since placing the junction.
> >
> > --
> > Cheers!
> >
> > Kevin.
> >
> > http://www.ve3syb.ca/   |"Nerds make the shiny things that
> > distract
> > Owner of Elecraft K2 #2172  | the mouth-breathers, and that's why
> > we're
> > | powerful!"
> > #include  | --Chris Hardwick
> >
> >
> > ___
> > 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://l

[Kicad-developers] [PATCH] Fix drag wire issue

[Seth Hillbrand]

​In Eeschema, if you draw two lines on top of each other that are not the
same type, e.g. wire and bus; or bus and graphic line​, and then hover over
the lines and use the 'drag' hotkey, both lines will drag at the same
time.  The correct behavior should show disambiguation.

The attached patch corrects this behavior by distinguishing the line types
in SCH_COLLECTOR::IsCorner().

​Reference: https://bugs.launchpad.net/kicad/+bug/1635984

-Seth​
From 22c5bdd1f90f00b65965cbd47a5e6fb687efeb73 Mon Sep 17 00:00:00 2001
From: Seth Hillbrand 
Date: Mon, 27 Nov 2017 14:44:41 -0800
Subject: [PATCH] Eeschema: IsCorner check for layer match

SCH_LINE can represent a bus, wire or graphic line.  Checking
for the corner needs to distinguish between these types.

Fixes: lp:1635984
* https://bugs.launchpad.net/kicad/+bug/1635984
---
 eeschema/sch_collectors.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eeschema/sch_collectors.cpp b/eeschema/sch_collectors.cpp
index 915d9616e..efe859720 100644
--- a/eeschema/sch_collectors.cpp
+++ b/eeschema/sch_collectors.cpp
@@ -263,7 +263,7 @@ bool SCH_COLLECTOR::IsCorner() const
 bool is_busentry1 = (dynamic_cast( m_List[1] ) != NULL);
 
 if( (m_List[0]->Type() == SCH_LINE_T) && (m_List[1]->Type() == SCH_LINE_T) )
-return true;
+return ( ( SCH_LINE* ) m_List[0])->GetLayer() == ( ( SCH_LINE* ) m_List[1])->GetLayer();
 
 if( (m_List[0]->Type() == SCH_LINE_T) && is_busentry1 )
 return true;
-- 
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] Potrace update (AGAIN)

[Kevin Cozens]

On 2017-11-27 03:00 AM, Maciej Sumiński wrote:

I wonder why do we even keep potrace in the source tree.


It would be better to use an external library instead of having the potrace 
source files in the KiCad tree. That eliminates the need to keep an eye out 
for changes in the upstream potrace files and then apply the changes to the 
copy of the files in KiCad.


--
Cheers!

Kevin.

http://www.ve3syb.ca/   |"Nerds make the shiny things that distract
Owner of Elecraft K2 #2172  | the mouth-breathers, and that's why we're
| powerful!"
#include  | --Chris Hardwick

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

On 11/27/2017 2:56 PM, jp charras wrote:
> Le 27/11/2017 à 20:18, Tomasz Wlostowski a écrit :
>> On 27/11/17 17:05, Henner Zeller wrote:
>>> Yes, I know about the time_t being different type situation,
>>
>> Why not just use uint64_t instead of time_t? It's identical on every
>> platform.
>>
>> Tom
>>
> 
> Looks good to me.
> 
> 

Will this cause issues on platforms where time_t is 32 bits?

___
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

[jp charras]

Le 27/11/2017 à 20:18, Tomasz Wlostowski a écrit :
> On 27/11/17 17:05, Henner Zeller wrote:
>> Yes, I know about the time_t being different type situation,
> 
> Why not just use uint64_t instead of time_t? It's identical on every
> platform.
> 
> Tom
> 

Looks good to me.


-- 
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] Python: time_t needs mapping; tentative patch

[Tomasz Wlostowski]

On 27/11/17 17:05, Henner Zeller wrote:
> Yes, I know about the time_t being different type situation,

Why not just use uint64_t instead of time_t? It's identical on every
platform.

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] snap images

[Eldar Khayrullin]

Hello.
You can see snappy issues here:
https://github.com/eldarkg/kicad-snap/issues
At time when I coding this package snappy was very restricted to run 
3rd party app (browser, pdf viewer and etc).

Now it may be is possible.
I haven't time to work with snappy. If you want you may to make patches.
See:
https://github.com/eldarkg/kicad-snap/tree/4.0
https://github.com/eldarkg/kicad-snap

В Понедельник, 27 ноя. 2017 в 10:04 Д. П., Marco 
Ciampa  написал:

Hello devs!
Just a heads up: the snap(py) version of KiCad is still to version:

(Ubuntu  Linux 16.04-64 here...)

Application: kicad
Version: 4.0.4-snap1-stable release build
wxWidgets: Version 3.0.2 (debug,wchar_t,compiler with C++ ABI 
1009,GCC 5.4.0,wx containers,compatible with 2.8)

Platform: Linux 4.4.0-101-generic x86_64, 64 bit, Little endian, wxGTK
Boost version: 1.58.0
 USE_WX_GRAPHICS_CONTEXT=OFF
 USE_WX_OVERLAY=OFF
 KICAD_SCRIPTING=ON
 KICAD_SCRIPTING_MODULES=ON
 KICAD_SCRIPTING_WXPYTHON=ON
 USE_FP_LIB_TABLE=HARD_CODED_ON
 BUILD_GITHUB_PLUGIN=ON

and the command:

 snap refresh

gives:

 All snaps up to date.

Is this all right?

PS: it seems to me that there is something weird in its configuration
also... I can't open an external program with the kicad snap version,
meaning any editor, pdf reader or web browser for the manuals.  
Again...

can someone check it if I am wrong? Hint: when I try to open the kicad
manual it gives:

execvp(�, <, 
/snap/kicad-snap/2/usr/share/doc/kicad/help/it/kicad.html) failed 
with error 2!


TIA and
Best regards,

--


Marco Ciampa

I know a joke about UDP, but you might not get it.



 GNU/Linux User #78271
 FSFE fellow #364




___
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

[Henner Zeller]

On 27 November 2017 at 07:34, Wayne Stambaugh  wrote:
> Henner,
>
> I'm pretty sure this is not correct because time_t is not long on all
> platforms.  You should be able to include the header file where time_t
> is defined and it should get mapped correctly.  If I am wrong, would one
> of our resident swig experts chime in here.

Yes, I know about the time_t being different type situation, this is
why I just threw this out as an example how it is working on my
platform.
If we include , wouldn't we also swig-bind all the time
functions ? This is why I did not do that. Anyway, this is why I'd
like to have a swig expert look at this.

Cheers,
  Henner.

>
> On 11/27/2017 9:20 AM, Henner Zeller wrote:
>> Hi,
>> whlie accessing SetTimeStamp() in the Python API, I found that the
>> parameter type was not understood by the swig-bound code as integer
>> type. So these functions can not be used out of
>> the box with resulting error messages such as the following:
>>
>>   File "/usr/local/lib/python2.7/dist-packages/pcbnew.py", line 1257,
>> in SetTimeStamp
>>return _pcbnew.EDA_ITEM_SetTimeStamp(self, aNewTimeStamp)
>> TypeError: in method 'EDA_ITEM_SetTimeStamp', argument 2 of type 'time_t'
>>
>> The following will make it work, but I have no idea if this is the
>> "correct" way to do this with swig, or if there should be a %typemap
>> version of it. So I leave this here for someone knowledgeable in swig
>> bindings to do it properly:
>>
>> -8<
>> --- a/pcbnew/swig/typeinfo.i
>> +++ b/pcbnew/swig/typeinfo.i
>> @@ -29,6 +29,9 @@
>> #include 
>> %}
>>
>> +// Set/GetTimeStamp() uses time_t
>> +typedef long time_t;
>> +
>> // methods like CONNECTIVITY_DATA::GetNetItems take an array of KICAD_T 
>> values,
>> >8---
>>
>> Thanks,
>>   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
>>
>
> ___
> 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]

Henner,

I'm pretty sure this is not correct because time_t is not long on all
platforms.  You should be able to include the header file where time_t
is defined and it should get mapped correctly.  If I am wrong, would one
of our resident swig experts chime in here.

Cheers,

Wayne

On 11/27/2017 9:20 AM, Henner Zeller wrote:
> Hi,
> whlie accessing SetTimeStamp() in the Python API, I found that the
> parameter type was not understood by the swig-bound code as integer
> type. So these functions can not be used out of
> the box with resulting error messages such as the following:
> 
>   File "/usr/local/lib/python2.7/dist-packages/pcbnew.py", line 1257,
> in SetTimeStamp
>return _pcbnew.EDA_ITEM_SetTimeStamp(self, aNewTimeStamp)
> TypeError: in method 'EDA_ITEM_SetTimeStamp', argument 2 of type 'time_t'
> 
> The following will make it work, but I have no idea if this is the
> "correct" way to do this with swig, or if there should be a %typemap
> version of it. So I leave this here for someone knowledgeable in swig
> bindings to do it properly:
> 
> -8<
> --- a/pcbnew/swig/typeinfo.i
> +++ b/pcbnew/swig/typeinfo.i
> @@ -29,6 +29,9 @@
> #include 
> %}
> 
> +// Set/GetTimeStamp() uses time_t
> +typedef long time_t;
> +
> // methods like CONNECTIVITY_DATA::GetNetItems take an array of KICAD_T 
> values,
> >8---
> 
> Thanks,
>   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
> 

___
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] Python: time_t needs mapping; tentative patch

[Henner Zeller]

Hi,
whlie accessing SetTimeStamp() in the Python API, I found that the
parameter type was not understood by the swig-bound code as integer
type. So these functions can not be used out of
the box with resulting error messages such as the following:

  File "/usr/local/lib/python2.7/dist-packages/pcbnew.py", line 1257,
in SetTimeStamp
   return _pcbnew.EDA_ITEM_SetTimeStamp(self, aNewTimeStamp)
TypeError: in method 'EDA_ITEM_SetTimeStamp', argument 2 of type 'time_t'

The following will make it work, but I have no idea if this is the
"correct" way to do this with swig, or if there should be a %typemap
version of it. So I leave this here for someone knowledgeable in swig
bindings to do it properly:

-8<
--- a/pcbnew/swig/typeinfo.i
+++ b/pcbnew/swig/typeinfo.i
@@ -29,6 +29,9 @@
#include 
%}

+// Set/GetTimeStamp() uses time_t
+typedef long time_t;
+
// methods like CONNECTIVITY_DATA::GetNetItems take an array of KICAD_T values,
>8---

Thanks,
  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] MacOS 4.0.7 release oopsie

[Adam Wolf]

Thanks Wayne.  I have no personal hesitation against increasing the support
for legacy versions if 10.11 ends up not being sufficient either.

Adam Wolf

On Nov 27, 2017 7:15 AM, "Wayne Stambaugh"  wrote:

> I think this is fine given our manpower limitations.  We may want to
> keep copies of the current stable release around for users who don't
> want to migrate their projects.
>
> Cheers,
>
> Wayne
>
> On 11/26/2017 8:37 PM, Adam Wolf wrote:
> > I think I agree, and I think this was Mac dev/packager consensus last
> > time this was discussed.  Wikipedia says 10.11 is the oldest supported
> > right now, but I can't find any primary source.  Just for the record, I
> > think we should lock this in at the start of a stable series.  This
> > means whatever oldest version we support for 5.0, we should continue to
> > support until 6.0.
> >
> > Adam Wolf
> >
> > On Nov 26, 2017 7:31 PM, "Simon Wells"  > > wrote:
> >
> > I Think it mainly comes down to, if there is a bug reported on 10.9
> > do we want to be a) trying to sort out why its an issue when we only
> > have newer systems or b) scrambling around trying to find an older
> > install to be able to test the issue and solve it
> >
> > Therefore I think its best to at most only support the oldest
> > version that is still supported by apple at the time 5.0 is released
> > (or at least when the RC is released).
> >
> > It does not stop someone building for an older version of OSX, but
> > if they have issues it is up to them (with the older operating
> > system) to solve them
> >
> > Simon
> >
> >
> >
> >> On 27/11/2017, at 1:41 PM, Adam Wolf
> >>  >> > wrote:
> >>
> >> I'll definitely be keeping the 4.0 server around for at least 6+
> >> months, but the plan is to generate the 5.0 stable releases from a
> >> 10.x VM.  We should have a test image after next weekend.  We had
> >> previously discussed using the oldest OS version still getting
> >> security updates, which appears to be 10.11.  I could do anything
> >> from 10.9 on.
> >>
> >> Do people think supporting 10.11 and newer is sufficient?
> >>
> >> Adam Wolf
> >>
> >> On Nov 26, 2017 6:23 PM, "Chris Pavlina"  >> > wrote:
> >>
> >> With an upcoming 5.0 I'm not sure how necessary it is to
> >> re-release
> >> 4.0.7 - I just want to make sure the same mistake doesn't get
> >> made for
> >> 5.0...
> >>
> >> On Sun, Nov 26, 2017 at 11:03:48PM +, Wayne Stambaugh wrote:
> >> > 4.0.7-2 seems reasonable if the previous macos version was
> >> 4.0.7-1.
> >> >
> >> > On 11/26/2017 05:25 PM, Adam Wolf wrote:
> >> > > 1) I'll take a look at the script, but I suspect Nick is
> >> correct.
> >> > >
> >> > > 2) What version number should I release this 4.0.7 as?
> >> 4.0.7-2?
> >> > >
> >> > > Adam Wolf
> >> > >
> >> > > On Sun, Nov 26, 2017 at 3:35 PM, Nick Østergaard
> >> mailto:oe.n...@gmail.com>> wrote:
> >> > >> It is because of what happened in:
> >> > >> [Kicad-developers] Yet another 4.0.7 release bug.
> >> > >>
> >> https://lists.launchpad.net/kicad-developers/msg30192.html
> >> 
> >> > >>
> >> > >> I suspect that the script for the OSX build did not
> >> consider that tags could
> >> > >> move. Which I think could happen like this:
> >> > >>
> >> > >> A tag will get pulled down when you pull normally. But if
> >> it changes
> >> > >> upstream you need to fetch with the --tags option
> >> > >> to sync it.
> >> > >>
> >> > >> 2017-11-26 20:12 GMT+01:00 Chris Pavlina
> >> mailto:pavlina.ch...@gmail.com>>:
> >> > >>>
> >> > >>> Okay people, wtf happened here.
> >> > >>>
> >> > >>> Helping someone on IRC figure out a PDF export bug on
> >> 4.0.7, when I
> >> > >>> realized this:
> >> > >>>
> >> > >>> https://misc.c4757p.com/pastes/0AOyojEiEE0V.txt
> >> 
> >> > >>>
> >> > >>> ^ "Tag stable release" is commit 631f6d5, on July 14.
> >> The ACTUAL 4.0.7
> >> > >>> tag is on 9f35e38, four commits later on August 1.
> >> > >>>
> >> > >>> Guess which one got released?
> >> > >>>
> >> > >>> Yup, we released the wrong commit for 4.0.7. The older
> >> one, missing
> >> > >>> several bug fixes. How did we manage to release
> >> something that wasn't
> >> > >>> actually tagged as 4.0.7? Doesn't the release build
> >> process involve
> >> > >>> something li

Re: [Kicad-developers] MacOS 4.0.7 release oopsie

[Wayne Stambaugh]

I think this is fine given our manpower limitations.  We may want to
keep copies of the current stable release around for users who don't
want to migrate their projects.

Cheers,

Wayne

On 11/26/2017 8:37 PM, Adam Wolf wrote:
> I think I agree, and I think this was Mac dev/packager consensus last
> time this was discussed.  Wikipedia says 10.11 is the oldest supported
> right now, but I can't find any primary source.  Just for the record, I
> think we should lock this in at the start of a stable series.  This
> means whatever oldest version we support for 5.0, we should continue to
> support until 6.0.
> 
> Adam Wolf
> 
> On Nov 26, 2017 7:31 PM, "Simon Wells"  > wrote:
> 
> I Think it mainly comes down to, if there is a bug reported on 10.9
> do we want to be a) trying to sort out why its an issue when we only
> have newer systems or b) scrambling around trying to find an older
> install to be able to test the issue and solve it
> 
> Therefore I think its best to at most only support the oldest
> version that is still supported by apple at the time 5.0 is released
> (or at least when the RC is released).
> 
> It does not stop someone building for an older version of OSX, but
> if they have issues it is up to them (with the older operating
> system) to solve them
> 
> Simon
> 
> 
> 
>> On 27/11/2017, at 1:41 PM, Adam Wolf
>> > > wrote:
>>
>> I'll definitely be keeping the 4.0 server around for at least 6+
>> months, but the plan is to generate the 5.0 stable releases from a
>> 10.x VM.  We should have a test image after next weekend.  We had
>> previously discussed using the oldest OS version still getting
>> security updates, which appears to be 10.11.  I could do anything
>> from 10.9 on.
>>
>> Do people think supporting 10.11 and newer is sufficient?
>>
>> Adam Wolf
>>
>> On Nov 26, 2017 6:23 PM, "Chris Pavlina" > > wrote:
>>
>> With an upcoming 5.0 I'm not sure how necessary it is to
>> re-release
>> 4.0.7 - I just want to make sure the same mistake doesn't get
>> made for
>> 5.0...
>>
>> On Sun, Nov 26, 2017 at 11:03:48PM +, Wayne Stambaugh wrote:
>> > 4.0.7-2 seems reasonable if the previous macos version was
>> 4.0.7-1.
>> >
>> > On 11/26/2017 05:25 PM, Adam Wolf wrote:
>> > > 1) I'll take a look at the script, but I suspect Nick is
>> correct.
>> > >
>> > > 2) What version number should I release this 4.0.7 as?
>> 4.0.7-2?
>> > >
>> > > Adam Wolf
>> > >
>> > > On Sun, Nov 26, 2017 at 3:35 PM, Nick Østergaard
>> mailto:oe.n...@gmail.com>> wrote:
>> > >> It is because of what happened in:
>> > >> [Kicad-developers] Yet another 4.0.7 release bug.
>> > >>
>> https://lists.launchpad.net/kicad-developers/msg30192.html
>> 
>> > >>
>> > >> I suspect that the script for the OSX build did not
>> consider that tags could
>> > >> move. Which I think could happen like this:
>> > >>
>> > >> A tag will get pulled down when you pull normally. But if
>> it changes
>> > >> upstream you need to fetch with the --tags option
>> > >> to sync it.
>> > >>
>> > >> 2017-11-26 20:12 GMT+01:00 Chris Pavlina
>> mailto:pavlina.ch...@gmail.com>>:
>> > >>>
>> > >>> Okay people, wtf happened here.
>> > >>>
>> > >>> Helping someone on IRC figure out a PDF export bug on
>> 4.0.7, when I
>> > >>> realized this:
>> > >>>
>> > >>> https://misc.c4757p.com/pastes/0AOyojEiEE0V.txt
>> 
>> > >>>
>> > >>> ^ "Tag stable release" is commit 631f6d5, on July 14.
>> The ACTUAL 4.0.7
>> > >>> tag is on 9f35e38, four commits later on August 1.
>> > >>>
>> > >>> Guess which one got released?
>> > >>>
>> > >>> Yup, we released the wrong commit for 4.0.7. The older
>> one, missing
>> > >>> several bug fixes. How did we manage to release
>> something that wasn't
>> > >>> actually tagged as 4.0.7? Doesn't the release build
>> process involve
>> > >>> something like "git checkout 4.0.7"? Help me understand
>> what went wrong
>> > >>> here...
>> > >>>
>> > >>> I'm still trying to figure out how a commit titled "tag
>> stable release
>> > >>> 4.0.7" and the actual 4.0.7 tag do not point at the same
>> place, let
>> > >>> alone how the release build process does not actually
>> directly check out
>> > >>> th

Re: [Kicad-developers] [PATCH] Demo: fix incorrect URI in symbol library table for video project

[jp charras]

Le 27/11/2017 à 10:46, Jay Aurabind a écrit :
> Hi,
> 
> The Video project in eeschema shows as questions marks within square.
> This fixes the location of symbol library table to the project
> specific directory.
> 

Committed. Thanks.


-- 
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] Potrace update (AGAIN)

[jp charras]

I updated potrace to latest version 1.15


-- 
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] Fix for 3D model offset

[Oliver Walters]

jp,

Sorry I forgot to reapply that patch on top.

Updated patch set is attached.

Thanks,

On Mon, Nov 27, 2017 at 6:48 PM, jp charras  wrote:

> Le 26/11/2017 à 22:21, Oliver Walters a écrit :
> > Wayne,
> >
> > Please find attached an updated patch set which also fixes 3D model
> units for the STEP exporter tool.
> >
> >
> >
> > On Thu, Nov 23, 2017 at 1:59 AM, Wayne Stambaugh  > > wrote:
> >
> > Consistency.  Currently we have two separate units in kicad board and
> > footprint files.  This change unifies that issue.  I know it's
> annoying
> > but it is a decision that I made to make the file formatting more
> > consistent.  Yes, it is a change that will break some users 3D models
> > but I think the long term benefit outweighs the short term annoyance.
>
> Hi Oliver and Wayne,
>
> I am thinking the "offset" should be written in footprint (and board)
> files *only* if it is not 0,0,0
>
> With this patch, all footprint files will be incompatible with stable
> version, due to a not used
> (most of time) parameter.
> Moreover footprint files have no version identification.
>
> --
> 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
>
From 28025695e70160a5663d83ec4b6dff27dbd58f9e Mon Sep 17 00:00:00 2001
From: Oliver 
Date: Mon, 27 Nov 2017 21:46:53 +1100
Subject: [PATCH 3/3] Write "offset" only if non-zero

- Use "at" if all offset dimensions are zero
- Use "offset" otherwise
---
 pcbnew/kicad_plugin.cpp | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/pcbnew/kicad_plugin.cpp b/pcbnew/kicad_plugin.cpp
index 79ef1cf..6dd19e4 100644
--- a/pcbnew/kicad_plugin.cpp
+++ b/pcbnew/kicad_plugin.cpp
@@ -1143,9 +1143,22 @@ void PCB_IO::format( MODULE* aModule, int aNestLevel ) const
 /* Write 3D model offset in mm
  * 4.0.x wrote "at" which was actually in inches
  * 5.0.x onwards, 3D model offset is written using "offset"
+ *
+ * If the offset is all zero, write "at" (fewer file changes)
+ * Otherwise, write "offset"
  */
 
-m_out->Print( aNestLevel+2, "(offset (xyz %s %s %s))\n",
+wxString offsetTag = "offset";
+
+if( bs3D->m_Offset.x == 0 &&
+bs3D->m_Offset.y == 0 &&
+bs3D->m_Offset.z == 0 )
+{
+offsetTag = "at";
+}
+
+m_out->Print( aNestLevel+2, "(%s (xyz %s %s %s))\n",
+  offsetTag.ToStdString().c_str(),
   Double2Str( bs3D->m_Offset.x ).c_str(),
   Double2Str( bs3D->m_Offset.y ).c_str(),
   Double2Str( bs3D->m_Offset.z ).c_str() );
-- 
2.7.4

From cf43b53bce992581902d99790fb305db004d1a7f Mon Sep 17 00:00:00 2001
From: Oliver 
Date: Mon, 27 Nov 2017 08:20:02 +1100
Subject: [PATCH 2/3] Decode "offset" in STEP export tool

- Read "at" as inches
- Read "offset" as mm
---
 pcbnew/kicad_plugin.cpp |  2 ++
 utils/kicad2step/pcb/kicadmodel.cpp | 25 +
 2 files changed, 27 insertions(+)

diff --git a/pcbnew/kicad_plugin.cpp b/pcbnew/kicad_plugin.cpp
index 2c75f27..79ef1cf 100644
--- a/pcbnew/kicad_plugin.cpp
+++ b/pcbnew/kicad_plugin.cpp
@@ -1142,7 +1142,9 @@ void PCB_IO::format( MODULE* aModule, int aNestLevel ) const
 
 /* Write 3D model offset in mm
  * 4.0.x wrote "at" which was actually in inches
+ * 5.0.x onwards, 3D model offset is written using "offset"
  */
+
 m_out->Print( aNestLevel+2, "(offset (xyz %s %s %s))\n",
   Double2Str( bs3D->m_Offset.x ).c_str(),
   Double2Str( bs3D->m_Offset.y ).c_str(),
diff --git a/utils/kicad2step/pcb/kicadmodel.cpp b/utils/kicad2step/pcb/kicadmodel.cpp
index 6f680e0..61395ba 100644
--- a/utils/kicad2step/pcb/kicadmodel.cpp
+++ b/utils/kicad2step/pcb/kicadmodel.cpp
@@ -80,12 +80,37 @@ bool KICADMODEL::Read( SEXPR::SEXPR* aEntry )
 std::string name = child->GetChild( 0 )->GetSymbol();
 bool ret = true;
 
+/*
+ * Version 4.x and prior used 'at' parameter,
+ * which was specified in inches.
+ */
 if( name == "at" )
+{
 ret = Get3DCoordinate( child->GetChild( 1 ), m_offset );
+
+if( ret )
+{
+m_offset.x *= 25.4f;
+m_offset.y *= 25.4f;
+m_offset.z *= 25.4f;
+}
+}
+/*
+ * From 5.x onwards, 3D model is provided in 'offset',
+ * which is in millimetres
+ */
+else if( name == "offset" )
+{
+ret = Get3DCoordinate

[Kicad-developers] [PATCH] Demo: fix incorrect URI in symbol library table for video project

[Jay Aurabind]

Hi,

The Video project in eeschema shows as questions marks within square.
This fixes the location of symbol library table to the project
specific directory.

-- 

Thanks and Regards,
Aurabindo J
From 6309bd38bd23162f7e59c1d623c1d38d8b0806bf Mon Sep 17 00:00:00 2001
From: Aurabindo J 
Date: Mon, 27 Nov 2017 15:07:29 +0530
Subject: [PATCH] Fix symbol library table URI for video demo

Signed-off-by: Aurabindo J 
---
 demos/video/sym-lib-table | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/demos/video/sym-lib-table b/demos/video/sym-lib-table
index ef905191..41721800 100644
--- a/demos/video/sym-lib-table
+++ b/demos/video/sym-lib-table
@@ -1,3 +1,3 @@
 (sym_lib_table
-  (lib (name video_schlib)(type Legacy)(uri F:/kicad-launchpad/git_testing/demos/video/libs/video_schlib.lib)(options "")(descr ""))
+  (lib (name video_schlib)(type Legacy)(uri ${KIPRJMOD}/libs/video_schlib.lib)(options "")(descr ""))
 )
-- 
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] Potrace update (AGAIN)

[Simon Wells]

And yet the files are also being modified unnecessarily making more effort when 
there is an update available,
The potrace library is not large and so seems pointless to bundle the code with 
the source tree.

If the potrace library is out of date with the distributions that can be 
expressed to the distributions esspecially since its been security updates and 
I am not familiar with a distribution that is currently supported by the 
distromaker to not get security updates

> On 27/11/2017, at 9:37 PM, jp charras  wrote:
> 
> Le 27/11/2017 à 09:00, Maciej Sumiński a écrit :
>> I wonder why do we even keep potrace in the source tree. It is available
>> in mingw, brew and major Linux distributions, so it does not need to be
>> build manually.
>> 
>> Regards,
>> Orson
> 
> We need only potrace library source files (only 200Kbytes).
> They are not a lot ( 20 / 30 files).
> 
> Using potrace lib coming with distros is obviously an option, but it does not 
> fix what is asked:
> potrace update ( and it creates one more (minor) dependency for compiling ).
> 
> For instance
> We are using currently potrace 1.13
> 
> potrace 1.15 fixes a few issues of potrace 1.13,  but on mingw the currently 
> potrace version is 1.13
> 
>> 
>> On 11/27/2017 03:58 AM, Simon Wells wrote:
>>> U I *think* its jp who does the potrace stuff but there has been 
>>> another security update for pot race, while I realise we are in a freeze I 
>>> think that security updates should probably be included.
>>> 
>>> "This release consists of bugfixes and minor portability improvements. Some 
>>> potential buffer overflows and arithmetic overflows were fixed, including 
>>> CVE-2017-12067. A bug triggered by very large bitmaps has been fixed. A new 
>>> configuration option --enable-local-getopt was added. Thanks to Agostino 
>>> Sarubbo, Daniel Macks, and Michael Voříšek for reporting bugs and 
>>> suggesting improvements.”
>>> 
>>> Simon
> 
> 
> -- 
> 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] Potrace update (AGAIN)

[jp charras]

Le 27/11/2017 à 09:00, Maciej Sumiński a écrit :
> I wonder why do we even keep potrace in the source tree. It is available
> in mingw, brew and major Linux distributions, so it does not need to be
> build manually.
> 
> Regards,
> Orson

We need only potrace library source files (only 200Kbytes).
They are not a lot ( 20 / 30 files).

Using potrace lib coming with distros is obviously an option, but it does not 
fix what is asked:
potrace update ( and it creates one more (minor) dependency for compiling ).

For instance
We are using currently potrace 1.13

potrace 1.15 fixes a few issues of potrace 1.13,  but on mingw the currently 
potrace version is 1.13

> 
> On 11/27/2017 03:58 AM, Simon Wells wrote:
>> U I *think* its jp who does the potrace stuff but there has been another 
>> security update for pot race, while I realise we are in a freeze I think 
>> that security updates should probably be included.
>>
>> "This release consists of bugfixes and minor portability improvements. Some 
>> potential buffer overflows and arithmetic overflows were fixed, including 
>> CVE-2017-12067. A bug triggered by very large bitmaps has been fixed. A new 
>> configuration option --enable-local-getopt was added. Thanks to Agostino 
>> Sarubbo, Daniel Macks, and Michael Voříšek for reporting bugs and 
>> suggesting improvements.”
>>
>> Simon


-- 
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] Gerbview: apply layer colors to GAL after sorting (Fixes lp:1720540)

[jp charras]

Le 27/11/2017 à 01:03, Jon Evans a écrit :
> Hi all,
> 
> This patch fixes this issue with X2 layer sorting feature in the GAL canvas:
> https://bugs.launchpad.net/kicad/+bug/1720540
> 
> Best,
> Jon
I committed your patch.
Thanks, Jon.

-- 
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] Potrace update (AGAIN)

[Maciej Sumiński]

I wonder why do we even keep potrace in the source tree. It is available
in mingw, brew and major Linux distributions, so it does not need to be
build manually.

Regards,
Orson

On 11/27/2017 03:58 AM, Simon Wells wrote:
> U I *think* its jp who does the potrace stuff but there has been another 
> security update for pot race, while I realise we are in a freeze I think that 
> security updates should probably be included.
> 
> "This release consists of bugfixes and minor portability improvements. Some 
> potential buffer overflows and arithmetic overflows were fixed, including 
> CVE-2017-12067. A bug triggered by very large bitmaps has been fixed. A new 
> configuration option --enable-local-getopt was added. Thanks to Agostino 
> Sarubbo, Daniel Macks, and Michael Voříšek for reporting bugs and 
> suggesting improvements.”
> 
> 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