[Kicad-developers] [PATCH] Show the current grid setting.
Attached please find a revised patch to show the current grid settings on the
status bar. The patch makes the grid settings visible in the following tools:
eeschema, symbol editor, pcbnew, footprint editor, gerbview, and the page
layout editor.
If there are any I missed, please let me know.
And of course please let me know if there are problems with the patch. This
one is for the master branch. If it is accepted, then I will create a version
for the 5.1 branch.
Steve
From 7f128614de33a2d55ad1367f9a10473924fa0fc6 Mon Sep 17 00:00:00 2001
From: "Steven A. Falco"
Date: Fri, 24 May 2019 09:55:33 -0400
Subject: [PATCH] Show the current grid setting.
---
common/legacy_gal/eda_draw_frame.cpp | 38 --
eeschema/sch_base_frame.cpp | 3 ++
gerbview/gerbview_frame.cpp | 38 ++
gerbview/gerbview_frame.h | 7
include/draw_frame.h | 5 +++
include/pcb_base_frame.h | 7
pagelayout_editor/pl_editor_frame.cpp | 46 ---
pagelayout_editor/pl_editor_frame.h | 2 ++
pcbnew/pcb_base_frame.cpp | 38 ++
9 files changed, 177 insertions(+), 7 deletions(-)
diff --git a/common/legacy_gal/eda_draw_frame.cpp b/common/legacy_gal/eda_draw_frame.cpp
index 6c3a3a47b..f24534980 100644
--- a/common/legacy_gal/eda_draw_frame.cpp
+++ b/common/legacy_gal/eda_draw_frame.cpp
@@ -124,7 +124,7 @@ EDA_DRAW_FRAME::EDA_DRAW_FRAME( KIWAY* aKiway, wxWindow* aParent, FRAME_T aFrame
m_auimgr.SetFlags(wxAUI_MGR_DEFAULT);
-CreateStatusBar( 6 );
+CreateStatusBar( 7 );
// set the size of the status bar subwindows:
@@ -147,6 +147,9 @@ EDA_DRAW_FRAME::EDA_DRAW_FRAME( KIWAY* aKiway, wxWindow* aParent, FRAME_T aFrame
// delta distances
GetTextSize( wxT( "dx 0234.567890 dx 0234.567890 d 0234.567890" ), stsbar ).x + 10,
+// grid size
+GetTextSize( wxT( "grid X 0234.567890 Y 0234.567890" ), stsbar ).x + 10,
+
// units display, Inches is bigger than mm
GetTextSize( _( "Inches" ), stsbar ).x + 10,
@@ -417,6 +420,37 @@ void EDA_DRAW_FRAME::DisplayToolMsg( const wxString& msg )
}
+/*
+ * Display the grid status.
+ */
+void EDA_DRAW_FRAME::DisplayGridMsg()
+{
+wxString line;
+wxString gridformatter;
+
+switch( m_UserUnits )
+{
+case INCHES:
+gridformatter = "grid %.3f";
+break;
+
+case MILLIMETRES:
+gridformatter = "grid %.4f";
+break;
+
+default:
+gridformatter = "grid %f";
+break;
+}
+
+wxRealPoint curr_grid_size = GetScreen()->GetGridSize();
+double grid = To_User_Unit( m_UserUnits, curr_grid_size.x );
+line.Printf( gridformatter, grid );
+
+SetStatusText( line, 4 );
+}
+
+
void EDA_DRAW_FRAME::DisplayUnitsMsg()
{
wxString msg;
@@ -428,7 +462,7 @@ void EDA_DRAW_FRAME::DisplayUnitsMsg()
default: msg = _( "Units" ); break;
}
-SetStatusText( msg, 4 );
+SetStatusText( msg, 5 );
}
diff --git a/eeschema/sch_base_frame.cpp b/eeschema/sch_base_frame.cpp
index e013d1789..72573884d 100644
--- a/eeschema/sch_base_frame.cpp
+++ b/eeschema/sch_base_frame.cpp
@@ -253,6 +253,9 @@ void SCH_BASE_FRAME::UpdateStatusBar()
line.Printf( locformatter, dXpos, dYpos, hypot( dXpos, dYpos ) );
SetStatusText( line, 3 );
+// refresh grid display
+DisplayGridMsg();
+
// refresh units display
DisplayUnitsMsg();
}
diff --git a/gerbview/gerbview_frame.cpp b/gerbview/gerbview_frame.cpp
index d2c7d22e7..005abe000 100644
--- a/gerbview/gerbview_frame.cpp
+++ b/gerbview/gerbview_frame.cpp
@@ -986,6 +986,42 @@ void GERBVIEW_FRAME::SetGridColor( COLOR4D aColor )
}
+/*
+ * Display the grid status.
+ */
+void GERBVIEW_FRAME::DisplayGridMsg()
+{
+wxString line;
+wxString gridformatter;
+
+switch( m_UserUnits )
+{
+case INCHES:
+gridformatter = "grid X %.6f Y %.6f";
+break;
+
+case MILLIMETRES:
+gridformatter = "grid X %.6f Y %.6f";
+break;
+
+default:
+gridformatter = "grid X %f Y %f";
+break;
+}
+
+BASE_SCREEN* screen = GetScreen();
+wxArrayString gridsList;
+
+int icurr = screen->BuildGridsChoiceList( gridsList, m_UserUnits != INCHES );
+GRID_TYPE& grid = screen->GetGrid( icurr );
+double grid_x = To_User_Unit( m_UserUnits, grid.m_Size.x );
+double grid_y = To_User_Unit( m_UserUnits, grid.m_Size.y );
+line.Printf( gridformatter, grid_x, grid_y );
+
+SetStatusText( line, 4 );
+}
+
+
void GERBVIEW_FRAME::UpdateStatusBar()
{
EDA_DRAW_FRAME::UpdateStatusBar();
@@ -1070,6 +1106,8 @@ void GERBVIEW_FRAME::UpdateStatusBar()
line.Printf( relformatter, dXpos, dYpos, hypot( dXpos, dYpos ) );
SetStatusText( line, 3 );
}
+
+DisplayGridMsg();
}
diff --git a/gerbview/gerbview_frame.h b/gerbview/gerbview_frame.h
index
Re: [Kicad-developers] Error regarding mutex?
Yep, it seems somehow was being included for that file from a file that Jeff just removed it from. This patch adds it where it should be, so it now can compile on my machine. On Wed, Jun 5, 2019 at 11:27 PM Nick Østergaard wrote: > I see the same. > > tor. 6. jun. 2019 00.04 skrev Steven A. Falco : > >> On 6/5/19 5:50 PM, Steven A. Falco wrote: >> > I just started getting the following error on Linux. Is anyone else >> seeing this? >> >> Looks like it is coming from commit >> 6fab7cc02512ddc47d42403d4d1ea3f88f832d14. If I remove that one, the build >> works. >> >> > >> > Steve >> > >> > [ 59%] Building CXX object >> pcbnew/connectivity/CMakeFiles/connectivity.dir/connectivity_algo.cpp.o >> > cd /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity && >> /usr/bin/c++ -DGLM_FORCE_CTOR_INIT -DHAVE_STDINT_H >> -DKICAD_CONFIG_DIR=kicad -DKICAD_SCRIPTING -DKICAD_SCRIPTING_ACTION_MENU >> -DKICAD_SCRIPTING_MODULES -DKICAD_SCRIPTING_PYTHON3 >> -DKICAD_SCRIPTING_WXPYTHON -DKICAD_SCRIPTING_WXPYTHON_PHOENIX -DKICAD_SPICE >> -DKICAD_USE_OCE -DPCBNEW -DUSE_WX_OVERLAY -DWXUSINGDLL -DWX_COMPATIBILITY >> -D_FILE_OFFSET_BITS=64 -D__WXGTK__ >> -I/builddir/build/BUILD/kicad-r16003-6fab7cc0/include >> -I/builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/. >> -I/builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/.. >> -I/builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../../include >> -I/builddir/build/BUILD/kicad-r16003-6fab7cc0 -I/usr/include/python3.7m >> -I/builddir/build/BUILD/kicad-r16003-6fab7cc0/scripting >> -I/builddir/build/BUILD/kicad-r16003-6fab7cc0/bitmaps_png/include >> -I/builddir/build/BUILD/kicad-r16003-6fab7cc0/polygon/include -isystem >> /usr/lib64/wx/include/gtk3-unicode-3.0 -isystem /usr/include/wx-3.0 -Wall >> -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 >> -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong >> -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 >> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic >> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection >> -Wsuggest-override -Werror=vla -pthread -g3 -ggdb3 -DDEBUG >> -Wno-deprecated-declarations -fPIC -fvisibility=hidden >> -fvisibility-inlines-hidden -std=gnu++11 -o >> CMakeFiles/connectivity.dir/connectivity_algo.cpp.o -c >> /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/connectivity_algo.cpp >> > make[2]: Leaving directory '/builddir/build/BUILD/kicad-r16003-6fab7cc0' >> > BUILDSTDERR: In file included from >> /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../connectivity/connectivity_algo.h:47, >> > BUILDSTDERR: from >> /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/connectivity_algo.cpp:25: >> > BUILDSTDERR: >> /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../connectivity/connectivity_data.h:238:10: >> error: 'mutex' in namespace 'std' does not name a type >> > BUILDSTDERR: 238 | std::mutex& GetLock() >> > BUILDSTDERR: | ^ >> > BUILDSTDERR: In file included from >> /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../connectivity/connectivity_algo.h:47, >> > BUILDSTDERR: from >> /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/connectivity_algo.cpp:25: >> > BUILDSTDERR: >> /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../connectivity/connectivity_data.h:1:1: >> note: 'std::mutex' is defined in header ''; did you forget to >> '#include '? >> > BUILDSTDERR: +++ |+#include >> > BUILDSTDERR: 1 | /* >> > BUILDSTDERR: In file included from >> /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../connectivity/connectivity_algo.h:47, >> > BUILDSTDERR: from >> /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/connectivity_algo.cpp:25: >> > BUILDSTDERR: >> /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../connectivity/connectivity_data.h:262:10: >> error: 'mutex' in namespace 'std' does not name a type >> > BUILDSTDERR: 262 | std::mutex m_lock; >> > BUILDSTDERR: | ^ >> > BUILDSTDERR: >> /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../connectivity/connectivity_data.h:262:5: >> note: 'std::mutex' is defined in header ''; did you forget to >> '#include '? >> > BUILDSTDERR: 262 | std::mutex m_lock; >> > BUILDSTDERR: | ^~~ >> > BUILDSTDERR: In file included from >> /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../connectivity/connectivity_algo.h:48, >> > BUILDSTDERR: from >> /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/connectivity_algo.cpp:25: >> > BUILDSTDERR: >> /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../connectivity/connectivity_items.h:176:10: >> error: 'mutex' in namespace 'std' does not name a type >> > BUILDSTDERR: 176
Re: [Kicad-developers] Error regarding mutex?
I see the same. tor. 6. jun. 2019 00.04 skrev Steven A. Falco : > On 6/5/19 5:50 PM, Steven A. Falco wrote: > > I just started getting the following error on Linux. Is anyone else > seeing this? > > Looks like it is coming from commit > 6fab7cc02512ddc47d42403d4d1ea3f88f832d14. If I remove that one, the build > works. > > > > > Steve > > > > [ 59%] Building CXX object > pcbnew/connectivity/CMakeFiles/connectivity.dir/connectivity_algo.cpp.o > > cd /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity && > /usr/bin/c++ -DGLM_FORCE_CTOR_INIT -DHAVE_STDINT_H > -DKICAD_CONFIG_DIR=kicad -DKICAD_SCRIPTING -DKICAD_SCRIPTING_ACTION_MENU > -DKICAD_SCRIPTING_MODULES -DKICAD_SCRIPTING_PYTHON3 > -DKICAD_SCRIPTING_WXPYTHON -DKICAD_SCRIPTING_WXPYTHON_PHOENIX -DKICAD_SPICE > -DKICAD_USE_OCE -DPCBNEW -DUSE_WX_OVERLAY -DWXUSINGDLL -DWX_COMPATIBILITY > -D_FILE_OFFSET_BITS=64 -D__WXGTK__ > -I/builddir/build/BUILD/kicad-r16003-6fab7cc0/include > -I/builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/. > -I/builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/.. > -I/builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../../include > -I/builddir/build/BUILD/kicad-r16003-6fab7cc0 -I/usr/include/python3.7m > -I/builddir/build/BUILD/kicad-r16003-6fab7cc0/scripting > -I/builddir/build/BUILD/kicad-r16003-6fab7cc0/bitmaps_png/include > -I/builddir/build/BUILD/kicad-r16003-6fab7cc0/polygon/include -isystem > /usr/lib64/wx/include/gtk3-unicode-3.0 -isystem /usr/include/wx-3.0 -Wall > -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 > -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong > -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 > -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic > -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection > -Wsuggest-override -Werror=vla -pthread -g3 -ggdb3 -DDEBUG > -Wno-deprecated-declarations -fPIC -fvisibility=hidden > -fvisibility-inlines-hidden -std=gnu++11 -o > CMakeFiles/connectivity.dir/connectivity_algo.cpp.o -c > /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/connectivity_algo.cpp > > make[2]: Leaving directory '/builddir/build/BUILD/kicad-r16003-6fab7cc0' > > BUILDSTDERR: In file included from > /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../connectivity/connectivity_algo.h:47, > > BUILDSTDERR: from > /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/connectivity_algo.cpp:25: > > BUILDSTDERR: > /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../connectivity/connectivity_data.h:238:10: > error: 'mutex' in namespace 'std' does not name a type > > BUILDSTDERR: 238 | std::mutex& GetLock() > > BUILDSTDERR: | ^ > > BUILDSTDERR: In file included from > /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../connectivity/connectivity_algo.h:47, > > BUILDSTDERR: from > /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/connectivity_algo.cpp:25: > > BUILDSTDERR: > /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../connectivity/connectivity_data.h:1:1: > note: 'std::mutex' is defined in header ''; did you forget to > '#include '? > > BUILDSTDERR: +++ |+#include > > BUILDSTDERR: 1 | /* > > BUILDSTDERR: In file included from > /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../connectivity/connectivity_algo.h:47, > > BUILDSTDERR: from > /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/connectivity_algo.cpp:25: > > BUILDSTDERR: > /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../connectivity/connectivity_data.h:262:10: > error: 'mutex' in namespace 'std' does not name a type > > BUILDSTDERR: 262 | std::mutex m_lock; > > BUILDSTDERR: | ^ > > BUILDSTDERR: > /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../connectivity/connectivity_data.h:262:5: > note: 'std::mutex' is defined in header ''; did you forget to > '#include '? > > BUILDSTDERR: 262 | std::mutex m_lock; > > BUILDSTDERR: | ^~~ > > BUILDSTDERR: In file included from > /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../connectivity/connectivity_algo.h:48, > > BUILDSTDERR: from > /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/connectivity_algo.cpp:25: > > BUILDSTDERR: > /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../connectivity/connectivity_items.h:176:10: > error: 'mutex' in namespace 'std' does not name a type > > BUILDSTDERR: 176 | std::mutex m_listLock; > > BUILDSTDERR: | ^ > > BUILDSTDERR: > /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../connectivity/connectivity_items.h:1:1: > note: 'std::mutex' is defined in header ''; did you forget to > '#include '? > > BUILDSTDERR: +++ |+#include > > BUILDSTDER
Re: [Kicad-developers] Error regarding mutex?
On 6/5/19 5:50 PM, Steven A. Falco wrote: > I just started getting the following error on Linux. Is anyone else seeing > this? Looks like it is coming from commit 6fab7cc02512ddc47d42403d4d1ea3f88f832d14. If I remove that one, the build works. > > Steve > > [ 59%] Building CXX object > pcbnew/connectivity/CMakeFiles/connectivity.dir/connectivity_algo.cpp.o > cd /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity && > /usr/bin/c++ -DGLM_FORCE_CTOR_INIT -DHAVE_STDINT_H -DKICAD_CONFIG_DIR=kicad > -DKICAD_SCRIPTING -DKICAD_SCRIPTING_ACTION_MENU -DKICAD_SCRIPTING_MODULES > -DKICAD_SCRIPTING_PYTHON3 -DKICAD_SCRIPTING_WXPYTHON > -DKICAD_SCRIPTING_WXPYTHON_PHOENIX -DKICAD_SPICE -DKICAD_USE_OCE -DPCBNEW > -DUSE_WX_OVERLAY -DWXUSINGDLL -DWX_COMPATIBILITY -D_FILE_OFFSET_BITS=64 > -D__WXGTK__ -I/builddir/build/BUILD/kicad-r16003-6fab7cc0/include > -I/builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/. > -I/builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/.. > -I/builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../../include > -I/builddir/build/BUILD/kicad-r16003-6fab7cc0 -I/usr/include/python3.7m > -I/builddir/build/BUILD/kicad-r16003-6fab7cc0/scripting > -I/builddir/build/BUILD/kicad-r16003-6fab7cc0/bitmaps_png/include > -I/builddir/build/BUILD/kicad-r16003-6fab7cc0/polygon/include -isystem > /usr/lib64/wx/include/gtk3-unicode-3.0 -isystem /usr/include/wx-3.0 -Wall > -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 > -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong > -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 > -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic > -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection > -Wsuggest-override -Werror=vla -pthread -g3 -ggdb3 -DDEBUG > -Wno-deprecated-declarations -fPIC -fvisibility=hidden > -fvisibility-inlines-hidden -std=gnu++11 -o > CMakeFiles/connectivity.dir/connectivity_algo.cpp.o -c > /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/connectivity_algo.cpp > make[2]: Leaving directory '/builddir/build/BUILD/kicad-r16003-6fab7cc0' > BUILDSTDERR: In file included from > /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../connectivity/connectivity_algo.h:47, > BUILDSTDERR: from > /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/connectivity_algo.cpp:25: > BUILDSTDERR: > /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../connectivity/connectivity_data.h:238:10: > error: 'mutex' in namespace 'std' does not name a type > BUILDSTDERR: 238 | std::mutex& GetLock() > BUILDSTDERR: | ^ > BUILDSTDERR: In file included from > /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../connectivity/connectivity_algo.h:47, > BUILDSTDERR: from > /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/connectivity_algo.cpp:25: > BUILDSTDERR: > /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../connectivity/connectivity_data.h:1:1: > note: 'std::mutex' is defined in header ''; did you forget to > '#include '? > BUILDSTDERR: +++ |+#include > BUILDSTDERR: 1 | /* > BUILDSTDERR: In file included from > /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../connectivity/connectivity_algo.h:47, > BUILDSTDERR: from > /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/connectivity_algo.cpp:25: > BUILDSTDERR: > /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../connectivity/connectivity_data.h:262:10: > error: 'mutex' in namespace 'std' does not name a type > BUILDSTDERR: 262 | std::mutex m_lock; > BUILDSTDERR: | ^ > BUILDSTDERR: > /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../connectivity/connectivity_data.h:262:5: > note: 'std::mutex' is defined in header ''; did you forget to > '#include '? > BUILDSTDERR: 262 | std::mutex m_lock; > BUILDSTDERR: | ^~~ > BUILDSTDERR: In file included from > /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../connectivity/connectivity_algo.h:48, > BUILDSTDERR: from > /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/connectivity_algo.cpp:25: > BUILDSTDERR: > /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../connectivity/connectivity_items.h:176:10: > error: 'mutex' in namespace 'std' does not name a type > BUILDSTDERR: 176 | std::mutex m_listLock; > BUILDSTDERR: | ^ > BUILDSTDERR: > /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../connectivity/connectivity_items.h:1:1: > note: 'std::mutex' is defined in header ''; did you forget to > '#include '? > BUILDSTDERR: +++ |+#include > BUILDSTDERR: 1 | /* > BUILDSTDERR: > /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectiv
[Kicad-developers] Error regarding mutex?
I just started getting the following error on Linux. Is anyone else seeing this? Steve [ 59%] Building CXX object pcbnew/connectivity/CMakeFiles/connectivity.dir/connectivity_algo.cpp.o cd /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity && /usr/bin/c++ -DGLM_FORCE_CTOR_INIT -DHAVE_STDINT_H -DKICAD_CONFIG_DIR=kicad -DKICAD_SCRIPTING -DKICAD_SCRIPTING_ACTION_MENU -DKICAD_SCRIPTING_MODULES -DKICAD_SCRIPTING_PYTHON3 -DKICAD_SCRIPTING_WXPYTHON -DKICAD_SCRIPTING_WXPYTHON_PHOENIX -DKICAD_SPICE -DKICAD_USE_OCE -DPCBNEW -DUSE_WX_OVERLAY -DWXUSINGDLL -DWX_COMPATIBILITY -D_FILE_OFFSET_BITS=64 -D__WXGTK__ -I/builddir/build/BUILD/kicad-r16003-6fab7cc0/include -I/builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/. -I/builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/.. -I/builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../../include -I/builddir/build/BUILD/kicad-r16003-6fab7cc0 -I/usr/include/python3.7m -I/builddir/build/BUILD/kicad-r16003-6fab7cc0/scripting -I/builddir/build/BUILD/kicad-r16003-6fab7cc0/bitmaps_png/include -I/builddir/build/BUILD/kicad-r16003-6fab7cc0/polygon/include -isystem /usr/lib64/wx/include/gtk3-unicode-3.0 -isystem /usr/include/wx-3.0 -Wall -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -Wsuggest-override -Werror=vla -pthread -g3 -ggdb3 -DDEBUG -Wno-deprecated-declarations -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -std=gnu++11 -o CMakeFiles/connectivity.dir/connectivity_algo.cpp.o -c /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/connectivity_algo.cpp make[2]: Leaving directory '/builddir/build/BUILD/kicad-r16003-6fab7cc0' BUILDSTDERR: In file included from /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../connectivity/connectivity_algo.h:47, BUILDSTDERR: from /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/connectivity_algo.cpp:25: BUILDSTDERR: /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../connectivity/connectivity_data.h:238:10: error: 'mutex' in namespace 'std' does not name a type BUILDSTDERR: 238 | std::mutex& GetLock() BUILDSTDERR: | ^ BUILDSTDERR: In file included from /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../connectivity/connectivity_algo.h:47, BUILDSTDERR: from /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/connectivity_algo.cpp:25: BUILDSTDERR: /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../connectivity/connectivity_data.h:1:1: note: 'std::mutex' is defined in header ''; did you forget to '#include '? BUILDSTDERR: +++ |+#include BUILDSTDERR: 1 | /* BUILDSTDERR: In file included from /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../connectivity/connectivity_algo.h:47, BUILDSTDERR: from /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/connectivity_algo.cpp:25: BUILDSTDERR: /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../connectivity/connectivity_data.h:262:10: error: 'mutex' in namespace 'std' does not name a type BUILDSTDERR: 262 | std::mutex m_lock; BUILDSTDERR: | ^ BUILDSTDERR: /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../connectivity/connectivity_data.h:262:5: note: 'std::mutex' is defined in header ''; did you forget to '#include '? BUILDSTDERR: 262 | std::mutex m_lock; BUILDSTDERR: | ^~~ BUILDSTDERR: In file included from /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../connectivity/connectivity_algo.h:48, BUILDSTDERR: from /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/connectivity_algo.cpp:25: BUILDSTDERR: /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../connectivity/connectivity_items.h:176:10: error: 'mutex' in namespace 'std' does not name a type BUILDSTDERR: 176 | std::mutex m_listLock; BUILDSTDERR: | ^ BUILDSTDERR: /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../connectivity/connectivity_items.h:1:1: note: 'std::mutex' is defined in header ''; did you forget to '#include '? BUILDSTDERR: +++ |+#include BUILDSTDERR: 1 | /* BUILDSTDERR: /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../connectivity/connectivity_items.h: In member function 'void CN_ITEM::Connect(CN_ITEM*)': BUILDSTDERR: /builddir/build/BUILD/kicad-r16003-6fab7cc0/pcbnew/connectivity/../connectivity/connectivity_items.h:316:14: error: 'lock_guard' is not a member of 'std' BUILDSTDERR: 316 | std::lock_guard lock( m_listLock )
Re: [Kicad-developers] Latest info on copper zones using solid polygons without outline thickness.
On 2019-06-05 14:33, jp charras wrote: I just committed the final version of fill algo to build solid polygons in zones: The current algo creates slightly smaller polygons and draw/plot the polygon outline with thick segments. It gives a very good look but creates some issue: - For very large boards, drawing outlines can be time consumming. - When exporting copper zones, the exported polygons are smaller than the actual shape. The new algo creates filled polygons without thick outlines (therefore having the right shape) By default, the new algo is not enabled. To enable it - In "kicad_advanced" file config, add "ForceThickZones=0" - In Pcbnew, "Board Setup/Design Rules", in "Option to fill polygons in zones", select "No Outline" Hi JP- A few questions on this. - Since this is a board-level setting, is there a reason to put the file format tag in each zone container? - The 3d viewer is about 25% slower on reload time with this option on. Do you see this in your tests as well? - Do we need to hard-code the inflate segments in computeRawFilledAreas at 16? I'm also seeing some floating copper after enabling the option. See attached image. Best- Seth___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Latest info on copper zones using solid polygons without outline thickness.
Le 05/06/2019 à 21:16, Tomasz Wlostowski a écrit : > On 05/06/2019 20:33, jp charras wrote: >> Could you test this version on your very large board, and said me if it >> fixes the very long time calculation to redraw the board on OpenGL. >> Thanks. > > Sure, will do. Sorry that I didn't follow the whole discussion, where > can I find the latest code? > > Tom > It is on the master branch (just committed). -- 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] Latest info on copper zones using solid polygons without outline thickness.
On 05/06/2019 20:33, jp charras wrote: > Could you test this version on your very large board, and said me if it > fixes the very long time calculation to redraw the board on OpenGL. > Thanks. Sure, will do. Sorry that I didn't follow the whole discussion, where can I find the latest code? 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
[Kicad-developers] Latest info on copper zones using solid polygons without outline thickness.
I just committed the final version of fill algo to build solid polygons in zones: The current algo creates slightly smaller polygons and draw/plot the polygon outline with thick segments. It gives a very good look but creates some issue: - For very large boards, drawing outlines can be time consumming. - When exporting copper zones, the exported polygons are smaller than the actual shape. The new algo creates filled polygons without thick outlines (therefore having the right shape) By default, the new algo is not enabled. To enable it - In "kicad_advanced" file config, add "ForceThickZones=0" - In Pcbnew, "Board Setup/Design Rules", in "Option to fill polygons in zones", select "No Outline" If this option is enabled, after refilling zones, the board file will be not readable by previous Pcbnew versions. If not, after refilling zones, board file format is not modified. @Tom, Could you test this version on your very large board, and said me if it fixes the very long time calculation to redraw the board on OpenGL. 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] [RFC] Test for Copper zones using solid polygons without outline thickness.
Le 05/06/2019 à 19:00, Wayne Stambaugh a écrit : > > I wouldn't mind doing some more testing as well given the complexity and > potential issues with this change. Having a public repo to clone from > would make life easier than patch sets given the amount of code changes. > > Wayne > Hi Wayne, The amount of code *actually* involved in the zone filling algo change is very small: perhaps less than 30 lines of code ( 60 to 80 lines including comments). Of course my commits are bigger, but "large" changes are mainly in .fbp files and are cosmetic changes. The actual change in panel_setup_feature_change is only adding two wxCheckBox to enable/disable the new fill algo. All others are cosmetic changes (I hope: enhancements). The main risk is not in our code (30 lines of code directly related in zone_filler.cpp) : it is in Clipper Inflate transform code: We are using inflate since a long time in our code with no issue, but mainly to inflate convex polygons. The risk is for polygons having acute angles between 2 edge segments, in some corner cases we don't yet know. (well: "corner case" is the right word here...). I am confident with Clipper library. As I said previously, it is the best library we used for polygon handling. However we cannot exclude some annoying bug for us. Only many tests made by many users on many boards will give us the answer. I just committed my last changes (the 30 risky lines of code). Most of my tests were related to "how to chose the number of segments in arc to polygons transform", and this is the reason I needed the Seth's work on arc to polygon changes. In fact, removing the thick outlines in solid areas was a basic and minor work. -- 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] Copy&pasting in eeschema
On 2019-06-05 13:31, Tom Crane wrote: I have had problems copying and pasting certain individual components, using the right-click method for both. The symptom was no-effect when right-click pasting despite the paste menu item not being greyed out. Further investigation showed the components (eg. SM resistors) which would not copy&paste had top-bit-set characters in some of their fields whereas otherwise identical components without such characters copy&pasted OK. Here is an example of a problem component definition; Hi Tom- This is a curious issue and sounds like it might be internal to our string handling. Could you please file a bug report at the bug tracker? It will greatly assist our ability to keep track of the problem, the versions it affects and the resolution. 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
[Kicad-developers] Copy&pasting in eeschema
I have had problems copying and pasting certain individual components, using the right-click method for both. The symptom was no-effect when right-click pasting despite the paste menu item not being greyed out. Further investigation showed the components (eg. SM resistors) which would not copy&paste had top-bit-set characters in some of their fields whereas otherwise identical components without such characters copy&pasted OK. Here is an example of a problem component definition; $Comp L Device:R R8 U 1 1 5CCB92EB P 4800 6150 F 0 "R8" V 4700 6050 50 C CNN F 1 "10k" V 4700 6200 50 C CNN F 2 "Resistor_SMD:R_0805_2012Metric" V 4730 6150 50 0001 C CNN F 3 "https://docs-emea.rs-online.com/webdocs/14ae/0900766b814ae02e.pdf"; H 4800 6150 50 0001 C CNN F 4 "10kΩ 0805 Thin Film Surface Mount Fixed Resistor ±1% 0.125W CRT0805-FZ-1002ELF" V 4800 6150 50 0001 C CNN "Data" F 5 "RS Stock No. 740-9224" V 4800 6150 50 0001 C CNN "Order code" 14800 6150 -1 001 $EndComp Here is a hexdump of the above, 24 43 6f 6d 70 0a 4c 20 44 65 76 69 63 65 3a 52 $Comp.L Device:R 0010 20 52 38 0a 55 20 31 20 31 20 35 43 43 42 39 32R8.U 1 1 5CCB92 0020 45 42 0a 50 20 34 38 30 30 20 36 31 35 30 0a 46 EB.P 4800 6150.F 0030 20 30 20 22 52 38 22 20 56 20 34 37 30 30 20 360 "R8" V 4700 6 0040 30 35 30 20 35 30 20 20 30 30 30 30 20 43 20 43 050 50 C C 0050 4e 4e 0a 46 20 31 20 22 31 30 6b 22 20 56 20 34 NN.F 1 "10k" V 4 0060 37 30 30 20 36 32 30 30 20 35 30 20 20 30 30 30 700 6200 50 000 0070 30 20 43 20 43 4e 4e 0a 46 20 32 20 22 52 65 73 0 C CNN.F 2 "Res 0080 69 73 74 6f 72 5f 53 4d 44 3a 52 5f 30 38 30 35 istor_SMD:R_0805 0090 5f 32 30 31 32 4d 65 74 72 69 63 22 20 56 20 34 _2012Metric" V 4 00a0 37 33 30 20 36 31 35 30 20 35 30 20 20 30 30 30 730 6150 50 000 00b0 31 20 43 20 43 4e 4e 0a 46 20 33 20 22 68 74 74 1 C CNN.F 3 "htt 00c0 70 73 3a 2f 2f 64 6f 63 73 2d 65 6d 65 61 2e 72 ps://docs-emea.r 00d0 73 2d 6f 6e 6c 69 6e 65 2e 63 6f 6d 2f 77 65 62 s-online.com/web 00e0 64 6f 63 73 2f 31 34 61 65 2f 30 39 30 30 37 36 docs/14ae/090076 00f0 36 62 38 31 34 61 65 30 32 65 2e 70 64 66 22 20 6b814ae02e.pdf" 0100 48 20 34 38 30 30 20 36 31 35 30 20 35 30 20 20 H 4800 6150 50 0110 30 30 30 31 20 43 20 43 4e 4e 0a 46 20 34 20 22 0001 C CNN.F 4 " 0120 31 30 6b ce a9 20 30 38 30 35 20 54 68 69 6e 20 10k.. 0805 Thin 0130 46 69 6c 6d 20 53 75 72 66 61 63 65 20 4d 6f 75 Film Surface Mou 0140 6e 74 20 46 69 78 65 64 20 52 65 73 69 73 74 6f nt Fixed Resisto 0150 72 20 c2 b1 31 25 20 30 2e 31 32 35 57 20 43 52 r ..1% 0.125W CR 0160 54 30 38 30 35 2d 46 5a 2d 31 30 30 32 45 4c 46 T0805-FZ-1002ELF 0170 22 20 56 20 34 38 30 30 20 36 31 35 30 20 35 30 " V 4800 6150 50 0180 20 20 30 30 30 31 20 43 20 43 4e 4e 20 22 44 61 0001 C CNN "Da 0190 74 61 22 0a 46 20 35 20 22 52 53 20 53 74 6f 63 ta".F 5 "RS Stoc 01a0 6b 20 4e 6f 2e 20 37 34 30 2d 39 32 32 34 22 20 k No. 740-9224" 01b0 56 20 34 38 30 30 20 36 31 35 30 20 35 30 20 20 V 4800 6150 50 01c0 30 30 30 31 20 43 20 43 4e 4e 20 22 4f 72 64 65 0001 C CNN "Orde 01d0 72 20 63 6f 64 65 22 0a 20 20 20 20 20 20 20 20 r code". 01e0 31 20 20 20 20 34 38 30 30 20 36 31 35 30 0a 20 14800 6150. 01f0 20 20 20 20 20 20 20 2d 31 20 20 20 30 20 20 20 -1 0 0200 20 30 20 20 20 20 31 20 20 20 0a 24 45 6e 64 4301 .$EndC 0210 6f 6d 70 0a omp. Duplication always worked but of course was no use for copying between sheets. After some more investigation I discovered changing the LANG setting in my locale enabled all components to be copy&pasted. Previously I had LANG=en_GB (originally needed due to limitations in the window manager I use). Changing it to en_GB.UTF-8 fixed the problem. I know there have been other problems with copy&pasting in the past. Could I make a feature-request for a diagnostic printed message/GUI pop-up to be produced when the copy to the clipboard or the paste from it fails, rather than just silently failing which is frustrating and not helpful for problem diagnosis? Thanks Tom Crane Kicad detail: Application: KiCad Version: (5.1.0-868-g0ea75cb4e), release build Libraries: wxWidgets 3.0.4 libcurl/7.65.0 OpenSSL/1.1.1c zlib/1.2.11 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.1.1) libssh2/1.8.2 nghttp2/1.38.0 Platform: Linux 4.19.47 x86_64, 64 bit, Little endian, wxGTK Build Info: wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24 Boost: 1.69.0 OpenCASCADE Community Edition: 6.9.1 Curl: 7.65.0 Compiler: GCC 9.1.0 with C++ ABI 1013 Build settings: USE_WX_GRAPHICS_CONTEXT=OFF USE_WX_OVERLAY=OFF KICAD_SCRIPTING=ON KICAD_SCRIPTING_MODULES=ON KICAD_SCRIPTING_PYTHON3=OFF KICAD_SCRIPTING_WXPYTHON=
Re: [Kicad-developers] CMake KICAD_SCRIPTING Options Hierarchy
On 6/5/19 1:14 PM, Seth Hillbrand wrote: > On 2019-06-05 13:03, Ian McInerney wrote: >> I was just noticing based on a post on the kicad forums that the CMake >> script will forcefully enable KICAD_SCRIPTING if either >> KICAD_SCRIPTING_ACTION_MENUS or KICAD_SCRIPTING_MODULES is turned on. >> This means to really disable scripting the user has to explicitly >> force all 3 to off (since they are all on by default). Is there are >> reason for making those two options take priority over the overall >> scripting support option instead of having KICAD_SCRIPTING take >> priority and disable those two when it is disabled? It seems more >> intuitive if KICAD_SCRIPTING has overall control of the scripting >> environment, and the others are dependent upon it. > > I'd be in favor of collapsing all scripting into a single option. > Anyone feel like that might cause issues? > > -Seth Some users may prefer scripting support without the modules and/or the scripting actions menu. It was split up this way for more granular control over what gets installed. I'm not opposed to unifying this but others may feel differently. Honestly, I would rather users stick to using nightly builds rather than build KiCad themselves. Developers are expected to learn how the KiCad configuration works. ___ 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] CMake KICAD_SCRIPTING Options Hierarchy
On 2019-06-05 13:03, Ian McInerney wrote: I was just noticing based on a post on the kicad forums that the CMake script will forcefully enable KICAD_SCRIPTING if either KICAD_SCRIPTING_ACTION_MENUS or KICAD_SCRIPTING_MODULES is turned on. This means to really disable scripting the user has to explicitly force all 3 to off (since they are all on by default). Is there are reason for making those two options take priority over the overall scripting support option instead of having KICAD_SCRIPTING take priority and disable those two when it is disabled? It seems more intuitive if KICAD_SCRIPTING has overall control of the scripting environment, and the others are dependent upon it. I'd be in favor of collapsing all scripting into a single option. Anyone feel like that might cause issues? -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] CMake KICAD_SCRIPTING Options Hierarchy
I was just noticing based on a post on the kicad forums that the CMake script will forcefully enable KICAD_SCRIPTING if either KICAD_SCRIPTING_ACTION_MENUS or KICAD_SCRIPTING_MODULES is turned on. This means to really disable scripting the user has to explicitly force all 3 to off (since they are all on by default). Is there are reason for making those two options take priority over the overall scripting support option instead of having KICAD_SCRIPTING take priority and disable those two when it is disabled? It seems more intuitive if KICAD_SCRIPTING has overall control of the scripting environment, and the others are dependent upon it. This hierarchy is not actually mentioned in any of the build docs here http://docs.kicad-pcb.org/doxygen/md_Documentation_development_compiling.html (and the docs seem to be slightly out of date also, since they say KICAD_SCRIPTING_ACTION_MENU defaults to off when it is actually on by default), so if nothing else it would be good to mention it in the build docs so people who really don't want scripting know to disable all 3. -Ian ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [RFC] Test for Copper zones using solid polygons without outline thickness.
On 6/5/19 11:55 AM, Seth Hillbrand wrote: > On 2019-06-05 10:09, jp charras wrote: >> Le 05/06/2019 à 15:40, Wayne Stambaugh a écrit : >>> On 6/5/19 7:20 AM, jp charras wrote: Le 04/06/2019 à 22:51, Wayne Stambaugh a écrit : > On 6/4/19 4:25 PM, Seth Hillbrand wrote: >> On 2019-05-31 07:25, Wayne Stambaugh wrote: >>> On 5/30/19 4:53 PM, Seth Hillbrand wrote: On 2019-05-30 15:00, jp charras wrote: > Le 29/05/2019 à 21:31, Seth Hillbrand a écrit : >> On 2019-05-29 10:33, jp charras wrote: >>> Attached a patch that modify the way filled areas (solid >>> polygons) >>> are >>> built in copper areas. >>> >>> Currently, solid polygons are slightly smaller than the exact >>> area, and >>> the polygon outlines have a thickness to fill the exact area. >>> With this patch, polygon outlines have no thickness and the >>> polygons >>> have the exact area. >>> >>> To test it on a given zone, the zone setting must be edited >>> with the >>> "Fill polys without thick outline" checked. >> >> >> Hi JP- >> >> Why did you decide to make this a user option? Is there some >> feature >> that it prevents that a user would want for some areas but not >> for >> others? >> >> I tested it with a large board and it reduces the polygon point >> count by >> almost 50% (!) for complex fills. If I zoom in on an edge, it >> appears >> that the approximation count is substantially coarsened by the >> patch. >> See attached image. The edge on the right is with the new option >> enabled. The edge of the left is without the new option. >> >> I didn't find any other issues. Large boards were much faster >> and >> DRC / >> plotting appear consistent between options (with the exception >> noted >> above) >> >> -Seth > > > Thanks Seth for your test. > > Currently, having a user option is useful to test and compare > the 2 > options (the current way, and the new way). OK. Makes sense. Instead of changing the board file, can we put the option in the advanced config file to enable our testing? It would be nice to avoid changing the file format here. >>> >>> I agree that the board file format should not change for rendering >>> configuration. Please make this a user option. >> >> >> Hi JP- >> >> Did you mean to push eb1faebf1? >> >> -Seth > > I thought this was not going to require any board file version > changes. > Did I miss something here? > > Wayne > Some clarification: I pushed some changes because maintaining my local branch against all changes in master branch was not always easy. >>> >>> I know keeping things rebased given the current development churn but >>> you should have held off committing the file format change before >>> committing the rest of the code that actually does anything with the >>> file format changes. How much longer before you merge the rest of the >>> changes? If it's going to be too long, we should probably revert your >>> initial commit. >> >> I'll commit the last change (in zone_filler) very soon. >> It is finalized on my computer and looks good. >> I just want to make more tests. >> >> Currently, the file format is not modified. >> ( changes are not yet enabled, because variables inside the code are >> fixed to a default value to use the current zone filled polygon way). >> >> When finalized, the new zone filling will be used only if the user >> activate it (until it become the default, after many tests) >> When not activated, the file format has no change. >> >> Commit eb1faebf1 prepares the change, but does not activate it. > > > Could we see and test what the changes are before they are committed? > I'm happy to use your launchpad branch if you could push it there. If > we are not making this a simple advanced config option, it would be > helpful to go over the details. > > > Best- > Seth > I wouldn't mind doing some more testing as well given the complexity and potential issues with this change. Having a public repo to clone from would make life easier than patch sets given the amount of code changes. Wayne ___ 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] [RFC] Test for Copper zones using solid polygons without outline thickness.
On 2019-06-05 10:09, jp charras wrote: Le 05/06/2019 à 15:40, Wayne Stambaugh a écrit : On 6/5/19 7:20 AM, jp charras wrote: Le 04/06/2019 à 22:51, Wayne Stambaugh a écrit : On 6/4/19 4:25 PM, Seth Hillbrand wrote: On 2019-05-31 07:25, Wayne Stambaugh wrote: On 5/30/19 4:53 PM, Seth Hillbrand wrote: On 2019-05-30 15:00, jp charras wrote: Le 29/05/2019 à 21:31, Seth Hillbrand a écrit : On 2019-05-29 10:33, jp charras wrote: Attached a patch that modify the way filled areas (solid polygons) are built in copper areas. Currently, solid polygons are slightly smaller than the exact area, and the polygon outlines have a thickness to fill the exact area. With this patch, polygon outlines have no thickness and the polygons have the exact area. To test it on a given zone, the zone setting must be edited with the "Fill polys without thick outline" checked. Hi JP- Why did you decide to make this a user option? Is there some feature that it prevents that a user would want for some areas but not for others? I tested it with a large board and it reduces the polygon point count by almost 50% (!) for complex fills. If I zoom in on an edge, it appears that the approximation count is substantially coarsened by the patch. See attached image. The edge on the right is with the new option enabled. The edge of the left is without the new option. I didn't find any other issues. Large boards were much faster and DRC / plotting appear consistent between options (with the exception noted above) -Seth Thanks Seth for your test. Currently, having a user option is useful to test and compare the 2 options (the current way, and the new way). OK. Makes sense. Instead of changing the board file, can we put the option in the advanced config file to enable our testing? It would be nice to avoid changing the file format here. I agree that the board file format should not change for rendering configuration. Please make this a user option. Hi JP- Did you mean to push eb1faebf1? -Seth I thought this was not going to require any board file version changes. Did I miss something here? Wayne Some clarification: I pushed some changes because maintaining my local branch against all changes in master branch was not always easy. I know keeping things rebased given the current development churn but you should have held off committing the file format change before committing the rest of the code that actually does anything with the file format changes. How much longer before you merge the rest of the changes? If it's going to be too long, we should probably revert your initial commit. I'll commit the last change (in zone_filler) very soon. It is finalized on my computer and looks good. I just want to make more tests. Currently, the file format is not modified. ( changes are not yet enabled, because variables inside the code are fixed to a default value to use the current zone filled polygon way). When finalized, the new zone filling will be used only if the user activate it (until it become the default, after many tests) When not activated, the file format has no change. Commit eb1faebf1 prepares the change, but does not activate it. Could we see and test what the changes are before they are committed? I'm happy to use your launchpad branch if you could push it there. If we are not making this a simple advanced config option, it would be helpful to go over the details. Best- Seth ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [RFC] Test for Copper zones using solid polygons without outline thickness.
Le 05/06/2019 à 15:40, Wayne Stambaugh a écrit : > On 6/5/19 7:20 AM, jp charras wrote: >> Le 04/06/2019 à 22:51, Wayne Stambaugh a écrit : >>> On 6/4/19 4:25 PM, Seth Hillbrand wrote: On 2019-05-31 07:25, Wayne Stambaugh wrote: > On 5/30/19 4:53 PM, Seth Hillbrand wrote: >> On 2019-05-30 15:00, jp charras wrote: >>> Le 29/05/2019 à 21:31, Seth Hillbrand a écrit : On 2019-05-29 10:33, jp charras wrote: > Attached a patch that modify the way filled areas (solid polygons) > are > built in copper areas. > > Currently, solid polygons are slightly smaller than the exact > area, and > the polygon outlines have a thickness to fill the exact area. > With this patch, polygon outlines have no thickness and the polygons > have the exact area. > > To test it on a given zone, the zone setting must be edited with the > "Fill polys without thick outline" checked. Hi JP- Why did you decide to make this a user option? Is there some feature that it prevents that a user would want for some areas but not for others? I tested it with a large board and it reduces the polygon point count by almost 50% (!) for complex fills. If I zoom in on an edge, it appears that the approximation count is substantially coarsened by the patch. See attached image. The edge on the right is with the new option enabled. The edge of the left is without the new option. I didn't find any other issues. Large boards were much faster and DRC / plotting appear consistent between options (with the exception noted above) -Seth >>> >>> >>> Thanks Seth for your test. >>> >>> Currently, having a user option is useful to test and compare the 2 >>> options (the current way, and the new way). >> >> OK. Makes sense. Instead of changing the board file, can we put the >> option in the advanced config file to enable our testing? It would be >> nice to avoid changing the file format here. > > I agree that the board file format should not change for rendering > configuration. Please make this a user option. Hi JP- Did you mean to push eb1faebf1? -Seth >>> >>> I thought this was not going to require any board file version changes. >>> Did I miss something here? >>> >>> Wayne >>> >> >> Some clarification: >> >> I pushed some changes because maintaining my local branch against all >> changes in master branch was not always easy. > > I know keeping things rebased given the current development churn but > you should have held off committing the file format change before > committing the rest of the code that actually does anything with the > file format changes. How much longer before you merge the rest of the > changes? If it's going to be too long, we should probably revert your > initial commit. I'll commit the last change (in zone_filler) very soon. It is finalized on my computer and looks good. I just want to make more tests. Currently, the file format is not modified. ( changes are not yet enabled, because variables inside the code are fixed to a default value to use the current zone filled polygon way). When finalized, the new zone filling will be used only if the user activate it (until it become the default, after many tests) When not activated, the file format has no change. Commit eb1faebf1 prepares the change, but does not activate it. > >> >> I do not yet committed the new zone fill algo living in zone_filler. >> It should happen very soon, after a few other tests. >> (note also, to be enabled, the advanced config file must be set) > > If this is the case, why did we just get a message on the dev mailing > list complaining about file compatibility with 5.1? If commit eb1faebf > uses the advanced config (which I'm not seeing) and the default is > disabled, why would this happen? Did you forget to merge the advanced > config part of your changes? This issue is not related to my commit that cannot yet change the file format. It is related to the new option to set the max error to approximate the arcs to polygons using a user defined value instead of a fixed value. In the dialog to set this value, I just added a comment to the existing dialog to explain the usefulness of this setting. > >> >> Now, about changes in file format, here are my thoughts: >> >> New zone filler algo is not "just" a rendering change. >> It modify many other things. >> >> These changes are not not due to a code change, but due to the fact the >> size/shape of solid polygons in zones are actually modified: >> Gerber files are modified. >> Connectivity is modified. >> >> Moreover, in order to remove thick outlines, the solid polygon shapes, >> once they are build, are inflate
Re: [Kicad-developers] [RFC] Test for Copper zones using solid polygons without outline thickness.
On 6/5/19 7:20 AM, jp charras wrote: > Le 04/06/2019 à 22:51, Wayne Stambaugh a écrit : >> On 6/4/19 4:25 PM, Seth Hillbrand wrote: >>> On 2019-05-31 07:25, Wayne Stambaugh wrote: On 5/30/19 4:53 PM, Seth Hillbrand wrote: > On 2019-05-30 15:00, jp charras wrote: >> Le 29/05/2019 à 21:31, Seth Hillbrand a écrit : >>> On 2019-05-29 10:33, jp charras wrote: Attached a patch that modify the way filled areas (solid polygons) are built in copper areas. Currently, solid polygons are slightly smaller than the exact area, and the polygon outlines have a thickness to fill the exact area. With this patch, polygon outlines have no thickness and the polygons have the exact area. To test it on a given zone, the zone setting must be edited with the "Fill polys without thick outline" checked. >>> >>> >>> Hi JP- >>> >>> Why did you decide to make this a user option? Is there some feature >>> that it prevents that a user would want for some areas but not for >>> others? >>> >>> I tested it with a large board and it reduces the polygon point >>> count by >>> almost 50% (!) for complex fills. If I zoom in on an edge, it appears >>> that the approximation count is substantially coarsened by the patch. >>> See attached image. The edge on the right is with the new option >>> enabled. The edge of the left is without the new option. >>> >>> I didn't find any other issues. Large boards were much faster and >>> DRC / >>> plotting appear consistent between options (with the exception noted >>> above) >>> >>> -Seth >> >> >> Thanks Seth for your test. >> >> Currently, having a user option is useful to test and compare the 2 >> options (the current way, and the new way). > > OK. Makes sense. Instead of changing the board file, can we put the > option in the advanced config file to enable our testing? It would be > nice to avoid changing the file format here. I agree that the board file format should not change for rendering configuration. Please make this a user option. >>> >>> >>> Hi JP- >>> >>> Did you mean to push eb1faebf1? >>> >>> -Seth >> >> I thought this was not going to require any board file version changes. >> Did I miss something here? >> >> Wayne >> > > Some clarification: > > I pushed some changes because maintaining my local branch against all > changes in master branch was not always easy. I know keeping things rebased given the current development churn but you should have held off committing the file format change before committing the rest of the code that actually does anything with the file format changes. How much longer before you merge the rest of the changes? If it's going to be too long, we should probably revert your initial commit. > > I do not yet committed the new zone fill algo living in zone_filler. > It should happen very soon, after a few other tests. > (note also, to be enabled, the advanced config file must be set) If this is the case, why did we just get a message on the dev mailing list complaining about file compatibility with 5.1? If commit eb1faebf uses the advanced config (which I'm not seeing) and the default is disabled, why would this happen? Did you forget to merge the advanced config part of your changes? > > Now, about changes in file format, here are my thoughts: > > New zone filler algo is not "just" a rendering change. > It modify many other things. > > These changes are not not due to a code change, but due to the fact the > size/shape of solid polygons in zones are actually modified: > Gerber files are modified. > Connectivity is modified. > > Moreover, in order to remove thick outlines, the solid polygon shapes, > once they are build, are inflated by zone min thickness/2> > I am really confident with the Clipper Library reliability, and the > Inflate function. > But previous experiences with other polygon libraries lead me to be > *very*careful. > I know Inflate transform is one of most hard to manage transform. > > I remember when we used boost::polygon, the first issue encountered was > reported one year after we started using it, and it was the reason we > was forced to use clipper. > > Therefore I want to be able to use the old (reliable...) way to build > the solid polygons, and to use the new way (without outline thickness). > > It imply the zones filled with the new way must have a flag to keep > trace of that. Fair enough. I misunderstood the original intent of this change. > > There is also an other (and important) problem: > We always try to keep Pcbnew compatible with old board files. > Without this flag, this is not possible: > * A old board generates broken Gerber files, unless zones are refilled, > but it imply a board change (and the fact the user knows that...). > By broken Ge
Re: [Kicad-developers] File format incompatibility between nightlies and 5.1 (max_error)
On 2019-06-05 08:35, Eeli Kaikkonen wrote: It was just found out (https://forum.kicad.info/t/bug-align-to-right-left-does-the-same-thing-on-bottom-side/17149/9) that commit 6bcf1839b7a6 added max_error which causes board to be incompatible between nightlies and 5.1. It's of course inevitable at some point, but I have asked earlier that developers would explicitly tell here or in the forum when that happens and how (I read the list but don't remember seeing a clear warning). Hi Eeli- Perhaps this message [1] was not clear enough. I will endeavour to make the warnings into their own messages in the future. I would caution against working with 5.1 and the nightlies on the same project. We will not only be adding new tags but we will be removing old tags that are no longer used. In this case, I have removed the segments per zone tag. This means that when opening a board in 5.1 after hand editing to remove the "max_error" tag will revert to the default segments per zone rather than what was in the file previously. This will probably not cause major issues unless you explicitly set the number before but in the future, removed tags might. Best- Seth [1] https://lists.launchpad.net/kicad-developers/msg40749.html ___ 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] File format incompatibility between nightlies and 5.1 (max_error)
Also reporter at https://bugs.launchpad.net/kicad/+bug/1831705 On Wed, 5 Jun 2019 at 14:36, Eeli Kaikkonen wrote: > > It was just found out > (https://forum.kicad.info/t/bug-align-to-right-left-does-the-same-thing-on-bottom-side/17149/9) > that commit 6bcf1839b7a6 added max_error which causes board to be > incompatible between nightlies and 5.1. It's of course inevitable at some > point, but I have asked earlier that developers would explicitly tell here or > in the forum when that happens and how (I read the list but don't remember > seeing a clear warning). > > It may be important to know; for example I can use nightlies at work but must > be careful so that I can continue with stable if nightlies don't work. > > For this specific problem there would be several possible solutions (at least > in my opinion) which would make the file format readable by 5.1.x, supposing > that otherwise the board files can still be read and edited. > > 1. Write the key/value to the file only if it's something else than the > default (i.e. changed explicitly). This was the case with hatched zone fills. > 2. Add the keyword to a bugfix release of 5.1 so that it can be ignored > (again, supposing that it can be ignored at all). It would help if someone > uses 5.1 nightlies or later the stable release. > 3. Create some generic system by which KiCad can ignore some future keywords > which aren't necessary to interpret. > > But over all I would ask information about incompatibilities. Thanks. > > Eeli Kaikkonen > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] File format incompatibility between nightlies and 5.1 (max_error)
It was just found out ( https://forum.kicad.info/t/bug-align-to-right-left-does-the-same-thing-on-bottom-side/17149/9) that commit 6bcf1839b7a6 added max_error which causes board to be incompatible between nightlies and 5.1. It's of course inevitable at some point, but I have asked earlier that developers would explicitly tell here or in the forum when that happens and how (I read the list but don't remember seeing a clear warning). It may be important to know; for example I can use nightlies at work but must be careful so that I can continue with stable if nightlies don't work. For this specific problem there would be several possible solutions (at least in my opinion) which would make the file format readable by 5.1.x, supposing that otherwise the board files can still be read and edited. 1. Write the key/value to the file only if it's something else than the default (i.e. changed explicitly). This was the case with hatched zone fills. 2. Add the keyword to a bugfix release of 5.1 so that it can be ignored (again, supposing that it can be ignored at all). It would help if someone uses 5.1 nightlies or later the stable release. 3. Create some generic system by which KiCad can ignore some future keywords which aren't necessary to interpret. But over all I would ask information about incompatibilities. Thanks. Eeli Kaikkonen ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [RFC] Test for Copper zones using solid polygons without outline thickness.
Le 04/06/2019 à 22:51, Wayne Stambaugh a écrit : > On 6/4/19 4:25 PM, Seth Hillbrand wrote: >> On 2019-05-31 07:25, Wayne Stambaugh wrote: >>> On 5/30/19 4:53 PM, Seth Hillbrand wrote: On 2019-05-30 15:00, jp charras wrote: > Le 29/05/2019 à 21:31, Seth Hillbrand a écrit : >> On 2019-05-29 10:33, jp charras wrote: >>> Attached a patch that modify the way filled areas (solid polygons) >>> are >>> built in copper areas. >>> >>> Currently, solid polygons are slightly smaller than the exact >>> area, and >>> the polygon outlines have a thickness to fill the exact area. >>> With this patch, polygon outlines have no thickness and the polygons >>> have the exact area. >>> >>> To test it on a given zone, the zone setting must be edited with the >>> "Fill polys without thick outline" checked. >> >> >> Hi JP- >> >> Why did you decide to make this a user option? Is there some feature >> that it prevents that a user would want for some areas but not for >> others? >> >> I tested it with a large board and it reduces the polygon point >> count by >> almost 50% (!) for complex fills. If I zoom in on an edge, it appears >> that the approximation count is substantially coarsened by the patch. >> See attached image. The edge on the right is with the new option >> enabled. The edge of the left is without the new option. >> >> I didn't find any other issues. Large boards were much faster and >> DRC / >> plotting appear consistent between options (with the exception noted >> above) >> >> -Seth > > > Thanks Seth for your test. > > Currently, having a user option is useful to test and compare the 2 > options (the current way, and the new way). OK. Makes sense. Instead of changing the board file, can we put the option in the advanced config file to enable our testing? It would be nice to avoid changing the file format here. >>> >>> I agree that the board file format should not change for rendering >>> configuration. Please make this a user option. >> >> >> Hi JP- >> >> Did you mean to push eb1faebf1? >> >> -Seth > > I thought this was not going to require any board file version changes. > Did I miss something here? > > Wayne > Some clarification: I pushed some changes because maintaining my local branch against all changes in master branch was not always easy. I do not yet committed the new zone fill algo living in zone_filler. It should happen very soon, after a few other tests. (note also, to be enabled, the advanced config file must be set) Now, about changes in file format, here are my thoughts: New zone filler algo is not "just" a rendering change. It modify many other things. These changes are not not due to a code change, but due to the fact the size/shape of solid polygons in zones are actually modified: Gerber files are modified. Connectivity is modified. Moreover, in order to remove thick outlines, the solid polygon shapes, once they are build, are inflated by zone min thickness/2 I am really confident with the Clipper Library reliability, and the Inflate function. But previous experiences with other polygon libraries lead me to be *very*careful. I know Inflate transform is one of most hard to manage transform. I remember when we used boost::polygon, the first issue encountered was reported one year after we started using it, and it was the reason we was forced to use clipper. Therefore I want to be able to use the old (reliable...) way to build the solid polygons, and to use the new way (without outline thickness). It imply the zones filled with the new way must have a flag to keep trace of that. There is also an other (and important) problem: We always try to keep Pcbnew compatible with old board files. Without this flag, this is not possible: * A old board generates broken Gerber files, unless zones are refilled, but it imply a board change (and the fact the user knows that...). By broken Gerber files I mean zones without thick lines can have very thin areas, not compatible with the zone settings. * A new board generates also broken Gerber files, unless zones are refilled, because filled areas are too big. It can happens if for some reasons we need to go back to the "old" (current) filling algo. I hope it does not happens, but who know. Note also files saved by the current pcbnew version are not compatible with 5.1.2 stable versions, due to the fact the "max_error" parameter is now stored in file. So to avoid predictable issues, I prefer have a flag stored in file (the cost is low), and a user settings to select the way the solid areas are built, at least for now, just in case... -- Jean-Pierre CHARRAS ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-develo
