[Kicad-developers] Importing DXF polygons in pcbnew vs. footprint editor
I am experimenting some more with importing DXF files into pcbnew and
the footprint editor as a filled polygon
and I have added some code to DXF2BRD_CONVERTER::addPolyline() to do
that so like so:
{
DRAWSEGMENT* poly = new DRAWSEGMENT( NULL );
std::vector wxPoint pts;
for( unsigned ii = 0; ii aData.vertlist.size(); ii++ )
{
DRW_Vertex* vertex = aData.vertlist[ii];
pts.push_back( wxPoint( mapX( vertex-basePoint.x ),
mapY( vertex-basePoint.y ) ) );
}
poly-SetType( PCB_ZONE_T );
poly-SetShape( S_POLYGON );
poly-SetLayer( ToLAYER_ID( m_brdLayer ) );
poly-SetWidth( mapDim( 0.001 ) );
poly-SetPolyPoints( pts );
m_newItemsList.push_back( poly );
}
This works in pcbnew and an imported polygon shape comes out in the pcb
file as:
(gr_poly (pts (xy 40 -1) (xy 40 0) (xy 50 0) (xy 50 -11) (xy 46 -11) (xy
46 -12) (xy 50 -12) (xy 50 -15) (xy 46 -15) (xy 46 -16) (xy 50 -16) (xy
50 -20) (xy 45 -20) (xy 45 -18) (xy 49 -18) (xy 49 -17) (xy 45 -17) (xy
45 -14) (xy 49 -14) (xy 49 -13) (xy 45 -13) (xy 45 -10) (xy 49 -10) (xy
49 -8) (xy 40 -8) (xy 40 -7) (xy 49 -7) (xy 49 -1)) (layer F.Cu) (width
0.001))
However, doing the same in the footprint editor, nothings shows up, but
when I save the footprint it has the following:
(fp_poly (pts) (layer F.Cu) (width 0.001))
So a fp_poly but with the XY points missing.
Anybody any idea where this is going wrong in the import. I can see some
differences (not pretending I fully understand them) between
InvokeDXFDialogBoardImport and InvokeDXFDialogModuleImport but I think
the problem seems to be much deeper.
Any pointers?
Marco
___
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] Use specific gerber extensions for inner Cu layers and the Edge_Cuts layer in preference to the default .gbr .
Thanks Wayne.
On this item, I noted that in dialog_plot_base.cpp the checkbox for
using these extensions are referred to as 'Protel'. Should we change
that to 'Altium' to stay with the times?
Marco
On 25-Jun-15 03:30, Wayne Stambaugh wrote:
Your patch was committed in the product branch r5818. Thank you for
your contribution to KiCad.
Cheers,
Wayne
On 6/21/2015 1:25 AM, Marco Hess wrote:
The attached patch is a minor fix to the Protel gerber file name
extensions to assign
a more specific extension to internal Cu layers as well as the Edge_Cuts
layer
as described here on the Altium site:
http://techdocs.altium.com/display/ADRR/WorkspaceManager_Dlg-GerberSetup_Form((Gerber+Setup))_AD
Regards,
Marco
diff --git a/pcbnew/pcbplot.cpp b/pcbnew/pcbplot.cpp
index 7d5527e..4b8f89e 100644
--- a/pcbnew/pcbplot.cpp
+++ b/pcbnew/pcbplot.cpp
@@ -55,7 +55,7 @@ const wxString GetGerberExtension( LAYER_NUM aLayer )
return wxT( gbl );
else
{
-return wxT( gbr );
+return wxString::Format( wxT( g%d ), aLayer+1 );
}
}
else
@@ -74,11 +74,12 @@ const wxString GetGerberExtension( LAYER_NUM aLayer )
case B_Mask:return wxT( gbs );
case F_Mask:return wxT( gts );
+case Edge_Cuts: return wxT( gm1 );
+
case Dwgs_User:
case Cmts_User:
case Eco1_User:
case Eco2_User:
-case Edge_Cuts:
default:return wxT( gbr );
}
}
___
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
--
Marco Hess
Through IP Pty. Ltd. - AUSTRALIA
www.through-ip.com | marco.h...@through-ip.com
p: +61 407 78 55 66 | f: +61 8 8121 6191
___
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] Use specific gerber extensions for inner Cu layers and the Edge_Cuts layer in preference to the default .gbr .
Hi Mitch, While this patch adds the inner copper layers and the board outline on the Protel/Altium Mechanical Layer 1, there are still a few layers 'unassigned' and still use the default '.grb' extensions. Among these are Dwgs_User, Cmts_User, Eco1_User, Eco2_User and any further unspecified layers. Would there be typical/appropriate Altium/Protel layers assignments for these layers that you use? Marco On 25-Jun-15 10:25, Mitch Davis wrote: Hi folks, On Thu, Jun 25, 2015 at 4:00 AM, Wayne Stambaugh stambau...@gmail.com wrote: Your patch was committed in the product branch r5818. Thank you for your contribution to KiCad. Big +1 for this patch. When a customer sends me a zip, I run a script which heuristically tries to work out which file corresponds to which function. This is going to make things a lot easier. Mitch. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] [PATCH] Cleanup: remove unnecessary macros
Hi,
macros.h provides two macros that appear to me completely unnecessary:
EXCHG and NEGATE.
The comment above EXCHG points out that it differs from std::swap in
that it accepts arguments of different types. I could not find a single
instance depending on that - it always swapped values of the same type.
It also remarks I hope to get rid of this soon or late. I removed it
and replaced its uses with std::swap.
The comment above NEGATE justifies it:
// This really needs a function? well, it is used *a lot* of times
Doesn't really mean it needs a macro though, otherwise we might as well
go defining macros like DOUBLE() and INCREMENT() and so on... It's just
as easy to type something like x = -x or x *= -1, and the latter is
_shorter_ than NEGATE( x ). I removed this too.
Up to you whether or not you want to accept the patch, but I think it's
a step in the direction of cleaner code. Macros for simple things that
don't need them confuse people - you have to go check the definition to
see if it does something special. They also result in some clumsy use
cases like this, from trying to shove them in:
m_pos.x -= aYaxis_position;
NEGATE( m_pos.x );
m_pos.x += aYaxis_position;
Writing out the NEGATE makes it clear that the lines are all very
similar and can easily be simplified:
m_pos.x = 2 * aYaxis_position - m_pos.x;
That's a lot clearer... I don't know about you, but I can visualize what
that's doing graphically a lot better too.
--
Chris
commit f96cd3a51e8c63f3f96a96d3a1e30e88723b9085
Author: Chris Pavlina cpavl...@binghamton.edu
Date: Fri Jun 26 01:28:30 2015 -0400
Remove unnecessary macros EXCHG and NEGATE
diff --git a/3d-viewer/3d_draw_helper_functions.cpp b/3d-viewer/3d_draw_helper_functions.cpp
index 577be18..25e3e6e 100644
--- a/3d-viewer/3d_draw_helper_functions.cpp
+++ b/3d-viewer/3d_draw_helper_functions.cpp
@@ -219,7 +219,7 @@ void EDA_3D_CANVAS::draw3DGrid( double aGriSizeMM )
wxSize brd_size = getBoardSize();
wxPoint brd_center_pos = getBoardCenter();
-NEGATE( brd_center_pos.y );
+brd_center_pos.y *= -1;
int xsize = std::max( brd_size.x, Millimeter2iu( 100 ) ) * 1.2;
int ysize = std::max( brd_size.y, Millimeter2iu( 100 ) ) * 1.2;
diff --git a/common/class_plotter.cpp b/common/class_plotter.cpp
index 427a094..3150d2c 100644
--- a/common/class_plotter.cpp
+++ b/common/class_plotter.cpp
@@ -150,7 +150,7 @@ void PLOTTER::Arc( const wxPoint centre, double StAngle, double EndAngle, int r
const int delta = 50; // increment (in 0.1 degrees) to draw circles
if( StAngle EndAngle )
-EXCHG( StAngle, EndAngle );
+std::swap( StAngle, EndAngle );
SetCurrentLineWidth( width );
/* Please NOTE the different sign due to Y-axis flip */
@@ -406,7 +406,7 @@ void PLOTTER::sketchOval( const wxPoint pos, const wxSize aSize, double orient
if( size.x size.y )
{
-EXCHG( size.x, size.y );
+std::swap( size.x, size.y );
orient = AddAngles( orient, 900 );
}
diff --git a/common/common.cpp b/common/common.cpp
index 6018e71..34aebf7 100644
--- a/common/common.cpp
+++ b/common/common.cpp
@@ -280,7 +280,7 @@ double RoundTo0( double x, double precision )
long long ix = KiROUND( x * precision );
if ( x 0.0 )
-NEGATE( ix );
+ix *= -1;
int remainder = ix % 10; // remainder is in precision mm
@@ -290,7 +290,7 @@ double RoundTo0( double x, double precision )
ix += 10 - remainder; // round to near number
if ( x 0 )
-NEGATE( ix );
+ix *= -1;
return (double) ix / precision;
}
diff --git a/common/common_plotDXF_functions.cpp b/common/common_plotDXF_functions.cpp
index 545b5ca..da5ef03 100644
--- a/common/common_plotDXF_functions.cpp
+++ b/common/common_plotDXF_functions.cpp
@@ -508,7 +508,7 @@ void DXF_PLOTTER::Arc( const wxPoint centre, double StAngle, double EndAngle, i
// If StAngle EndAngle, it is CW. So transform it to CCW
if( StAngle EndAngle )
{
-EXCHG( StAngle, EndAngle );
+std::swap( StAngle, EndAngle );
}
DPOINT centre_dev = userToDeviceCoordinates( centre );
@@ -536,7 +536,7 @@ void DXF_PLOTTER::FlashPadOval( const wxPoint pos, const wxSize aSize, double
* (Oval vertical orientation 0) */
if( size.x size.y )
{
-EXCHG( size.x, size.y );
+std::swap( size.x, size.y );
orient = AddAngles( orient, 900 );
}
diff --git a/common/common_plotGERBER_functions.cpp b/common/common_plotGERBER_functions.cpp
index a2a912f..2e041e6 100644
--- a/common/common_plotGERBER_functions.cpp
+++ b/common/common_plotGERBER_functions.cpp
@@ -459,7 +459,7 @@ void GERBER_PLOTTER::FlashPadOval( const wxPoint pos, const wxSize aSize, doub
trace_mode == FILLED )
{
if( orient == 900 || orient == 2700 ) /* orientation turned 90 deg. */
-EXCHG( size.x, size.y );
+std::swap( size.x,
Re: [Kicad-developers] Debug tracing on Windows
Most of the wxLog functions are compiled out in release builds. You must create a debug build. To see the logged output, you must run you application in either gdb or use a debug viewer such as DebugView (https://technet.microsoft.com/en-us/library/bb896647.aspx). If you use DebugView, you have to run it as admin. If you want to view wxLogTrace messages, you must first set the WXTRACE environment variable to enable the trace messages. Everything you want to know about wxLogging can be found here http://docs.wxwidgets.org/3.0/overview_log.html On 6/25/2015 3:23 AM, Nick Østergaard wrote: I am not exactly sure about this, but I think the wxLog works when you build KiCad in debug mode. That is the cmake build type switch. Are doing that? Den 25/06/2015 09.13 skrev Marco Hess marco.h...@through-ip.com mailto:marco.h...@through-ip.com: I am still new to KiCad and wxWidgerts development and as yet have not managed to get any trace output from KiCad for debug purposes. I see some wxLog type messages being used througout the code, but can't find where these are enabled? How do I enable those in my Windows build? I would love to have a simple trace window output when running KiCad. Is that possible? Any further pointers on how to best debug KiCad in a Windows Code::Blocks environment? Marco ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net mailto:kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] Use specific gerber extensions for inner Cu layers and the Edge_Cuts layer in preference to the default .gbr .
Hi Marco, On Thu, Jun 25, 2015 at 5:26 PM, Marco Hess marco.h...@through-ip.com wrote: While this patch adds the inner copper layers and the board outline on the Protel/Altium Mechanical Layer 1, there are still a few layers 'unassigned' and still use the default '.grb' extensions. Among these are Dwgs_User, Cmts_User, Eco1_User, Eco2_User and any further unspecified layers. Would there be typical/appropriate Altium/Protel layers assignments for these layers that you use? I don't know. My role is PCB supplier. People send me their zipped gerbers, and I arrange to have them made. As useful as those other layers are, they don't generally affect PCB production, so I ignore them, and can afford to ignore them. A better solution to file extensions is to have the purpose of a file embedded in the file, and that's what the Gerber X2 extension do. However most of the factories I use don't yet support Gerber X2. Mitch. ___ 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] Allow HTML files in KiCad project manager to be opened in browser
Le 24/06/2015 21:34, Wayne Stambaugh a écrit : Marco, I committed your patch in the product branch r5819. Thanks. Would one of our expert bitmap designers please come up with a better html file bitmap instead of the light bulb provided in this patch? Thanks, Wayne I committed a new html file icon, but we still need one of our expert bitmap designers. -- 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 buffer overflows in eeschema
Chris, Thanks for the patch. I just want to let you know that, this is one of those likely to be short lived patches. After the stable release, one of my first orders of business will be to write proper I/O management code similar to what we have for Pcbnew. It will use code in richio.h/.cpp for parsing and formatting which takes care of the memory allocation issues. Wayne On 6/25/2015 12:37 AM, Chris Pavlina wrote: Eeschema is _full_ of sscanf buffer overflow vulnerabilities, in almost every ::Load. This patch adds the proper field width specifiers to prevent the buffers from being smashed by an invalid or malicious input. -- Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] Use specific gerber extensions for inner Cu layers and the Edge_Cuts layer in preference to the default .gbr .
On Thu, Jun 25, 2015 at 10:03:31PM +1000, Mitch Davis wrote: I think the name Protel is there to indicate the historical origin, rather than be the name of a current package. (Do factories still use Exactly. In the past the dialog said 'proper' but I assumed it was a typo since they were the extension protel used; remember those days where 8+3 filename times, so you had to be creative :P AFAIK Altium has a configurable CAM processor so it wouldn't be correct to call them 'altium extension' (unless it still use these by default:D) Gerber plotters? Do factories still use Excellon drill machines?) It was something like Gerber-Barco-Ucamco (at least that's what wikipedia says...), so you could say that gerber plotter are *still* in use. Well, a little different since they are raster machine these days... No idea if there are many other photoplotter manufacturer arounds; however it seems that everyone eventually standardized on RS274X (i.e. gerber). At least, it seems that *everyone* uses the same preprocessor, at least here in italy (genesis) As for the drill tapes, excellon is still in business so I'd say that even for these, yes, they still use them :D there are other format in use however (SiebMayer, for example). Pick and place and AOI however are a whole hell of custom file formats, don't worry :D -- Lorenzo Marcantonio Logos Srl ___ 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] Use specific gerber extensions for inner Cu layers and the Edge_Cuts layer in preference to the default .gbr .
Hi Marco, On Thu, Jun 25, 2015 at 5:31 PM, Marco Hess marco.h...@through-ip.com wrote: On this item, I noted that in dialog_plot_base.cpp the checkbox for using these extensions are referred to as 'Protel'. Should we change that to 'Altium' to stay with the times? I think the name Protel is there to indicate the historical origin, rather than be the name of a current package. (Do factories still use Gerber plotters? Do factories still use Excellon drill machines?) Mitch. ___ 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] Feature request about hierarchical net names
I know, feature freeze! But I just want to put this out there before I forget. It was mentioned on the Kicad.info forum, and I just happened to add a hierarchical thing to a current design, so it stood out. Consider a common use of hierarchical schematics. You have some lower-level thing which you need to replicate. You create a hierarchical sheet, draw the thing, and you give it say four ports, two inputs called In1 and In2, and two outputs called Out1 and Out2. In the higher-up sheet, you have two instances of Thing. This instantiating sheet has four nets, Foo[4:1] and Bar[4:1]. You wire Foo1 and Foo2 to Thing 1’s inputs In1 and In2, and you wire Foo3 and Foo4 to Thing 2’s inputs In1 and In2. You do the same with Bar and the outputs. Create the netlist for pcbnew. You’ll notice that nets that connect the top sheet to Thing1 and Thing2 get names like /Topsheet/Thing1/In1, /Topsheet/Thing2/In1 and /Topsheet/Thing2/Out2 and so forth. When you look at the footprint pads for those nets (and when you draw the traces), you see only the In1 and In2 netnames. So at a casual glance, you might think that the two nets In1 are the same and that the signals to the lower level things are tied together. That’s not the case; the netlist is correct and your design is fine. So the request: can’t the names of the nets passed down through hierarchical ports be that of the top-level (instantiating) entity, and not that of the low level instance? -a ___ 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] Use specific gerber extensions for inner Cu layers and the Edge_Cuts layer in preference to the default .gbr .
One of the reasons I did this patch was in an attempt to deal with some of the PCB manufacturers I am using. If I send them the default named KiCad files they did not understand the Gerbers at all. They basically complained that the ZIP I send them only contained a drill file. I found that many of them use a package called CAM350, I had a bit of a play with a trial version of that package and found that on importing a design it mainly looks at the file extensions used on the gerbers to assign the right gerber to the right layer. It uses a number of 'profiles' that matched extensions used with the typical more popular packages and even has some auto-scan feature to look for the best match. Unfortunately the default KiCad naming was not one of the profiles they had. If the extensions could not be matched to anything, CAM350 was unable to assign the gerber to the right layer and assigned the gerber to a default 'Graphical' layer and the manufacturing check bailed out with an error. When I renamed the gerbers with either the Protel extensions or with the default extensions used for Orcad, I had more success with these PCB manufacturers accepting my ZIP package :-). Not sure what others experiences are in this area. I am not on KiCad that long, I previously mainly used Protel 99 and some Altium and for that I could just send the PCB file without having to worry about individual Gerbers (although I found it annoying that often I had holes in my board as they interpreted the KeepOut layers as board outline in addition to the normal board outline. I personally hate dialog boxes with too many options. I like when things can be locked down and scripted where possible so that I can generate gerbers the same way each and every time I produce a board. A such I feel that KiCad could do with an extension in the manufacturing output where you can select a a predefined 'Profile' that sets the DRC rules for a particular manufacturer (or personal defaults) but also configure the gerber file naming rules. Over time there could be a collection of such manufacturer profiles files that can be included to help newer users to generate the right manufacturing pack straight of the bat. I might have a look into that at some time when things settled down a bit and I got my other changes submitted :-) Marco On 25/06/2015 9:54 PM, Lorenzo Marcantonio wrote: On Thu, Jun 25, 2015 at 10:03:31PM +1000, Mitch Davis wrote: I think the name Protel is there to indicate the historical origin, rather than be the name of a current package. (Do factories still use Exactly. In the past the dialog said 'proper' but I assumed it was a typo since they were the extension protel used; remember those days where 8+3 filename times, so you had to be creative :P AFAIK Altium has a configurable CAM processor so it wouldn't be correct to call them 'altium extension' (unless it still use these by default:D) Gerber plotters? Do factories still use Excellon dill machines?) It was something like Gerber-Barco-Ucamco (at least that's what wikipedia says...), so you could say that gerber plotter are *still* in use. Well, a little different since they are raster machine these days... No idea if there are many other photoplotter manufacturer arounds; however it seems that everyone eventually standardized on RS274X (i.e. gerber). At least, it seems that *everyone* uses the same preprocessor, at least here in italy (genesis) As for the drill tapes, excellon is still in business so I'd say that even for these, yes, they still use them :D there are other format in use however (SiebMayer, for example). Pick and place and AOI however are a whole hell of custom file formats, don't worry :D ___ 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 buffer overflows in eeschema
On Jun 25, 2015, at 5:16 AM, Wayne Stambaugh stambau...@gmail.com wrote: Chris, Thanks for the patch. I just want to let you know that, this is one of those likely to be short lived patches. After the stable release, one of my first orders of business will be to write proper I/O management code similar to what we have for Pcbnew. It will use code in richio.h/.cpp for parsing and formatting which takes care of the memory allocation issues. Wayne Wayne, While you may consider it to be a short-term patch because the plan is to fix the root cause of the issues, we all know that a stable release will be the one that most of the regular users stick with for a long time, at least to the next stable release. So the fix is a Good Thing and will hopefully eliminate some bug reports and user complaints. -a On 6/25/2015 12:37 AM, Chris Pavlina wrote: Eeschema is _full_ of sscanf buffer overflow vulnerabilities, in almost every ::Load. This patch adds the proper field width specifiers to prevent the buffers from being smashed by an invalid or malicious input. -- Chris ___ 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 buffer overflows in eeschema
On 6/25/2015 1:43 PM, Andy Peters wrote: On Jun 25, 2015, at 5:16 AM, Wayne Stambaugh stambau...@gmail.com wrote: Chris, Thanks for the patch. I just want to let you know that, this is one of those likely to be short lived patches. After the stable release, one of my first orders of business will be to write proper I/O management code similar to what we have for Pcbnew. It will use code in richio.h/.cpp for parsing and formatting which takes care of the memory allocation issues. Wayne Wayne, While you may consider it to be a short-term patch because the plan is to fix the root cause of the issues, we all know that a stable release will be the one that most of the regular users stick with for a long time, at least to the next stable release. So the fix is a Good Thing and will hopefully eliminate some bug reports and user complaints. I agree but I also wanted to let Chris know that future plans for Eeschema will make the code he wrote obsolete. I want keep developers informed so they are not blindsided when some code they wrote goes away in the future. It's a simple courtesy. -a On 6/25/2015 12:37 AM, Chris Pavlina wrote: Eeschema is _full_ of sscanf buffer overflow vulnerabilities, in almost every ::Load. This patch adds the proper field width specifiers to prevent the buffers from being smashed by an invalid or malicious input. -- Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] Fix cancel option when exiting without saving
I committed your patch it the product branch r5822. Thank you for you contribution to KiCad. On 6/24/2015 3:13 PM, Jon Neal wrote: In three different programs (pcbnew, cvpcb, and eeschema) if you close without saving and press cancel in the dialog that comes up you get an assert from wxWidgets. This is caused by the dialog being set to forced close which means that it can't be cancelled. The attached patch fixes this issue. Jon Neal ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] Skip redundant repetition of component name in component chooser
Are you positive that a better fix wouldn't be to stop putting redundant things in component descriptions? This seems like a poor way to KISS... On Thu, Jun 25, 2015 at 06:24:33PM -0700, Henner Zeller wrote: Hi, In component descriptions, often the first word in the description is a repetition of the component name. While this is generally not a problem when reading this in a description box, if displayed in the brief description in the tree view, this is redundant information, taking space of more relevant information (see first attachment picture). This patch uses some heuristic to get rid of these and thus generally improves the experience for these components: https://github.com/hzeller/kicad/compare/skip-redundant-name-repetition-in-tree.diff See second picture for an example. 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 -- Chris ___ 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] Skip redundant repetition of component name in component chooser
On 25 June 2015 at 19:18, Chris Pavlina pavlina.ch...@gmail.com wrote: Any chance of making it configurable? Or at least, of not being offended if I throw in a patch to do that? ;) What do you want to make configurable ? Do you _want_ to see the redundant information ? On Thu, Jun 25, 2015 at 07:15:36PM -0700, Henner Zeller wrote: On 25 June 2015 at 19:09, Chris Pavlina pavlina.ch...@gmail.com wrote: Are you positive that a better fix wouldn't be to stop putting redundant things in component descriptions? It would be good if that wouldn't happen, yes. But I can't change all the libraries that exist in the world; changing only the KiCAD internal libraries would probably be feasible (need to hack up something) and should probably be done independently. This change helps to have KiCAD behave best in the real world. -h On Thu, Jun 25, 2015 at 06:24:33PM -0700, Henner Zeller wrote: Hi, In component descriptions, often the first word in the description is a repetition of the component name. While this is generally not a problem when reading this in a description box, if displayed in the brief description in the tree view, this is redundant information, taking space of more relevant information (see first attachment picture). This patch uses some heuristic to get rid of these and thus generally improves the experience for these components: https://github.com/hzeller/kicad/compare/skip-redundant-name-repetition-in-tree.diff See second picture for an example. 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 -- Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] Skip redundant repetition of component name in component chooser
I am assuming that it is only removed from the description when it matches the component name? i.e. If I use a different naming convention where the component name is not necessarily repeated in the description, this patch is a NOOP? On 26-Jun-15 11:58, Henner Zeller wrote: On 25 June 2015 at 19:18, Chris Pavlina pavlina.ch...@gmail.com wrote: Any chance of making it configurable? Or at least, of not being offended if I throw in a patch to do that? ;) What do you want to make configurable ? Do you _want_ to see the redundant information ? On Thu, Jun 25, 2015 at 07:15:36PM -0700, Henner Zeller wrote: On 25 June 2015 at 19:09, Chris Pavlina pavlina.ch...@gmail.com wrote: Are you positive that a better fix wouldn't be to stop putting redundant things in component descriptions? It would be good if that wouldn't happen, yes. But I can't change all the libraries that exist in the world; changing only the KiCAD internal libraries would probably be feasible (need to hack up something) and should probably be done independently. This change helps to have KiCAD behave best in the real world. -h On Thu, Jun 25, 2015 at 06:24:33PM -0700, Henner Zeller wrote: Hi, In component descriptions, often the first word in the description is a repetition of the component name. While this is generally not a problem when reading this in a description box, if displayed in the brief description in the tree view, this is redundant information, taking space of more relevant information (see first attachment picture). This patch uses some heuristic to get rid of these and thus generally improves the experience for these components: https://github.com/hzeller/kicad/compare/skip-redundant-name-repetition-in-tree.diff See second picture for an example. 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 -- Chris ___ 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 -- Marco Hess Through IP Pty. Ltd. - AUSTRALIA www.through-ip.com | marco.h...@through-ip.com p: +61 407 78 55 66 | f: +61 8 8121 6191 ___ 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] Skip redundant repetition of component name in component chooser
On 25 June 2015 at 19:34, Marco Hess marco.h...@through-ip.com wrote: I am assuming that it is only removed from the description when it matches the component name? Yes, only then. i.e. If I use a different naming convention where the component name is not necessarily repeated in the description, this patch is a NOOP? Exactly. if the description doesn't start with the component name, it displays the whole description. On 26-Jun-15 11:58, Henner Zeller wrote: On 25 June 2015 at 19:18, Chris Pavlina pavlina.ch...@gmail.com wrote: Any chance of making it configurable? Or at least, of not being offended if I throw in a patch to do that? ;) What do you want to make configurable ? Do you _want_ to see the redundant information ? On Thu, Jun 25, 2015 at 07:15:36PM -0700, Henner Zeller wrote: On 25 June 2015 at 19:09, Chris Pavlina pavlina.ch...@gmail.com wrote: Are you positive that a better fix wouldn't be to stop putting redundant things in component descriptions? It would be good if that wouldn't happen, yes. But I can't change all the libraries that exist in the world; changing only the KiCAD internal libraries would probably be feasible (need to hack up something) and should probably be done independently. This change helps to have KiCAD behave best in the real world. -h On Thu, Jun 25, 2015 at 06:24:33PM -0700, Henner Zeller wrote: Hi, In component descriptions, often the first word in the description is a repetition of the component name. While this is generally not a problem when reading this in a description box, if displayed in the brief description in the tree view, this is redundant information, taking space of more relevant information (see first attachment picture). This patch uses some heuristic to get rid of these and thus generally improves the experience for these components: https://github.com/hzeller/kicad/compare/skip-redundant-name-repetition-in-tree.diff See second picture for an example. 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 -- Chris ___ 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 -- Marco Hess Through IP Pty. Ltd. - AUSTRALIA www.through-ip.com | marco.h...@through-ip.com p: +61 407 78 55 66 | f: +61 8 8121 6191 ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] Skip redundant repetition of component name in component chooser
On 25 June 2015 at 19:09, Chris Pavlina pavlina.ch...@gmail.com wrote: Are you positive that a better fix wouldn't be to stop putting redundant things in component descriptions? It would be good if that wouldn't happen, yes. But I can't change all the libraries that exist in the world; changing only the KiCAD internal libraries would probably be feasible (need to hack up something) and should probably be done independently. This change helps to have KiCAD behave best in the real world. -h On Thu, Jun 25, 2015 at 06:24:33PM -0700, Henner Zeller wrote: Hi, In component descriptions, often the first word in the description is a repetition of the component name. While this is generally not a problem when reading this in a description box, if displayed in the brief description in the tree view, this is redundant information, taking space of more relevant information (see first attachment picture). This patch uses some heuristic to get rid of these and thus generally improves the experience for these components: https://github.com/hzeller/kicad/compare/skip-redundant-name-repetition-in-tree.diff See second picture for an example. 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 -- Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] Skip redundant repetition of component name in component chooser
I want the description column to show exactly what's in the component description field, as it does now. I'm not opposed to different behavior, I'd just ideally like an optional way to keep it the way it is. I maintain my own libraries, and if there's something wrong with them like that, I'd rather see it so I can fix it! I don't think I'm the only one who'd like to see major interface elements like that stay relatively simple and predictable. It's POLA - it claims to be a description column, so you expect it to directly show the description. https://en.wikipedia.org/wiki/Principle_of_least_astonishment On Thu, Jun 25, 2015 at 07:28:31PM -0700, Henner Zeller wrote: On 25 June 2015 at 19:18, Chris Pavlina pavlina.ch...@gmail.com wrote: Any chance of making it configurable? Or at least, of not being offended if I throw in a patch to do that? ;) What do you want to make configurable ? Do you _want_ to see the redundant information ? On Thu, Jun 25, 2015 at 07:15:36PM -0700, Henner Zeller wrote: On 25 June 2015 at 19:09, Chris Pavlina pavlina.ch...@gmail.com wrote: Are you positive that a better fix wouldn't be to stop putting redundant things in component descriptions? It would be good if that wouldn't happen, yes. But I can't change all the libraries that exist in the world; changing only the KiCAD internal libraries would probably be feasible (need to hack up something) and should probably be done independently. This change helps to have KiCAD behave best in the real world. -h On Thu, Jun 25, 2015 at 06:24:33PM -0700, Henner Zeller wrote: Hi, In component descriptions, often the first word in the description is a repetition of the component name. While this is generally not a problem when reading this in a description box, if displayed in the brief description in the tree view, this is redundant information, taking space of more relevant information (see first attachment picture). This patch uses some heuristic to get rid of these and thus generally improves the experience for these components: https://github.com/hzeller/kicad/compare/skip-redundant-name-repetition-in-tree.diff See second picture for an example. 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 -- Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] Skip redundant repetition of component name in component chooser
On 25 June 2015 at 19:32, Chris Pavlina pavlina.ch...@gmail.com wrote: I want the description column to show exactly what's in the component description field, as it does now. Note, the description is not affected in the little description box in the bottom right. Only in the list view, where space is precious. I'm not opposed to different behavior, I'd just ideally like an optional way to keep it the way it is. I maintain my own libraries, and if there's something wrong with them like that, I'd rather see it so I can fix it! Fair enough. Maybe this should be different if this dialog is used in the library editor (where this information could be useful) vs. eeschema (where redundant information is annoying). I don't think I'm the only one who'd like to see major interface elements like that stay relatively simple and predictable. It's POLA - it claims to be a description column, so you expect it to directly show the description. Well, it doesn't really claim to be a description column anywhere. https://en.wikipedia.org/wiki/Principle_of_least_astonishment I don't think invoking Pola applies here. It only removes something that has been written a couple of pixels before. So for a human user this is not astonishing at all. It is rather annoying if it _not_ happens. -h On Thu, Jun 25, 2015 at 07:28:31PM -0700, Henner Zeller wrote: On 25 June 2015 at 19:18, Chris Pavlina pavlina.ch...@gmail.com wrote: Any chance of making it configurable? Or at least, of not being offended if I throw in a patch to do that? ;) What do you want to make configurable ? Do you _want_ to see the redundant information ? On Thu, Jun 25, 2015 at 07:15:36PM -0700, Henner Zeller wrote: On 25 June 2015 at 19:09, Chris Pavlina pavlina.ch...@gmail.com wrote: Are you positive that a better fix wouldn't be to stop putting redundant things in component descriptions? It would be good if that wouldn't happen, yes. But I can't change all the libraries that exist in the world; changing only the KiCAD internal libraries would probably be feasible (need to hack up something) and should probably be done independently. This change helps to have KiCAD behave best in the real world. -h On Thu, Jun 25, 2015 at 06:24:33PM -0700, Henner Zeller wrote: Hi, In component descriptions, often the first word in the description is a repetition of the component name. While this is generally not a problem when reading this in a description box, if displayed in the brief description in the tree view, this is redundant information, taking space of more relevant information (see first attachment picture). This patch uses some heuristic to get rid of these and thus generally improves the experience for these components: https://github.com/hzeller/kicad/compare/skip-redundant-name-repetition-in-tree.diff See second picture for an example. 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 -- Chris ___ 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 ___ 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] Quick rescue fixes
Here are a couple quick fixes to project_rescue.
- Components with multiple converts were rendered with all of them
overlapping instead of just one.
- Schematics missing a -cache.lib resulted in unnecessary renaming
suggestions.
- The dialog title Conflicts Checking is inaccurate now (as we're
checking for more than just conflicts) and also somewhat awkward,
unidiomatic GUI English; I renamed it to Project Rescue Helper.
--
Chris
commit b4359ade0ab17ca967338cc30b7994208481ddc9
Author: Chris Pavlina cpavl...@binghamton.edu
Date: Thu Jun 25 20:26:10 2015 -0400
Rescue fixes
diff --git a/eeschema/dialogs/dialog_rescue_each.cpp b/eeschema/dialogs/dialog_rescue_each.cpp
index 31c424a..69fc5ec 100644
--- a/eeschema/dialogs/dialog_rescue_each.cpp
+++ b/eeschema/dialogs/dialog_rescue_each.cpp
@@ -219,7 +219,7 @@ void DIALOG_RESCUE_EACH::renderPreview( LIB_PART* aComponent, int aUnit, wxPanel
dc.SetDeviceOrigin( dc_size.x / 2, dc_size.y / 2 );
// Find joint bounding box for everything we are about to draw.
-EDA_RECT bBox = aComponent-GetBoundingBox( aUnit, /* deMorganConvert */ 0 );
+EDA_RECT bBox = aComponent-GetBoundingBox( aUnit, /* deMorganConvert */ 1 );
const double xscale = (double) dc_size.x / bBox.GetWidth();
const double yscale = (double) dc_size.y / bBox.GetHeight();
const double scale = std::min( xscale, yscale ) * 0.85;
@@ -235,7 +235,7 @@ void DIALOG_RESCUE_EACH::renderPreview( LIB_PART* aComponent, int aUnit, wxPanel
if( !width || !height )
return;
-aComponent-Draw( NULL, dc, offset, aUnit, /* deMorganConvert */ 0, GR_COPY,
+aComponent-Draw( NULL, dc, offset, aUnit, /* deMorganConvert */ 1, GR_COPY,
UNSPECIFIED_COLOR, DefaultTransform, true, true, false );
}
diff --git a/eeschema/dialogs/dialog_rescue_each_base.fbp b/eeschema/dialogs/dialog_rescue_each_base.fbp
index fcc7882..5199216 100644
--- a/eeschema/dialogs/dialog_rescue_each_base.fbp
+++ b/eeschema/dialogs/dialog_rescue_each_base.fbp
@@ -47,7 +47,7 @@
property name=size529,593/property
property name=stylewxDEFAULT_DIALOG_STYLE|wxRESIZE_BORDER/property
property name=subclassDIALOG_SHIM; dialog_shim.h/property
-property name=titleConflicts Checking/property
+property name=titleProject Rescue Helper/property
property name=tooltip/property
property name=window_extra_style/property
property name=window_name/property
diff --git a/eeschema/dialogs/dialog_rescue_each_base.h b/eeschema/dialogs/dialog_rescue_each_base.h
index e6490c3..40d1b11 100644
--- a/eeschema/dialogs/dialog_rescue_each_base.h
+++ b/eeschema/dialogs/dialog_rescue_each_base.h
@@ -62,7 +62,7 @@ class DIALOG_RESCUE_EACH_BASE : public DIALOG_SHIM
public:
- DIALOG_RESCUE_EACH_BASE( wxWindow* parent, wxWindowID id = wxID_ANY, const wxString title = _(Conflicts Checking), const wxPoint pos = wxDefaultPosition, const wxSize size = wxSize( 529,593 ), long style = wxDEFAULT_DIALOG_STYLE|wxRESIZE_BORDER );
+ DIALOG_RESCUE_EACH_BASE( wxWindow* parent, wxWindowID id = wxID_ANY, const wxString title = _(Project Rescue Helper), const wxPoint pos = wxDefaultPosition, const wxSize size = wxSize( 529,593 ), long style = wxDEFAULT_DIALOG_STYLE|wxRESIZE_BORDER );
~DIALOG_RESCUE_EACH_BASE();
};
diff --git a/eeschema/project_rescue.cpp b/eeschema/project_rescue.cpp
index 9104372..5645787 100644
--- a/eeschema/project_rescue.cpp
+++ b/eeschema/project_rescue.cpp
@@ -243,7 +243,7 @@ public:
{
wxString part_name( each_component-GetPartName() );
-LIB_PART* case_sensitive_match = find_component( part_name, aRescuer.GetLibs(), /* aCached */ true );
+LIB_ALIAS* case_sensitive_match = aRescuer.GetLibs()-FindLibraryEntry( part_name );
std::vectorLIB_ALIAS* case_insensitive_matches;
aRescuer.GetLibs()-FindLibraryNearEntries( case_insensitive_matches, part_name );
___
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] Skip redundant repetition of component name in component chooser
Hi, In component descriptions, often the first word in the description is a repetition of the component name. While this is generally not a problem when reading this in a description box, if displayed in the brief description in the tree view, this is redundant information, taking space of more relevant information (see first attachment picture). This patch uses some heuristic to get rid of these and thus generally improves the experience for these components: https://github.com/hzeller/kicad/compare/skip-redundant-name-repetition-in-tree.diff See second picture for an example. 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
[Kicad-developers] Debug tracing on Windows
I am still new to KiCad and wxWidgerts development and as yet have not managed to get any trace output from KiCad for debug purposes. I see some wxLog type messages being used througout the code, but can't find where these are enabled? How do I enable those in my Windows build? I would love to have a simple trace window output when running KiCad. Is that possible? Any further pointers on how to best debug KiCad in a Windows Code::Blocks environment? Marco ___ 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] Debug tracing on Windows
I am not exactly sure about this, but I think the wxLog works when you build KiCad in debug mode. That is the cmake build type switch. Are doing that? Den 25/06/2015 09.13 skrev Marco Hess marco.h...@through-ip.com: I am still new to KiCad and wxWidgerts development and as yet have not managed to get any trace output from KiCad for debug purposes. I see some wxLog type messages being used througout the code, but can't find where these are enabled? How do I enable those in my Windows build? I would love to have a simple trace window output when running KiCad. Is that possible? Any further pointers on how to best debug KiCad in a Windows Code::Blocks environment? Marco ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] Fix buffer overflows in eeschema
Le 25/06/2015 06:37, Chris Pavlina a écrit : Eeschema is _full_ of sscanf buffer overflow vulnerabilities, in almost every ::Load. This patch adds the proper field width specifiers to prevent the buffers from being smashed by an invalid or malicious input. -- Chris Committed, with the patch to fix the bug 1468604. 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
