Re: [Kicad-developers] Benchmarking kicad compilation on CPUs released 6 years apart

[Henner Zeller]

On Mon, 28 Oct 2019 at 22:21, Andrew Lutsenko  wrote:

> Hi all,
>
> This information may be useful to people that are considering an upgrade
> for their workstations or for general information, feel free to skip this
> email if you are not interested.
>
> I've been using my 6 year old Haswell i7 machine that served me well over
> the years but kicad compilation times both under msys and in linux vm were
> frustratingly long. That reason along with a few others pushed me to
> upgrade.
> If you've been following the hardware news lately AMD's Ryzen is all the
> rage lately and for a very good reason. I've been rooting for them since
> Athlon days but had to begrudgingly buy Intel a few times after that
> because AMD products just weren't competitive.
> This definitely has changed with Ryzen series.
>
> To not make this too long and so that you don't think of me as AMD shill
> let the numbers speak for themselves and you decide whether it's worth it
> to upgrade for you.
>
> My previous config: i7 4770 Haswell 4 core CPU, 16gb of DDR3 ram in dual
> channel, sata ssd.
> My new config: R9 3900x Matisse 12 core CPU, 32gb of DDR4 ram in dual
> channel, nvme ssd.
>
> I set my master branch to same commit in both cases (846397c69) and did
> "make clean". Then I compiled all targets to measure time of clean build.
> Then switched to master~15 and compiled, then switched to master~5 and
> compiled, and lastly back to master and compiled again. Thus I measured
> more typical scenario of incremental compilation as well.
> In case of my old system I did "make -j8" as that is the number of threads
> that CPU has, in case of new one I did "make -j24" for same reason,
> maximizing used threads.
>

For compilation uses, I recently upgraded to a 16 core 1950x and am also
pretty impressed.
I find that using a bit more parallelism than can even give a little more
as not all compile threads might be using the CPU 100% but might be waiting
on IO. On my 1950X, I use -j50 (on 32 hyper-threaded cores). Something like
this might in particular work for your network storage connection.

Also highly recommended (when in development with intermediate 'make
clean') install ccache

Also something of note is that for both configs linux vm was run from a
> virtual disk located on a network storage device with 1Gbps link, not on
> local ssd. And I didn't master~15 build for linux, just master~5 and master
> again.
>
> clean master~15 master~5 master
> i7 4770 msys 36m28.515s 26m51.178s 27m45.738s 14m21.653s
> R9 3900x msys 6m40.112s 4m56.747s 4m55.271s 3m15.945s
> i7 4770 linux 44m49.681s - 15m53.635s 15m53.098s
> R9 3900x linux 6m35.732s - 3m26.773s 3m18.514s
>
> I kinda expected 2x maybe 3x decrease because not all computations scale
> linearly with number of threads. I was pleasantly surprised by almost 6x
> decrease in clean build time and 5x in incremental builds.
>
> Here are the numbers in google sheet in case table above is not readable
>
> https://docs.google.com/spreadsheets/d/1UI1aW-FTTI-TncTWhAdG_Ag__5nc2FF1626WaPiL3LE/edit?usp=sharing
>
> Regards,
> Andrew
> ___
> 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: Raytracing - a more pleasing way sequencing blocks to render ?

[Henner Zeller]

On Thu, 9 May 2019 at 13:06, Wayne Stambaugh  wrote:
>
> Hi Henner,
>
> On 5/1/19 9:44 AM, Henner Zeller wrote:
> > On Wed, 1 May 2019 at 06:14, John Beard  wrote:
> >>
> >> On 01/05/2019 13:57, Mário Luzeiro wrote:
> >>> Hi John,
> >>>
> >>> yeah the Morton code is to improve cache hits.
> >>>
> >>> Regarding the speed test, since OS are multi-tasking there could be some 
> >>> interference on the results so 1s difference is not a very measurable 
> >>> difference ( 4% ).
> >>> A possibility would be to run the same scene multiple times and make an 
> >>> average of the times.
> >>
> >> Sure, it was just a fun observation. It does change a bit from run to
> >> run, but I was at least expecting a small penalty. Next up, wipes[1] and
> >> then perhaps Snake :-D
> >>
> >> A more robust benchmarking harness would probably be the way to go if we
> >> really were serious about putting the pedal to the metal here.
> >>
> >> But I think the centre-first approach is certainly better usability, but
> >> I'm unsure about the checkerboard.
> >
> > I agree, without checkerboard it makes it quicker to see what is going
> > on in the center. Attached the (even simpler) just spiraling out from
> > the center patch.
>
> I tested this patch and it works as advertised.  Would you please fix a
> few minor coding policy issues (missing spaces after opening and before
> closing parentheses) and resubmit it?  There is now a clang-format
> (>=3.9) commit hook[1] that allows you to check your code formatting
> before you commit.

Sorry for the formatting mess-up, attached you find the patch properly
clang-tidied.
I really like the new clang tidy script, much more seamless than the
uncrustify stuff from the past.

Thanks,
  Henner.

>
> Thanks,
>
> Wayne
>
> [1]:
> http://docs.kicad-pcb.org/doxygen/md_Documentation_development_coding-style-policy.html#tools
>
> >
> >>
> >> Cheers,
> >>
> >> John
> >>
> >> [1]: https://www.youtube.com/watch?v=cGqAu9gj_F0
> >>
> >> ___
> >> 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
diff --git a/3d-viewer/3d_rendering/3d_render_raytracing/c3d_render_raytracing.cpp b/3d-viewer/3d_rendering/3d_render_raytracing/c3d_render_raytracing.cpp
index 27b2ae4bc..3880eaf8c 100644
--- a/3d-viewer/3d_rendering/3d_render_raytracing/c3d_render_raytracing.cpp
+++ b/3d-viewer/3d_rendering/3d_render_raytracing/c3d_render_raytracing.cpp
@@ -28,10 +28,11 @@
  */
 
 #include 
-#include 
+#include 
 #include 
-#include 
 #include 
+#include 
+#include 
 
 #include "c3d_render_raytracing.h"
 #include "mortoncodes.h"
@@ -2074,6 +2075,13 @@ bool C3D_RENDER_RAYTRACING::initializeOpenGL()
 }
 
 
+static float distance( const SFVEC2UI& a, const SFVEC2UI& b )
+{
+const float dx = (float) a.x - (float) b.x;
+const float dy = (float) a.y - (float) b.y;
+return hypotf( dx, dy );
+}
+
 void C3D_RENDER_RAYTRACING::initialize_block_positions()
 {
 
@@ -2123,26 +2131,24 @@ void C3D_RENDER_RAYTRACING::initialize_block_positions()
 m_postshader_ssao.UpdateSize( m_realBufferSize );
 
 
-// Calc block positions
+// Calc block positions for regular rendering. Choose an 'inside out'
+// style of rendering
 // /
 m_blockPositions.clear();
-m_blockPositions.reserve( (m_realBufferSize.x / RAYPACKET_DIM) *
-  (m_realBufferSize.y / RAYPACKET_DIM) );
-
-i = 0;
-
-while(1)
-{
-SFVEC2UI blockPos( DecodeMorton2X(i) * RAYPACKET_DIM,
-   DecodeMorton2Y(i) * RAYPACKET_DIM );
-i++;
-
-if( (blockPos.x >= m_realBufferSize.x) && (blockPos.y >= m_realBufferSize.y) )
-break;
-
-if( (blockPos.x < m_realBufferSize.x) && (blockPos.y < m_realBufferSize.y) )
-m_blockPositions.push_back( blockPos );
-}
+const int blocks_x = m_realBufferSize.x / RAYPACKET_DIM;
+const int blocks_y = m_realBufferSize.y / RAYPACKET_DIM;
+m_blockPositions.reserve(

Re: [Kicad-developers] PATCH: exact match of component with sub-units in schematic did not show

[Henner Zeller]

On Thu, 2 May 2019 at 09:31, Henner Zeller  wrote:
>
> On Thu, 2 May 2019 at 09:25, Seth Hillbrand  wrote:
> >
> > Am 2019-05-02 12:18, schrieb Henner Zeller:
> > > On Tue, 30 Apr 2019 at 20:24, Henner Zeller  wrote:
> > >>
> > >> Hi,
> > >> so here one digit patch.
> > >>
> > >> Problem Symptom: in the schematic symbol chooser, if you search for an
> > >> exact match of a component with multiple units, it is not selected.
> > >> For instance, search for
> > >>
> > >>74LS00
> > >>
> > >> The scored element is in the tree, but you need to manually unfold it
> > >> (see before.png image). This usually works otherwise (I suspect it has
> > >> to do with the fact that there are sub-units).
> > >>
> > >> The attached change will reliably select the first unit of that
> > >> particular symbol and fix the problem (after.png image).
> > >>
> > >> Now it might be up for debate if the search should actually unfold to
> > >> the first unit or if the tree unfolding should stop at the 74LS00 part
> > >> - I guess if the latter is wished, something dependent on
> > >> tree-children needs to be introduced. I leave that up to you.
> > >>
> > >> Attached: patch (against 5.1 branch),
> > >
> > > It also applies cleanly against current head, which has the same
> > > problem.
> >
> >
> > Hmmm... cache will be local to each core, so the we'll probably get
> > speed up by dividing the image into quadrants based on the number of
> > threads and having a morton sweep per quadrant.
>
> so on my 16 core, 32 'thread' Ryzen Threadripper, I only see about
> 1-2% slower execution, so it is probably not a big deal even with a
> lot of competing cores.
>
> Having said that, I have some ideas for some further optimizations,
> but that would go more into the guts of it (e.g. dividing memory areas
> by cores etc.) that I didn't want to start it now for a (hopefully)
> 5.1 acceptable patch.

(uhm, also we are talking in the wrong email-thread here ... This
should've gone to the
"PATCH: Raytracing - a more pleasing way sequencing blocks to render ?"-thread)

>
> -h
>
> >
> > But even without, the center spiral patch is a nice touch.
> >
> > -Seth

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] PATCH: exact match of component with sub-units in schematic did not show

[Henner Zeller]

On Thu, 2 May 2019 at 09:25, Seth Hillbrand  wrote:
>
> Am 2019-05-02 12:18, schrieb Henner Zeller:
> > On Tue, 30 Apr 2019 at 20:24, Henner Zeller  wrote:
> >>
> >> Hi,
> >> so here one digit patch.
> >>
> >> Problem Symptom: in the schematic symbol chooser, if you search for an
> >> exact match of a component with multiple units, it is not selected.
> >> For instance, search for
> >>
> >>74LS00
> >>
> >> The scored element is in the tree, but you need to manually unfold it
> >> (see before.png image). This usually works otherwise (I suspect it has
> >> to do with the fact that there are sub-units).
> >>
> >> The attached change will reliably select the first unit of that
> >> particular symbol and fix the problem (after.png image).
> >>
> >> Now it might be up for debate if the search should actually unfold to
> >> the first unit or if the tree unfolding should stop at the 74LS00 part
> >> - I guess if the latter is wished, something dependent on
> >> tree-children needs to be introduced. I leave that up to you.
> >>
> >> Attached: patch (against 5.1 branch),
> >
> > It also applies cleanly against current head, which has the same
> > problem.
>
>
> Hmmm... cache will be local to each core, so the we'll probably get
> speed up by dividing the image into quadrants based on the number of
> threads and having a morton sweep per quadrant.

so on my 16 core, 32 'thread' Ryzen Threadripper, I only see about
1-2% slower execution, so it is probably not a big deal even with a
lot of competing cores.

Having said that, I have some ideas for some further optimizations,
but that would go more into the guts of it (e.g. dividing memory areas
by cores etc.) that I didn't want to start it now for a (hopefully)
5.1 acceptable patch.

-h

>
> But even without, the center spiral patch is a nice touch.
>
> -Seth

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] PATCH: exact match of component with sub-units in schematic did not show

[Henner Zeller]

On Tue, 30 Apr 2019 at 20:24, Henner Zeller  wrote:
>
> Hi,
> so here one digit patch.
>
> Problem Symptom: in the schematic symbol chooser, if you search for an
> exact match of a component with multiple units, it is not selected.
> For instance, search for
>
>74LS00
>
> The scored element is in the tree, but you need to manually unfold it
> (see before.png image). This usually works otherwise (I suspect it has
> to do with the fact that there are sub-units).
>
> The attached change will reliably select the first unit of that
> particular symbol and fix the problem (after.png image).
>
> Now it might be up for debate if the search should actually unfold to
> the first unit or if the tree unfolding should stop at the 74LS00 part
> - I guess if the latter is wished, something dependent on
> tree-children needs to be introduced. I leave that up to you.
>
> Attached: patch (against 5.1 branch),

It also applies cleanly against current head, which has the same problem.

___
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: Raytracing - a more pleasing way sequencing blocks to render ?

[Henner Zeller]

On Wed, 1 May 2019 at 06:54, Mário Luzeiro  wrote:
>
> Hi Henner,
>
> Instead of using SFVEC2UI and hypotf (probably slow), could it be implemented 
> using SFVEC2F and glm::length( a - b ) ?

I didn't know about SFVEC2F or glm::length functions, but then again,
this only happens at preparation time when we set up a new buffer and
blocks to render, so this
happens once whenever the window size changes; everything in that
preparation will probably only take a few microseconds to run even on
an old
machine, so I was not worried either (Whatever glm::length is doing,
will probably just call hyoptf() anyway...)

If there are more elegant ways to describe the same, it should be done
of course.

-h

>
> Mario
> ________
> From: Henner Zeller 
> Sent: 01 May 2019 14:44
> To: John Beard
> Cc: Mário Luzeiro; KiCad Developers
> Subject: Re: [Kicad-developers] PATCH: Raytracing - a more pleasing way 
> sequencing blocks to render ?
>
> On Wed, 1 May 2019 at 06:14, John Beard  wrote:
> >
> > On 01/05/2019 13:57, Mário Luzeiro wrote:
> > > Hi John,
> > >
> > > yeah the Morton code is to improve cache hits.
> > >
> > > Regarding the speed test, since OS are multi-tasking there could be some 
> > > interference on the results so 1s difference is not a very measurable 
> > > difference ( 4% ).
> > > A possibility would be to run the same scene multiple times and make an 
> > > average of the times.
> >
> > Sure, it was just a fun observation. It does change a bit from run to
> > run, but I was at least expecting a small penalty. Next up, wipes[1] and
> > then perhaps Snake :-D
> >
> > A more robust benchmarking harness would probably be the way to go if we
> > really were serious about putting the pedal to the metal here.
> >
> > But I think the centre-first approach is certainly better usability, but
> > I'm unsure about the checkerboard.
>
> I agree, without checkerboard it makes it quicker to see what is going
> on in the center. Attached the (even simpler) just spiraling out from
> the center patch.
>
> >
> > Cheers,
> >
> > John
> >
> > [1]: https://www.youtube.com/watch?v=cGqAu9gj_F0

___
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: Raytracing - a more pleasing way sequencing blocks to render ?

[Henner Zeller]

On Wed, 1 May 2019 at 06:14, John Beard  wrote:
>
> On 01/05/2019 13:57, Mário Luzeiro wrote:
> > Hi John,
> >
> > yeah the Morton code is to improve cache hits.
> >
> > Regarding the speed test, since OS are multi-tasking there could be some 
> > interference on the results so 1s difference is not a very measurable 
> > difference ( 4% ).
> > A possibility would be to run the same scene multiple times and make an 
> > average of the times.
>
> Sure, it was just a fun observation. It does change a bit from run to
> run, but I was at least expecting a small penalty. Next up, wipes[1] and
> then perhaps Snake :-D
>
> A more robust benchmarking harness would probably be the way to go if we
> really were serious about putting the pedal to the metal here.
>
> But I think the centre-first approach is certainly better usability, but
> I'm unsure about the checkerboard.

I agree, without checkerboard it makes it quicker to see what is going
on in the center. Attached the (even simpler) just spiraling out from
the center patch.

>
> Cheers,
>
> John
>
> [1]: https://www.youtube.com/watch?v=cGqAu9gj_F0
diff --git a/3d-viewer/3d_rendering/3d_render_raytracing/c3d_render_raytracing.cpp b/3d-viewer/3d_rendering/3d_render_raytracing/c3d_render_raytracing.cpp
index b059cfeaf..f7fc54b21 100644
--- a/3d-viewer/3d_rendering/3d_render_raytracing/c3d_render_raytracing.cpp
+++ b/3d-viewer/3d_rendering/3d_render_raytracing/c3d_render_raytracing.cpp
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "c3d_render_raytracing.h"
 #include "mortoncodes.h"
@@ -2074,6 +2075,13 @@ bool C3D_RENDER_RAYTRACING::initializeOpenGL()
 }
 
 
+static float distance(const SFVEC2UI , const SFVEC2UI )
+{
+const float dx = (float)a.x - (float)b.x;
+const float dy = (float)a.y - (float)b.y;
+return hypotf(dx, dy);
+}
+
 void C3D_RENDER_RAYTRACING::initialize_block_positions()
 {
 
@@ -2123,26 +2131,26 @@ void C3D_RENDER_RAYTRACING::initialize_block_positions()
 m_postshader_ssao.UpdateSize( m_realBufferSize );
 
 
-// Calc block positions
+// Calc block positions for regular rendering. Choose an 'inside out'
+// style of rendering
 // /
 m_blockPositions.clear();
-m_blockPositions.reserve( (m_realBufferSize.x / RAYPACKET_DIM) *
-  (m_realBufferSize.y / RAYPACKET_DIM) );
-
-i = 0;
-
-while(1)
-{
-SFVEC2UI blockPos( DecodeMorton2X(i) * RAYPACKET_DIM,
-   DecodeMorton2Y(i) * RAYPACKET_DIM );
-i++;
-
-if( (blockPos.x >= m_realBufferSize.x) && (blockPos.y >= m_realBufferSize.y) )
-break;
-
-if( (blockPos.x < m_realBufferSize.x) && (blockPos.y < m_realBufferSize.y) )
-m_blockPositions.push_back( blockPos );
-}
+const int blocks_x = m_realBufferSize.x / RAYPACKET_DIM;
+const int blocks_y = m_realBufferSize.y / RAYPACKET_DIM;
+m_blockPositions.reserve( blocks_x * blocks_y );
+
+for (int x = 0; x < blocks_x; ++x)
+for (int y = 0; y < blocks_y; ++y)
+m_blockPositions.push_back(SFVEC2UI(x * RAYPACKET_DIM,
+y * RAYPACKET_DIM));
+
+const SFVEC2UI center(m_realBufferSize.x/2, m_realBufferSize.y/2);
+std::sort(m_blockPositions.begin(), m_blockPositions.end(),
+  [&](const SFVEC2UI , const SFVEC2UI )
+  {
+  // Sort order: inside out.
+  return distance(a, center) < distance(b, center);
+  });
 
 // Create m_shader buffer
 delete[] m_shaderBuffer;
___
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: Raytracing - a more pleasing way sequencing blocks to render ?

[Henner Zeller]

Hi,
I often use the excellent raytracing mode to get a nice 3D view of the board.

The rendering of the individual blocks is done in a Morton sequence,
possibly to minimize cache-miss penalties.

Since this render sequence starts in one corner, it usually takes a
while until the "meat" of the render hits the interesting parts in the
middle of the board.

So I implemented an alternative sequence: from the center out, in a
growing circle. To ease the time long renders take, it is actually two
complementing checkerboard patterns in consecutive passes (hard to
explain, you have to patch and look for yourself). I find this much
more pleasing to watch and also it helps to early see for the user if
they want to adjust the view as the important parts are rendered
first.

Of course, this will be slightly slower (possibly due to cache
issues), but in measurements on my machine this is typically in the
imperceptible noise (9.0 seconds vs. 9.1 seconds for instance).

Given that there might be a performance penalty I prepared two
patches: one that just does the rendering from the center, and one
which provides a setting in the menu-bar to give full choice.
(it might be good for comparison the two types of renderings, but
given the complexity and the added end-user confusion and the
essentially imperceptible performance penalty, I'd tend towards just
using the simple implementation without menu-bar settings).

Anyway, attached you find two patches:
raytrace-from-center-always.patch just does as described above,
without setting.
The raytrace-from-center-with-menubar-setting.patch goes all the way
of having a menu-bar choice and storing the setting in a configuration
(more complex, less preferred).

These patches are against the 5.1 branch, but it also applies cleanly to master.

Cheers,
  Henner.
diff --git a/3d-viewer/3d_rendering/3d_render_raytracing/c3d_render_raytracing.cpp b/3d-viewer/3d_rendering/3d_render_raytracing/c3d_render_raytracing.cpp
index b059cfeaf..72274ac4b 100644
--- a/3d-viewer/3d_rendering/3d_render_raytracing/c3d_render_raytracing.cpp
+++ b/3d-viewer/3d_rendering/3d_render_raytracing/c3d_render_raytracing.cpp
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "c3d_render_raytracing.h"
 #include "mortoncodes.h"
@@ -2074,6 +2075,13 @@ bool C3D_RENDER_RAYTRACING::initializeOpenGL()
 }
 
 
+static float distance(const SFVEC2UI , const SFVEC2UI )
+{
+const float dx = (float)a.x - (float)b.x;
+const float dy = (float)a.y - (float)b.y;
+return hypotf(dx, dy);
+}
+
 void C3D_RENDER_RAYTRACING::initialize_block_positions()
 {
 
@@ -2123,26 +2131,32 @@ void C3D_RENDER_RAYTRACING::initialize_block_positions()
 m_postshader_ssao.UpdateSize( m_realBufferSize );
 
 
-// Calc block positions
+// Calc block positions for regular rendering. Choose an 'inside out'
+// style of rendering
 // /
 m_blockPositions.clear();
-m_blockPositions.reserve( (m_realBufferSize.x / RAYPACKET_DIM) *
-  (m_realBufferSize.y / RAYPACKET_DIM) );
-
-i = 0;
-
-while(1)
-{
-SFVEC2UI blockPos( DecodeMorton2X(i) * RAYPACKET_DIM,
-   DecodeMorton2Y(i) * RAYPACKET_DIM );
-i++;
-
-if( (blockPos.x >= m_realBufferSize.x) && (blockPos.y >= m_realBufferSize.y) )
-break;
-
-if( (blockPos.x < m_realBufferSize.x) && (blockPos.y < m_realBufferSize.y) )
-m_blockPositions.push_back( blockPos );
-}
+const int blocks_x = m_realBufferSize.x / RAYPACKET_DIM;
+const int blocks_y = m_realBufferSize.y / RAYPACKET_DIM;
+m_blockPositions.reserve( blocks_x * blocks_y );
+
+for (int x = 0; x < blocks_x; ++x)
+for (int y = 0; y < blocks_y; ++y)
+m_blockPositions.push_back(SFVEC2UI(x * RAYPACKET_DIM,
+y * RAYPACKET_DIM));
+
+const SFVEC2UI center(m_realBufferSize.x/2, m_realBufferSize.y/2);
+std::sort(m_blockPositions.begin(), m_blockPositions.end(),
+  [&](const SFVEC2UI , const SFVEC2UI )
+  {
+  // Sort order:
+  // 1) One type of checkerboard pattern first
+  // 2) then inside out
+  const bool half_a = ((a.x / RAYPACKET_DIM) % 2) ^ ((a.y / RAYPACKET_DIM) % 2);
+  const bool half_b = ((b.x / RAYPACKET_DIM) % 2) ^ ((b.y / RAYPACKET_DIM) % 2);
+  if (half_a == half_b)
+  return distance(a, center) < distance(b, center);
+  return half_a < half_b;
+  });
 
 // Create m_shader buffer
 delete[] m_shaderBuffer;
diff --git a/3d-viewer/3d_enums.h b/3d-viewer/3d_enums.h
index 7ff5d1403..2c56c3528 100644
--- a/3d-viewer/3d_enums.h
+++ b/3d-viewer/3d_enums.h
@@ -56,6 +56,7 @@ enum DISPLAY3D_FLG {
 

[Kicad-developers] PATCH: exact match of component with sub-units in schematic did not show

[Henner Zeller]

Hi,
so here one digit patch.

Problem Symptom: in the schematic symbol chooser, if you search for an
exact match of a component with multiple units, it is not selected.
For instance, search for

   74LS00

The scored element is in the tree, but you need to manually unfold it
(see before.png image). This usually works otherwise (I suspect it has
to do with the fact that there are sub-units).

The attached change will reliably select the first unit of that
particular symbol and fix the problem (after.png image).

Now it might be up for debate if the search should actually unfold to
the first unit or if the tree unfolding should stop at the 74LS00 part
- I guess if the latter is wished, something dependent on
tree-children needs to be introduced. I leave that up to you.

Attached: patch (against 5.1 branch), before image and after image.

Cheers,
  Henner.
diff --git a/common/lib_tree_model_adapter.cpp b/common/lib_tree_model_adapter.cpp
index 0a26788af..6ce97930c 100644
--- a/common/lib_tree_model_adapter.cpp
+++ b/common/lib_tree_model_adapter.cpp
@@ -451,7 +451,7 @@ LIB_TREE_NODE* LIB_TREE_MODEL_ADAPTER::ShowResults()
[]( LIB_TREE_NODE const* n )
{
// return leaf nodes with some level of matching
-   return n->Children.size() == 0 && n->Score > 1;
+   return n->Children.size() == 0 && n->Score > 0;
},
 );
 
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Best practice for multi-gate symbols ? (74LVC2G14 has hidden pins)

[Henner Zeller]

On Sun, 21 Apr 2019 at 13:28, Nick Østergaard  wrote:
>
> Hello Henner,
>
> I think the Librarians more or less communicate exclusively via github 
> issues. So it may be worth to post this as an issue on the kicad-symbols repo 
> over on github.

Thanks Nick; looks like this is
https://github.com/KiCad/kicad-symbols/issues/756 and is decided to be
pushed to v6.

-h

___
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] Best practice for multi-gate symbols ? (74LVC2G14 has hidden pins)

[Henner Zeller]

Hi,
While converting some older project to current libraries, I noticed
that the 74LVC2G14 (a dual Schmitt-Trigger inverter) comes with hidden
power pins.

I have not followed the discussions w.r.t. hidden power pins, but it
seems like they are generally discouraged these days (KLC S4.6), which
is good as it does not reflect the reality of many different power
rails in modern circuits.

In other multi-gate symbols I've noticed there is these days on extra
'unit' that essentially contains the power pins; is this the
recommended way these days ? And if so, is someone working on this, or
should I prepare a pull request for 74LVC2G14 ?

Is there a mailing list specifically for library discussions, or is
this the right place ?

Thanks,
  Henner.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Schematic capture: showing connecting line when moving name/value text

[Henner Zeller]

> I’ve added the umbilical lines to the GAL renderer, although I won’t get a 
> chance to merge it for a couple of days….

Cool, thanks! I'll then not look into it deeper.

-h

___
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] Schematic capture: showing connecting line when moving name/value text

[Henner Zeller]

Hi,
A long time ago, I added a little connecting line while moving the
label or value in the schematic editor (BZR4686 now as git commit:
3132c70e54a0c5a61110eab7662e288398145c15 ), which is very helpful to
not loose track of which label belongs to which symbol.

This feature seems to have gotten lost in recent changes (looking at
git master branch), possibly due to overhaul of how rendering is done
?

It looks like this code is currently work-in-progress, so it might be
just temporarily not working; but if this is on nobody's radar, I can
have a look at resurrecting this feature.

Cheers,
  Henner.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Zone fill hangup?

[Henner Zeller]

On 3 February 2018 at 13:29, Steven A. Falco  wrote:
> On 02/03/2018 12:40 PM, Steven A. Falco wrote:
>> On 02/03/2018 12:28 PM, Tomasz Wlostowski wrote:
>>> On 03/02/18 16:57, Steven A. Falco wrote:
 I have been using Kicad 4.0.7 successfully.  I just decided to give the 
 upcoming 5 series a try, so I set up a Fedora VM and loaded the COPR 
 100:r11969.dc66b73-nightlies.fc27 build.

 Most everything I've tried works fine, but zone fill in pcbnew just 
 appears to hang.  Running "top" doesn't show anything sucking up time - it 
 just never completes.

 All that I get is a dialog box titled "Fill All Zones", with a message 
 "Calculating zone fills...".  The Elapsed time counter shows 0:00:00, and 
 the progress bar doesn't move.  If I click the Cancel button, it goes 
 gray, but the box stays up.

 The same thing happens if I try to run a DRC - as soon as it tries to fill 
 zones, it hangs.  This board behaves properly in 4.0.7.  I even tried 
 deleting the zones and re-adding them but that has no effect.

 I've put the project, schematic, board file, etc up on dropbox in case 
 anyone wants to take a look at it:

 https://www.dropbox.com/sh/lw7lhg7jyigvyi7/AAB0ALAWmYS2LmOlw7-spqP6a?dl=0

 I'll be happy to file a bug, but first I wanted to see if this is operator 
 error or a known problem.

>>>
>>> Hi Steve,
>>>
>>> You're using a build from 30 November 2017. Since then the freeze has
>>> been fixed. Your board fills correctly on the latest nightly.
>>>
>>> Tom
>>>
>>
>> Thanks, but now I'm confused.  I downloaded from 
>> https://copr-be.cloud.fedoraproject.org/results/%40kicad/kicad/fedora-27-x86_64/00708625-kicad/
>>  which appears to be from 2018-Feb-03.
>>
>> Could you please point me to the correct place to download the current 
>> Fedora nightlies?
>
> Sorry to reply to my own post, but I've been doing some digging, and I have 
> some new information:
>
> I tried the same project under windows using this nightly: 
> http://downloads.kicad-pcb.org/windows/nightly/kicad-r9348.dc66b73a2-x86_64.exe
>
> It reports its version as "(2018-02-02 revision dc66b73a2)-makepkg, release 
> build", and the SHA1 of dc66b73a2 appears to match the tip of the source tree.
>
> I get the same hang-up in windows when trying to fill all zones that I get in 
> linux.
>
> I'm tempted to conclude that this is a real problem.  Could someone please 
> try loading the project I put on dropbox into their kicad and see if it is 
> reproducible?  All you need to do is open the board file and hit 'b' to 
> trigger a zone refill.

So loading your file (main.kicad_pcb), filling the copper zones works
very quickly for me (< 0.1s on my laptop). The progress bar just
blinks up briefly. Version: [(2017-12-24 revision 570866557)-master,
release build Libraries: wxWidgets 3.0.3]

-h

>
> Steve
>
> ___
> 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] Kicad from scratch, with web technologies. Suggestions?

[Henner Zeller]

On 25 December 2017 at 00:51, Henner Zeller <h.zel...@acm.org> wrote:
> Thanks for your humble introduction. Send a link once you have code. You are
> in for years of work. If you choose to not positively contribute to KiCAD
> with patches or suggestions then why are you here?
>
> All software has issues, and the only way to fix them is to get involved and
> contribute code. Spewing vitriol does _not_ fix code and also makes it hard
> to retain developers once you do consider leading a project, just saying.

So I think I have to retract a little of my statement here. Re-reading
it does sound like the vitriolic the "Kicad sucks and developers are
arrogant" attitude was meant to be an impression in the past and a 1.5
year misunderstanding while Cerems mail here is more like "ah, now I
discovered the developer list and would like to rather contribute, but
don't know C++, and I am wondering if a web-UI makes sense".
I was reading the mail after having read the Kicad user forum post
which was showing an attitude so apologies if I misread your first
mail to the mailing list,l Cerem. It is not very clearly coming
through though.

> As for technology, I am glad that EDA tools are not running in the browser,
> JavaScript is a mess to maintain.

This statement is still true. I don't think it is worthwhile nor
useful to try to redo the UI to run in the browser, but there are many
other things to work on.

-h

So if you go that route, make sure to have
> only the presentation in  "web technology"; still 95% of your code will be
> in the backend and be C, C++, Go or whatever you choose.
>
>
> Good luck
> H
>
> On Dec 25, 2017 08:03, "Cerem Cem ASLAN" <cerem...@ceremcem.net> wrote:
>>
>> Hello everyone,
>>
>> I'm the founder and project engineer of my current company. We are
>> developing open source web based realtime SCADA solutions with or without
>> custom open source hardware. We are using Kicad for our hardware
>> development, and thank you for your hard work.
>>
>> Before the main subject, let me clear an issue:
>>
>> There are a few problems between Kicad and us (me). First, you developers
>> are too arrogant. And your software, Kicad, sucks in many aspects. I can
>> build my own EDA, better than yours, there is no need for Kicad.
>>
>> Yeah, that was what I was thinking for the last 1.5 years and that's
>> corrected a few days ago:
>> https://forum.kicad.info/t/kicad-from-scratch-with-web-technologies/8962 I
>> realized that "those people" were not developers at all, so there was a
>> total misunderstanding on my side. "Kicad sucks"? Nope, every application
>> might have problems. I'm a developer, an engineer, I know that. Sending bug
>> reports and/or sending patches is one of our responsibility as a user (and
>> this is what I did for our workflow:
>> https://github.com/aktos-io/kicad-tools,
>> https://github.com/aktos-io/kicad-install) .
>>
>> Real problem between Kicad an me:
>>
>> There is a "lost" 1.5 years for me because of the above misunderstanding
>> and I have a long wish list. Plus, I don't write C++ applications, which
>> will force me diverging my own effort if I want to dive into Kicad codes. In
>> addition, I feel like a web application might be useful in many cases.
>> Additionally, such a drawing ability will be used for our SCADA product.
>> That's why I've initiated the following project:
>> https://github.com/ceremcem/aecad
>>
>> Above forum thread is too long to be read easily, but I would like to
>> quote one of my thoughts from there:
>>
>>> I have a question: Is KiCAD a tool, or an idea with a physical evidence?
>>> If it's a tool, you are justified "defending" it to the end. If it is an
>>> idea with physical product, then the physical product may change slightly.
>>> Like an airplane. It's an idea about flying. There are many different
>>> airplanes. They share the same knowledge, but these teams can not work on
>>> the same plane. Important part is to keep these teams in touch to let them
>>> chat and share their experiences.
>>
>>
>> Based on this logic, I would like to get your opinions. What design
>> decisions should be taken into account in this step? What would you do
>> differently if you were at the time you started coding Kicad? What are the
>> dead valleys? What would you expect from such a project?
>>
>>
>> Regards.
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Kicad from scratch, with web technologies. Suggestions?

[Henner Zeller]

Thanks for your humble introduction. Send a link once you have code. You
are in for years of work. If you choose to not positively contribute to
KiCAD with patches or suggestions then why are you here?

All software has issues, and the only way to fix them is to get involved
and contribute code. Spewing vitriol does _not_ fix code and also makes it
hard to retain developers once you do consider leading a project, just
saying.

As for technology, I am glad that EDA tools are not running in the browser,
JavaScript is a mess to maintain. So if you go that route, make sure to
have only the presentation in  "web technology"; still 95% of your code
will be in the backend and be C, C++, Go or whatever you choose.


Good luck
H

On Dec 25, 2017 08:03, "Cerem Cem ASLAN"  wrote:

> Hello everyone,
>
> I'm the founder and project engineer of my current company. We are
> developing open source web based realtime SCADA solutions with or without
> custom open source hardware. We are using Kicad for our hardware
> development, and thank you for your hard work.
>
> Before the main subject, let me clear an issue:
>
> There are a few problems between Kicad and us (me). First, you developers
> are too arrogant. And your software, Kicad, sucks in many aspects. I can
> build my own EDA, better than yours, there is no need for Kicad.
>
> Yeah, that was what I was thinking for the last 1.5 years and that's
> corrected a few days ago: https://forum.kicad.info/
> t/kicad-from-scratch-with-web-technologies/8962 I realized that "those
> people" were not developers at all, so there was a total misunderstanding
> on my side. "Kicad sucks"? Nope, every application might have problems. I'm
> a developer, an engineer, I know that. Sending bug reports and/or sending
> patches is one of our responsibility as a user (and this is what I did for
> our workflow: https://github.com/aktos-io/kicad-tools, https://
> github.com/aktos-io/kicad-install) .
>
> Real problem between Kicad an me:
>
> There is a "lost" 1.5 years for me because of the above misunderstanding
> and I have a long wish list. Plus, I don't write C++ applications, which
> will force me diverging my own effort if I want to dive into Kicad codes.
> In addition, I feel like a web application might be useful in many cases.
> Additionally, such a drawing ability will be used for our SCADA product.
> That's why I've initiated the following project: https://github.com/
> ceremcem/aecad
>
> Above forum thread is too long to be read easily, but I would like to
> quote one of my thoughts from there:
>
> I have a question: Is KiCAD a tool, or an idea with a physical evidence?
>> If it's a tool, you are justified "defending" it to the end. If it is an
>> idea with physical product, then the physical product may change slightly.
>> Like an airplane. It's an idea about flying. There are many different
>> airplanes. They share the same knowledge, but these teams can not work on
>> the same plane. Important part is to keep these teams in touch to let them
>> chat and share their experiences.
>>
>
> Based on this logic, I would like to get your opinions. What design
> decisions should be taken into account in this step? What would you do
> differently if you were at the time you started coding Kicad? What are the
> dead valleys? What would you expect from such a project?
>
>
> Regards.
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Flip board view: horizontal scrollbar swapped ?

[Henner Zeller]

Hi,
I just tried the 'Flip Board View' feature. Neat - but is it
intentional that the horizontal scrollbar now works, uhm, inversed ?
It feels very unintuitive ...

Cheers,
 -h

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Python: time_t needs mapping; tentative patch

[Henner Zeller]

On 7 December 2017 at 05:12, jp charras <jp.char...@wanadoo.fr> wrote:
> Le 07/12/2017 à 09:11, jp charras a écrit :
>> Le 07/12/2017 à 01:20, Wayne Stambaugh a écrit :
>>> JP,
>>>
>>> Would you please test this patch when you get a chance?  I took a quick
>>> look at it and it seems correct but I don't know when I will have time
>>> to test it.
>>>
>>> Thanks,
>>>
>>> Wayne
>>
>> No problem.
>>
>>>
>>> On 12/05/2017 12:00 PM, Henner Zeller wrote:
>>>> Alright, here is a reworked patch that includes the ideas discussed here
>>>>
>>>>   - Where we used to use time_t in the functions that deal with
>>>> timestamps, this is now done with a new typedef timestamp_t that makes
>>>> sure the c++ side and swigged Python side agree on the type.
>>>>   - this typedef is now in common.h, close to the declaration of
>>>> GetNewTimeStamp()
>>>>   - The type of this type is 'long' as this makes sure that it is at
>>>> least 32 bits. Trying to use something like int32_t did not work well
>>>> with swig that seems to be more comfortable by default with the
>>>> standard types (but some local Swig expert might know how to do this)
>>>>
>>>> Cheers,
>>>>   Henner.
>>
>>
>
> Hi Henner,
>
> I committed your patch. Thanks.

Thanks Jean-Pierre. I confirmed that getting/setting timestamps now
works in Python (which triggered this all).

-h

>
> --
> Jean-Pierre CHARRAS
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Python: time_t needs mapping; tentative patch

[Henner Zeller]

Alright, here is a reworked patch that includes the ideas discussed here

  - Where we used to use time_t in the functions that deal with
timestamps, this is now done with a new typedef timestamp_t that makes
sure the c++ side and swigged Python side agree on the type.
  - this typedef is now in common.h, close to the declaration of
GetNewTimeStamp()
  - The type of this type is 'long' as this makes sure that it is at
least 32 bits. Trying to use something like int32_t did not work well
with swig that seems to be more comfortable by default with the
standard types (but some local Swig expert might know how to do this)

Cheers,
  Henner.


timestamp-type.patch.gz
Description: GNU Zip compressed data
___
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] Build failed in Jenkins: linux-kicad-full-gcc-head #2589

[Henner Zeller]

b

On 5 December 2017 at 07:25, Miguel Angel Ajo  wrote:
> See 
> 
>
> Changes:
>
> [tomasz.wlostowski] pcbnew: Optimized zone filling algorithm.
>
> [tomasz.wlostowski] SHAPE_FILE_IO: default constructor outputs to stdout
>
> [tomasz.wlostowski] SHAPE_POLY_SET: fix empty triangulation bug
>
> [tomasz.wlostowski] pcbnew: made TransformShapeWithClearanceToPolygon virtual
>
> [tomasz.wlostowski] Sample tool for generating board geometyr as polygons
>
> [tomasz.wlostowski] PCB_TOOL: added convenience methods for accessing current 
> SELECTION
>
> [tomasz.wlostowski] POINT_EDITOR: migrate to ZONE_FILLER class
>
> [tomasz.wlostowski] pcbnew: factored out ZONE_FILLER to a separate file
>
> [tomasz.wlostowski] pcbnew: removed unused files
>
> [tomasz.wlostowski] pcbnew: Optimized zone filling algorithm: code cleanup
>
> [tomasz.wlostowski] pcbnew: made zone filling algorithm thread-safe. - moved 
> zone filling
>
> [tomasz.wlostowski] WX_PROGRESS_REPORTER: fix assert warnings
>
> [tomasz.wlostowski] WX_PROGRESS_REPORTER: fixed windows build error
>
> [tomasz.wlostowski] pcbnew: now PROGRESS_REPORTER should work in 
> multi-threaded context
>
> [tomasz.wlostowski] poly2tri: fixed some warnings
>
> --
> [...truncated 152.74 KB...]
> [ 88%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_fp_lib_table_base.cpp.o
> [ 88%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_fp_lib_table.cpp.o
> [ 88%] Built target eeschema_kiface
> [ 88%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_fp_plugin_options_base.cpp.o
> Scanning dependencies of target eeschema
> [ 88%] Building CXX object 
> eeschema/CMakeFiles/eeschema.dir/__/common/single_top.cpp.o
> [ 88%] Building CXX object 
> eeschema/CMakeFiles/eeschema.dir/__/common/pgm_base.cpp.o
> [ 88%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_fp_plugin_options.cpp.o
> [ 88%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_freeroute_exchange.cpp.o
> [ 88%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_freeroute_exchange_base.cpp.o
> [ 88%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_gencad_export_options.cpp.o
> [ 88%] Linking CXX executable eeschema
> [ 88%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_gendrill.cpp.o
> [ 88%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_gendrill_base.cpp.o
> [ 88%] Built target eeschema
> Scanning dependencies of target qa_eagle_plugin
> [ 88%] Building CXX object 
> eeschema/qa/CMakeFiles/qa_eagle_plugin.dir/test_module.cpp.o
> [ 88%] Building CXX object 
> eeschema/qa/CMakeFiles/qa_eagle_plugin.dir/test_basic.cpp.o
> [ 88%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_gen_module_position_file_base.cpp.o
> [ 88%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_general_options.cpp.o
> [ 88%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_general_options_BoardEditor_base.cpp.o
> [ 88%] Linking CXX executable qa_eagle_plugin
> [ 88%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_get_footprint_by_name_base.cpp.o
> [ 88%] Built target qa_eagle_plugin
> [ 88%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_global_edit_tracks_and_vias.cpp.o
> [ 88%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_global_edit_tracks_and_vias_base.cpp.o
> [ 88%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_global_modules_fields_edition.cpp.o
> [ 88%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_global_modules_fields_edition_base.cpp.o
> [ 89%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_global_pads_edition_base.cpp.o
> [ 89%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_global_pads_edition.cpp.o
> [ 89%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_graphic_items_options.cpp.o
> [ 89%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_graphic_items_options_base.cpp.o
> [ 89%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_graphic_item_properties.cpp.o
> [ 89%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_graphic_item_properties_base.cpp.o
> [ 89%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_graphic_item_properties_for_Modedit.cpp.o
> [ 89%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_global_deletion.cpp.o
> [ 89%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_global_deletion_base.cpp.o
> [ 89%] Building CXX 

Re: [Kicad-developers] Zone filling & display speed improvements

[Henner Zeller]

On 5 December 2017 at 06:02, Tomasz Wlostowski
 wrote:
> On 05/12/17 08:55, jp charras wrote:
>> Le 05/12/2017 à 01:41, Tomasz Wlostowski a écrit :
>>> Hi guys,
>>>
>>> Now it should work fine - the filling algorithm was not thread safe and
>>> apparently wxProgressDialog can't be invoked from non-main thread.
>>>
>>> Check out the updated branch.
>>>
>>> Thanks!
>>> Tom
>>>
>>
>> Hi Tom,
>>
>> It works fine for me.
>> And on my 4 cores computer, the speedup is really impressive!
>>
>> Thanks.
>>
>
> Hi guys,
>
> Thanks for testing, I just merged it to the master.

There is still the left-over method RemoveInsulatedCopperIslands()
declaration that is otherwise never defined or used; so this needs to
be done:


--- a/pcbnew/class_zone.h
+++ b/pcbnew/class_zone.h
@@ -151,13 +151,6 @@ public:

int GetClearance( BOARD_CONNECTED_ITEM* aItem = NULL ) const override;

-/**
- * Function RemoveInsulatedCopperIslands
- * Remove insulated copper islands found in m_FilledPolysList.
- * @param aPcb = the board to analyze
- */
-void RemoveInsulatedCopperIslands( BOARD* aPcb );
-
/**
 * Function IsOnCopperLayer
 * @return true if this zone is on a copper layer, false if on a
technical layer


(This will prevent the scripting from compiling as Swig is generating
stub-code from the header but then complains while linking that it
does not exist).

-h

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

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Zone filling & display speed improvements

[Henner Zeller]

On 4 December 2017 at 16:41, Tomasz Wlostowski
<tomasz.wlostow...@cern.ch> wrote:
> On 04/12/17 15:43, Henner Zeller wrote:
>> On 4 December 2017 at 06:31, Tomasz Wlostowski
>> <tomasz.wlostow...@cern.ch> wrote:
>>> On 04/12/17 02:05, Henner Zeller wrote:
>>>> On 2 December 2017 at 10:11, Henner Zeller <h.zel...@acm.org> wrote:
>>>>> On 1 December 2017 at 08:12, Tomasz Wlostowski
>>>>> <tomasz.wlostow...@cern.ch> wrote:
>>>>>> On 29/11/17 16:10, jp charras wrote:
>>>>>>> I am using a few board in Kicad demos: interf_u, video, pic_programmer.
>>>>>>>
>>>>>>> Also, filled areas are no shown in OpenGL, but are shown in Cairo 
>>>>>>> canvas.
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> The branch [1] contains a set of improvements in the zone filling
>>>>>> algorithm. It's several times faster than in the current master branch.
>>>>>>
>>>>>> I'd like to merge it soon and move on to fixing P issues pending for
>>>>>> the V5 - I'll greatly appreciate testing and feedback!
>>>>>
>>>>> Hi Tom,
>>>>>
>>>>> I'll compile your branch hopefully later this weekend for testing.
>>>>> If you need another board for testing, I am currently having a board
>>>>> that takes annoying several seconds to fill the zones in head KiCad,
>>>>> which hence might be interesting test case:
>>>
>>> Hi Henner,
>>>
>>> What OS did you build for?
>>
>> This was on Debian testing on a x86_64 machine.
>> g++ 7.2.0, Cairo: 1.15.8, boost 1.62.0
>>
>> -h
>
> Hi guys,
>
> Now it should work fine - the filling algorithm was not thread safe and
> apparently wxProgressDialog can't be invoked from non-main thread.
>
> Check out the updated branch.

Thanks Tom!

Nice, the [tom-faster-zones-dec01] branch works well and very fast. I
have not seen any crashes anymore.

There is a leftover method mentioned in pcbnew/class_zone.h:
  void RemoveInsulatedCopperIslands()
.. which is not used/implemented so should be removed from the header.

One thing I noticed: since it is sooo fast now, the progress-popup is
actually quite annoying as it just briefly blinks up and vanishes
again (at least for the board I was testing it with). Maybe it should
only show up if the operation is still ongoing after a second and less
than 50% is done at that time ?

Another thought: if zone filling can be that fast, maybe we should
only store zone outlines in the *.kicad_pcb file, not the
(filled_polygon ...) that are now also stored. It is cheap to just
recreate them when loading the file.
Backround: This can save a lot of disk space as the filled polygons
tend to create a lot of points and tend to completely change with tiny
changes to other elements on the board, such as a moved via. This
means that version control has to store huge changes every time and it
is hard to see what actual changes are happening just looking at the
diff (I like to inspect diffs before checking something in, and this
makes it hard. Also it makes it hard to git merge kicad-pcbs).
Downside is, that everyone loading a file has to pay the extra cost to
create the zones (e.g. gerber generation). Maybe it could be a
heuristic to not store the filled polygons if recreating it takes less
than a second or so.

Cheers,
  Henner.

>
> Thanks!
> Tom
>

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Zone filling & display speed improvements

[Henner Zeller]

On 4 December 2017 at 06:31, Tomasz Wlostowski
<tomasz.wlostow...@cern.ch> wrote:
> On 04/12/17 02:05, Henner Zeller wrote:
>> On 2 December 2017 at 10:11, Henner Zeller <h.zel...@acm.org> wrote:
>>> On 1 December 2017 at 08:12, Tomasz Wlostowski
>>> <tomasz.wlostow...@cern.ch> wrote:
>>>> On 29/11/17 16:10, jp charras wrote:
>>>>> I am using a few board in Kicad demos: interf_u, video, pic_programmer.
>>>>>
>>>>> Also, filled areas are no shown in OpenGL, but are shown in Cairo canvas.
>>>>
>>>> Hi all,
>>>>
>>>> The branch [1] contains a set of improvements in the zone filling
>>>> algorithm. It's several times faster than in the current master branch.
>>>>
>>>> I'd like to merge it soon and move on to fixing P issues pending for
>>>> the V5 - I'll greatly appreciate testing and feedback!
>>>
>>> Hi Tom,
>>>
>>> I'll compile your branch hopefully later this weekend for testing.
>>> If you need another board for testing, I am currently having a board
>>> that takes annoying several seconds to fill the zones in head KiCad,
>>> which hence might be interesting test case:
>
> Hi Henner,
>
> What OS did you build for?

This was on Debian testing on a x86_64 machine.
g++ 7.2.0, Cairo: 1.15.8, boost 1.62.0

-h

>
> Tom

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Zone filling & display speed improvements

[Henner Zeller]

On 2 December 2017 at 10:11, Henner Zeller <h.zel...@acm.org> wrote:
> On 1 December 2017 at 08:12, Tomasz Wlostowski
> <tomasz.wlostow...@cern.ch> wrote:
>> On 29/11/17 16:10, jp charras wrote:
>>> I am using a few board in Kicad demos: interf_u, video, pic_programmer.
>>>
>>> Also, filled areas are no shown in OpenGL, but are shown in Cairo canvas.
>>
>> Hi all,
>>
>> The branch [1] contains a set of improvements in the zone filling
>> algorithm. It's several times faster than in the current master branch.
>>
>> I'd like to merge it soon and move on to fixing P issues pending for
>> the V5 - I'll greatly appreciate testing and feedback!
>
> Hi Tom,
>
> I'll compile your branch hopefully later this weekend for testing.
> If you need another board for testing, I am currently having a board
> that takes annoying several seconds to fill the zones in head KiCad,
> which hence might be interesting test case:
>
> https://github.com/hzeller/quadrigotion.git
> path tmc2660/tmc2660-quad.kicad_pcb

So I tested your branch with the board above and it seems to work
quickly iff it does not crash; but it crashes
often. Sometimes the first time, sometimes the second time doing a
zone-recalculation (Tested under Cairo)

I have not debugged the full reason, but it seems to happen when
deleting a SHAPE_POLY_SET, somewhere around

ZONE_CONTAINER::BuildFilledSolidAreasPolygons () at
pcbnew/zone_filling_algorithm.cpp:138

Even if it is made sure that m_smoothedPoly has a defined value at
construction time with e.g.

---
--- a/pcbnew/class_zone.h
+++ b/pcbnew/class_zone.h
@@ -739,7 +739,7 @@ private:
void buildFeatureHoleList( BOARD* aPcb, SHAPE_POLY_SET& aFeatures );

SHAPE_POLY_SET*   m_Poly;///< Outline of the zone.
-SHAPE_POLY_SET*   m_smoothedPoly;// Corner-smoothed
version of m_Poly
+SHAPE_POLY_SET*   m_smoothedPoly = nullptr;//
Corner-smoothed version of m_Poly
int   m_cornerSmoothingType;
unsigned int  m_cornerRadius;
--

it still crashes, possibly because the recursive deleting it might
attempt to delete some shared SHAPE_LINE_CHAIN in it ?
Running it with valgrind indicates some double-delete issue.

Making this explicitly leak in pcbnew/zone_filling_algorithm.cpp:138
by removing the 'delete' it does not crash, so there is definitely
some double-delete stuff going on.

( there is also a lot of
../src/generic/progdlgg.cpp(435): assert "value <= m_maximum" failed
in Update(): invalid progress valu
e [in thread 20c55700]
../src/gtk/gauge.cpp(95): assert "pos <= m_rangeMax" failed in
SetValue(): invalid value in wxGauge::SetValue() [in thread 20c55700]

going on when compiling in debug mode, but I don't know if that is
related/relevant
)

Then when that is 'worked around', there are other crashes later when
selecting ranom zones, this is a typical stack trace.

#8  0x7fffe886e539 in PROGRESS_REPORTER::SetMaxProgress
(this=0x5843f800, aMaxProgress=193)
   at common/widgets/progress_reporter.cpp:62
#9  0x7fffe870700d in CN_CONNECTIVITY_ALGO::searchConnections
(this=0x572bfd00,
   aIncludeZones=true) at pcbnew/connectivity_algo.cpp:520
#10 0x7fffe87076db in CN_CONNECTIVITY_ALGO::SearchClusters
(this=0x572bfd00,
   aMode=CN_CONNECTIVITY_ALGO::CSM_RATSNEST, aTypes=0x57ce68e0,
aSingleNet=-1)
   at pcbnew/connectivity_algo.cpp:632
#11 0x7fffe8707480 in CN_CONNECTIVITY_ALGO::SearchClusters
(this=0x572bfd00,
   aMode=CN_CONNECTIVITY_ALGO::CSM_RATSNEST)
   at pcbnew/connectivity_algo.cpp:616
#12 0x7fffe8709243 in CN_CONNECTIVITY_ALGO::GetClusters
(this=0x572bfd00)
   at pcbnew/connectivity_algo.cpp:906
#13 0x7fffe86f77f5 in CONNECTIVITY_DATA::RecalculateRatsnest
(this=0x58052e70)
   at pcbnew/connectivity_data.cpp:147
#14 0x7fffe86a0f20 in BOARD_COMMIT::Push (this=0x57ce6c40,
aMessage=...,
   aCreateUndoEntry=false) at pcbnew/board_commit.cpp:281
#15 0x7fffe851ad18 in PCB_EDIT_FRAME::Fill_Zone
(this=0x56e0a4d0, aZone=0x5811f300)
   at pcbnew/zones_by_polygon_fill_functions.cpp:123
#16 0x7fffe8546577 in POINT_EDITOR::finishItem (this=0x587035f0)
   at pcbnew/tools/point_editor.cpp:575
#17 0x7fffe854535c in POINT_EDITOR::OnSelectionChange
(this=0x587035f0, aEvent=...)
   at pcbnew/tools/point_editor.cpp:379

Hope this is some useful input,
Henner.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Zone filling & display speed improvements

[Henner Zeller]

On 1 December 2017 at 08:12, Tomasz Wlostowski
 wrote:
> On 29/11/17 16:10, jp charras wrote:
>> I am using a few board in Kicad demos: interf_u, video, pic_programmer.
>>
>> Also, filled areas are no shown in OpenGL, but are shown in Cairo canvas.
>
> Hi all,
>
> The branch [1] contains a set of improvements in the zone filling
> algorithm. It's several times faster than in the current master branch.
>
> I'd like to merge it soon and move on to fixing P issues pending for
> the V5 - I'll greatly appreciate testing and feedback!

Hi Tom,

I'll compile your branch hopefully later this weekend for testing.
If you need another board for testing, I am currently having a board
that takes annoying several seconds to fill the zones in head KiCad,
which hence might be interesting test case:

https://github.com/hzeller/quadrigotion.git
path tmc2660/tmc2660-quad.kicad_pcb

Cheers,
  Henner.

>
> Tom
>
> [1] https://github.com/twlostow/kicad-dev/tree/tom-faster-zones-dec01
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Python: time_t needs mapping; tentative patch

[Henner Zeller]

>>> IIRC the timestamp is just an unique ID of the item in Kicad, right?
>>> It's never propagated to the system time, so 64-bits IMHO 64-bits should
>>> be safe everywhere.
>>>
>>> Tom
>>
>> Yes it is a unique ID only.
>> It is converted to a date in footprint editor (legacy mode) to show the last 
>> edition date to the user.
>> This is easy to convert a uint64_t to show this message.
>
> I suppose the most elegant solution would be to change time_t in KiCad
> source code to uint64_t. This leaves no ambiguity and should be easy to
> handle with swig.

This sounds good to me, in particular as it reflects more the use of
what this is (a unique ID instead of a timestamp).

-h

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Python: time_t needs mapping; tentative patch

[Henner Zeller]

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

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

Cheers,
  Henner.

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

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Python: time_t needs mapping; tentative patch

[Henner Zeller]

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

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

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

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

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

Thanks,
  Henner.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] All kinds of glitches because polygons don't have an origin. Also: Outline ?

[Henner Zeller]

On 25 November 2017 at 07:01, Wayne Stambaugh <stambau...@gmail.com> wrote:
> I though Tom mentioned he had done some work on this but that may have
> been some other board editing tool.

So I looked a little more into it, it looks like this is mostly
because the GetStart()/GetPosition() etc. return (0,0) for S_POLYGON
in class DRAWSEGMENT. Many parts that handle drawsegments assume these
to have reasonable values. It happens to draw correctly when drawn the
first time, but rotating or moving does not result in a properly
placed polygon.

Things to do:
   * SetStart()/GetStart()/SetPosition()/GetPostion() should return
something reasonable; That way, rotation would have a proper anchor
point.
   * DRAWSEGMENT::Move() should iterate through m_Poly to move each point.
   * something strange: in PCB_PAINTER::draw( const DRAWSEGMENT*
aSegment, int aLayer ), there is a strange
 m_gal->Translate( aSegment->GetPosition() )
 which right now is a no-op, but once GetPosition() returns
something proper, this won't change.

These are too many moving parts to digg into while Thanksgiving family
stuff is going on in the background :) But someone more familiar with
the code might use the above as a starting point for debugging.

It looks like this became fragile because class DRAWSEGMENT is trying
to do too much: it can represent a line, a polyogn, an arc, a bezier
coruve; each of these have slightly different interpretations of what
m_Start/m_End means, which makes things a little fragile. Might be
worthwhile looking into this this more detailed after the release; I
am happy to help with this once I got myself more into the code base
again after a 2 year hiatus.

Anyway, maybe it might be a good idea to disable the polygon drawing
button in pcbnew before the imminent release until that is fixed ? It
might just be frustrating to users.

[ The artifacts show up similarly in Ciaro and OpenGL. To reproduce:
draw a polygon. Select it and attempt to move or rotate. Observe how
they seem to 'disappear', but this is only because they are moved
around the imaginary position (0,0). ]

Cheers,
  Henner.

>
> On 11/25/2017 08:28 AM, Henner Zeller wrote:
>> Is someone working on this bug or should I have a stab at it ?
>>
>> On 20 November 2017 at 21:26, Henner Zeller <h.zel...@acm.org> wrote:
>>> Hi,
>>> I am playing with polygons currently and notice that they only really
>>> can be created, but not moved or copied.
>>>
>>> A move (m) creates a phantom polygon on the screen that is offset from
>>> the polygon the same distance as the original polygon from the origin.
>>> A similar glitch happens when attempting to copy a polygon.
>>>
>>> This indicates that the polygon does not really have a position that
>>> is rooted in the e.g. top-left point, but that its Position is always
>>> kept at (0,0).
>>> This is confirmed when reading the board with the Python API and
>>> printing GetPosition().
>>>
>>> The dialog for the polygon (edit dialog) also shows that all positions
>>> Start (x,y) and End (x,y) are zero.
>>>
>>> I think the whole confusion comes because the original idea of a draw
>>> segment has the concept of a line which has a clear start/endpoint. So
>>> maybe some SetStart() needs to be done whenever a polygon is moved ?
>>>
>>> I wonder if the concept of Polygons and Zones can be merged: both of
>>> them allow to fill an area in the layer and have the same editing
>>> controls with the control points (and zones work).
>>>
>>> -h
>>
>> ___
>> 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] All kinds of glitches because polygons don't have an origin. Also: Outline ?

[Henner Zeller]

Is someone working on this bug or should I have a stab at it ?

On 20 November 2017 at 21:26, Henner Zeller <h.zel...@acm.org> wrote:
> Hi,
> I am playing with polygons currently and notice that they only really
> can be created, but not moved or copied.
>
> A move (m) creates a phantom polygon on the screen that is offset from
> the polygon the same distance as the original polygon from the origin.
> A similar glitch happens when attempting to copy a polygon.
>
> This indicates that the polygon does not really have a position that
> is rooted in the e.g. top-left point, but that its Position is always
> kept at (0,0).
> This is confirmed when reading the board with the Python API and
> printing GetPosition().
>
> The dialog for the polygon (edit dialog) also shows that all positions
> Start (x,y) and End (x,y) are zero.
>
> I think the whole confusion comes because the original idea of a draw
> segment has the concept of a line which has a clear start/endpoint. So
> maybe some SetStart() needs to be done whenever a polygon is moved ?
>
> I wonder if the concept of Polygons and Zones can be merged: both of
> them allow to fill an area in the layer and have the same editing
> controls with the control points (and zones work).
>
> -h

___
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] Polygons: should have outline mode to draw Edge.Cuts

[Henner Zeller]

Hi,
So polygons are very neat as they employ the nice polygon drawing
features we are used to from zone drawing [*1].

A missing feature here is to _not_ have them filled but simply an
outline. Why ? This would be _very_ useful to draw Edge.Cuts.
Currently, the only way is to draw single lines, which are then hard
to adjust later, as they all fall apart into separate lines, and have
to be edited manually.

Now, if that could be drawn with the polygon tool, that would remove a
hge pain having to deal with outlines (and yes, I know the usual
advice to draw that separately and import as DXF. But what if I could
just do simple polygons directly ?).

Also what we could get for almost free then: Chamfers and Fillets. I
like to have boards with rounded corners [*2], but currently this is
of course a torture to do manually and and dread it every time it
comes to that part of the project: draw a rectangle with the line
tool. Do circles in the corners and manually calculate where the
center and the start point is, shorten the lines accordingly to match
the length shorter the radius. Do that on all four corners. That
easily takes several minutes and high concentration. And god forbid
one wants to change that again later ...

Now how wounderful that would be if that could be done with the
Polygon tool and I just choose to have a fillet or camfer. If this is
something nobody is working on yet and if people think this is a good
idea, I might have a look over the Thanksgiving days.

Cheers,
  Henner.


[*1] also see my mail before [All kinds of glitches], Polygons as-is
are currently broken and maybe the concept should be merged with the
zone ?

[*2] 
https://raw.githubusercontent.com/hzeller/quadrigotion/master/img/tmc2660-quad-render.jpg

___
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] All kinds of glitches because polygons don't have an origin. Also: Outline ?

[Henner Zeller]

Hi,
I am playing with polygons currently and notice that they only really
can be created, but not moved or copied.

A move (m) creates a phantom polygon on the screen that is offset from
the polygon the same distance as the original polygon from the origin.
A similar glitch happens when attempting to copy a polygon.

This indicates that the polygon does not really have a position that
is rooted in the e.g. top-left point, but that its Position is always
kept at (0,0).
This is confirmed when reading the board with the Python API and
printing GetPosition().

The dialog for the polygon (edit dialog) also shows that all positions
Start (x,y) and End (x,y) are zero.

I think the whole confusion comes because the original idea of a draw
segment has the concept of a line which has a clear start/endpoint. So
maybe some SetStart() needs to be done whenever a polygon is moved ?

I wonder if the concept of Polygons and Zones can be merged: both of
them allow to fill an area in the layer and have the same editing
controls with the control points (and zones work).

-h

___
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] tiny Patch: fix board.Save() breakage in Python scripting

[Henner Zeller]

Hi,
While playing around with the Python API, I noticed that saving a
board didn't work.
Apparently there was a parameter IO_MGR.KICAD passed internally that
the interpreter didn't know about.

The attached patch fixes it, but I have no idea if this is the
'correct' way to do it.

Cheers,
  Henner


saveboard-py.patch.gz
Description: GNU Zip compressed data
___
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: Fix module pad sequence storage

[Henner Zeller]

Hi,
When openeing a kicad_pcb and storing it again, the pads in all
embedded modules get reversed. This is generally not really nice if
the pcb is managed by version control as it creates churn and could
make merges hard.

The problem is that pads are inserted rather than appended when
loading a pcb, so the pads are reversed on reading. The attached patch
that fixes that.

In general, there are more places of Add() where ADD_APPEND would
probably make more sense (e.g. in the copy constructor and the
assignment operator for MODULE), but I have not touched these here as
it requires more thorough inspection.

The fact that the default behavior is ADD_INSERT probably results in a
lot of trouble. I wonder when _ever_ someone means to insert things in
the beginning ? It feels like a rare operation. Maybe not making the
kind of insert operation a default parameter of the Add() function but
rather have the user decide every time which operation is needed -
this might reduce the accidents like this (in particular, since the
name of the operation, Add(), kindof more strongly implies appending).
(and I would almost bet that we don't even need ADD_INSERT so could
simplify a lot of places).

Anyway, something I might look into when having a little more time
(all BOARD_ITEM_CONTAINER have that, so there are probably more bugs
like this lurking). This is the second issue like that I noticed (last
year same with segments).

For now a simple patch that fixes the issue at hand.

Cheers,
  Henner.


patch-fix-alternating-pad-save-sequence.patch.gz
Description: GNU Zip compressed data
___
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] Eeschema: add wildcard and regex support to component chooser

[Henner Zeller]

On 19 December 2015 at 16:32, Chris Pavlina <pavlina.ch...@gmail.com> wrote:
> I'm fine with this one, and it all works quite well so I'm assuming Henner
> considers it final. I'd commit it.

Yes, considered final, ready to submit.

(And yes, sorry if I screwed up code styles, I try to be more careful.
Too many projects with different styles to juggle)

-h

>
> On Dec 19, 2015 7:21 PM, "Wayne Stambaugh" <stambau...@gmail.com> wrote:
>>
>> On 12/19/2015 2:57 AM, Henner Zeller wrote:
>> > On 18 December 2015 at 21:57, Henner Zeller <h.zel...@acm.org> wrote:
>> >> On 18 December 2015 at 21:50, Chris Pavlina <pavlina.ch...@gmail.com>
>> >> wrote:
>> >>> On Fri, Dec 18, 2015 at 09:40:29PM -0800, Henner Zeller wrote:
>> >>>> On 18 December 2015 at 21:33, Chris Pavlina <pavlina.ch...@gmail.com>
>> >>>> wrote:
>> >>>>> I'm not going to argue about search methods, it'll suffice to say I
>> >>>>> disagree. I don't _want_ to search my library your way, and yes, I
>> >>>>> understand that it can work.
>> >>>>>
>> >>>>> I'm unconvinced that adding one option box is excessive complexity.
>> >>>>> It's
>> >>>>> not in the main UI, it's in the preferences dialog. What's wrong
>> >>>>> with
>> >>>>> preferences? Users can ignore those. Most do. Though the preferences
>> >>>>> dialog does need to be reorganized.
>> >>>>
>> >>>> The problem is, that people don't find it. They get frustrated
>> >>>> because
>> >>>> they want to search with regular expressions, but it doesn't work.
>> >>>> And
>> >>>> they never find the option to set it.
>> >>>
>> >>> Somehow I don't think that wildcard/regex search is going to be a big
>> >>> advertised feature that all the kids will be flocking to kicad for. I
>> >>> also doubt that the sort of person who would want it is the sort of
>> >>> person who couldn't be bothered to look at the options.
>> >>>
>> >>>>
>> >>>> If the dialog would do all matches in parallel and increases scores
>> >>>> for each matcher that triggers, then you get all the simple matching
>> >>>> I
>> >>>> am proposing and all the extended regular expression searching that
>> >>>> you want. And it will work automatically without anyone ever setting
>> >>>> an option.
>> >>>
>> >>> Yes, and clutters up the results with false matches, just like
>> >>> searching
>> >>> for "ATXMEGA*D3" by typing "ATXMEGA D3" does.
>> >>
>> >> But if you have all scoring functions engaged, the relevant come first.
>> >>
>> >>>
>> >>> Seriously, what is it with this mailing list? Every time someone
>> >>> suggests a simple idea, everyone immediately piles on with their
>> >>> favorite way to overcomplicate it.
>> >>
>> >> Calm down. I make suggestions to _simplify_, not complicate.
>> >>
>> >>>
>> >>> I just suggested adding this because I thought it'd be a simple
>> >>> addition
>> >>> that might add some utility for some people. Never imagined wildcards
>> >>> could be so controversial.
>> >>
>> >> As I said, I like wildcards and regexp and like to see them supported.
>> >> But I suggested way to support them automatically.
>> >>
>> >>> Take it or leave it, I'm not going to keep
>> >>> revising it to make it more complex.
>> >>
>> >> You don't have to. I can do that.
>> >
>> > Attached, the simplified patch, using your new matchers:
>> >
>> >* Uses all your matchers, but does not need to have the factory.
>> >* No need for extra code to add option for users.
>> >* Same effect. People can use any syntax they want and get matches
>> > accordingly.
>> >* It is very unlikely to get unwanted results.
>> >* Less code (366 vs 833 loc)
>> >* More user friendly to use (no search for obscure options, if
>> > someone uses FOO*BAR or a regexp it just works as expected).
>>
>> Is this the patch that should be committed?  I took a look at it and 

Re: [Kicad-developers] 3D refactor

[Henner Zeller]

On 18 December 2015 at 23:07, Cirilo Bernardo  wrote:
> Hi folks,
>
>  I've gone over the changes in the 3d_initial_merge branch and it looks like
> it's ready for people to inspect the code and merge with the main branch.
>
>  At the moment the legacy 3DViewer is left intact but the Footprint
> Properties dialogs in pcbnew and the Footprint Editor have an improved
> GUI which includes a special widget on the 3D File Browser to configure
> the 3D search paths and of course the model preview in the Footprint
> Properties dialog.
>
> So far only an IDF Component Outline plugin has been implemented
> (I'm not counting the plugins developed for demo/tutorials) but I'd like
> the code to get into the main branch as soon as practical so people
> can test it more and help find any remaining bugs. A merge would
> also give the 2x 3D branches (Mario's and mine) a more solid foundation
> in the main branch and help prevent a fork-like situation where it
> becomes very difficult to stage a merge.  Even this relatively small
> initial merge has taken a few weeks of my spare time to prepare and
> I've already encountered some instances of code divergence which
> have broken the build.
>
> https://code.launchpad.net/~cirilo-bernardo/kicad/3d_initial_merge

For testing: Is there a simple way to extract a patch from launchpad ?
(I am using git, so I need to get the patch out of bzr first...)

>
> Added approx. 17k sloc
>
> - Cirilo
>
>
> ___
> 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] [RFC] Wildcard and/or regex support in the component chooser

[Henner Zeller]

On 18 December 2015 at 09:20, Chris Pavlina  wrote:
> No, and I'm highly skeptical it'll achieve what I'm looking for. Can you
> give an example of what you mean? How do I search for "ATXMEGA*D3" and
> get "ATXMEGA64D3", "ATXMEGA128D3", "ATXMEGA256D3", etc to come up?

you type
  ATXMEGA D3
in the component search box. without any regexp.

>
> On Fri, Dec 18, 2015 at 12:14:33PM -0500, Jon Evans wrote:
>> More and more modern text editing software is moving to fuzzy string
>> matching rather than explicitly requiring users to put in wildcards when
>> doing searches for filenames, code intelligence searches (i.e. match
>> function / class names etc).  Have you considered that as an option?
>>
>> On Fri, Dec 18, 2015 at 12:08 PM, Chris Pavlina 
>> wrote:
>>
>> > Would everyone be okay with me patching the eeschema component chooser
>> > to support wildcards or regexes? And if yes, what's the preference -
>> > simple *? wildcards, regexes, or selectable in preferences? (Plan is to
>> > make it totally disableable [is that a word? :] in prefs anyway.)
>> >
>> > --
>> > 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] Eeschema: add wildcard and regex support to component chooser

[Henner Zeller]

On 18 December 2015 at 21:33, Chris Pavlina <pavlina.ch...@gmail.com> wrote:
> I'm not going to argue about search methods, it'll suffice to say I
> disagree. I don't _want_ to search my library your way, and yes, I
> understand that it can work.
>
> I'm unconvinced that adding one option box is excessive complexity. It's
> not in the main UI, it's in the preferences dialog. What's wrong with
> preferences? Users can ignore those. Most do. Though the preferences
> dialog does need to be reorganized.

The problem is, that people don't find it. They get frustrated because
they want to search with regular expressions, but it doesn't work. And
they never find the option to set it.

If the dialog would do all matches in parallel and increases scores
for each matcher that triggers, then you get all the simple matching I
am proposing and all the extended regular expression searching that
you want. And it will work automatically without anyone ever setting
an option.

-h

>
>
> On Fri, Dec 18, 2015 at 09:19:54PM -0800, Henner Zeller wrote:
>> On 18 December 2015 at 20:16, Chris Pavlina <pavlina.ch...@gmail.com> wrote:
>> > As discussed earlier today, this patch adds support for both wildcard
>> > and regular expression search to the eeschema component chooser. An
>> > option is added to eeschema options to select the "Component search
>> > method", which defaults to "Simple" (the original behavior). Regular
>> > expression search was added as a "bonus", as it was used as a stepping
>> > stone to wildcard search.
>>
>> Cool, I'll try it.
>>
>> BUT: I am skeptical I must admit, as adding these features that are
>> undoublty more complicated for the non-software engineer to use and
>> also to choose from. More choices for the user to handle, and I am not
>> convinced yet that it is worth it.
>>
>> I would rather try to make the search as best as possible that a few
>> words will bring the result. If it doesn't, then the scoring function
>> needs to be tweaked. I am a big fan of simple user interfaces...
>>
>> Do you have some real world examples that are really hard to solve
>> with simple string-matching and scoring of the result as it is now
>> (the XMEGA example in the other thread can be done by just having a
>> space between the xmega and d3, so this is not really a good example).
>>
>> Having simple user interfaces is hugely important IMHO, so we should
>> add features and confusing user options only if the simple way of
>> dealing with it can't do it.
>>
>> -h
>>
>> >
>> > The existing behavior of Henner's component chooser wasn't changed, just
>> > the matching function it uses.
>> >
>> > Following Wayne's suggestion, an EDA_PATTERN_MATCH base class is defined
>> > in include/eda_pattern_match.h, and then:
>> >
>> > - EDA_PATTERN_MATCH_SUBSTR implements EDA_PATTERN_MATCH with the old
>> >   behavior
>> >
>> > - EDA_PATTERN_MATCH_REGEX implements EDA_PATTERN_MATCH providing regex
>> >   search via wxRegEx and wxRE_ADVANCED.
>> >
>> > - EDA_PATTERN_MATCH_WILDCARD extends EDA_PATTERN_MATCH_REGEX,
>> >   translating a wildcard string to a regular expression and then loading
>> >   it into the latter. This allows the nice, fast, wxString-compatible,
>> >   and well tested regex search to be reused for wildcard search.
>> >
>> > --
>> > 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] Eeschema: add wildcard and regex support to component chooser

[Henner Zeller]

On 18 December 2015 at 21:50, Chris Pavlina <pavlina.ch...@gmail.com> wrote:
> On Fri, Dec 18, 2015 at 09:40:29PM -0800, Henner Zeller wrote:
>> On 18 December 2015 at 21:33, Chris Pavlina <pavlina.ch...@gmail.com> wrote:
>> > I'm not going to argue about search methods, it'll suffice to say I
>> > disagree. I don't _want_ to search my library your way, and yes, I
>> > understand that it can work.
>> >
>> > I'm unconvinced that adding one option box is excessive complexity. It's
>> > not in the main UI, it's in the preferences dialog. What's wrong with
>> > preferences? Users can ignore those. Most do. Though the preferences
>> > dialog does need to be reorganized.
>>
>> The problem is, that people don't find it. They get frustrated because
>> they want to search with regular expressions, but it doesn't work. And
>> they never find the option to set it.
>
> Somehow I don't think that wildcard/regex search is going to be a big
> advertised feature that all the kids will be flocking to kicad for. I
> also doubt that the sort of person who would want it is the sort of
> person who couldn't be bothered to look at the options.
>
>>
>> If the dialog would do all matches in parallel and increases scores
>> for each matcher that triggers, then you get all the simple matching I
>> am proposing and all the extended regular expression searching that
>> you want. And it will work automatically without anyone ever setting
>> an option.
>
> Yes, and clutters up the results with false matches, just like searching
> for "ATXMEGA*D3" by typing "ATXMEGA D3" does.

But if you have all scoring functions engaged, the relevant come first.

>
> Seriously, what is it with this mailing list? Every time someone
> suggests a simple idea, everyone immediately piles on with their
> favorite way to overcomplicate it.

Calm down. I make suggestions to _simplify_, not complicate.

>
> I just suggested adding this because I thought it'd be a simple addition
> that might add some utility for some people. Never imagined wildcards
> could be so controversial.

As I said, I like wildcards and regexp and like to see them supported.
But I suggested way to support them automatically.

>Take it or leave it, I'm not going to keep
> revising it to make it more complex.

You don't have to. I can do that.

>
>>
>> -h
>>
>> >
>> >
>> > On Fri, Dec 18, 2015 at 09:19:54PM -0800, Henner Zeller wrote:
>> >> On 18 December 2015 at 20:16, Chris Pavlina <pavlina.ch...@gmail.com> 
>> >> wrote:
>> >> > As discussed earlier today, this patch adds support for both wildcard
>> >> > and regular expression search to the eeschema component chooser. An
>> >> > option is added to eeschema options to select the "Component search
>> >> > method", which defaults to "Simple" (the original behavior). Regular
>> >> > expression search was added as a "bonus", as it was used as a stepping
>> >> > stone to wildcard search.
>> >>
>> >> Cool, I'll try it.
>> >>
>> >> BUT: I am skeptical I must admit, as adding these features that are
>> >> undoublty more complicated for the non-software engineer to use and
>> >> also to choose from. More choices for the user to handle, and I am not
>> >> convinced yet that it is worth it.
>> >>
>> >> I would rather try to make the search as best as possible that a few
>> >> words will bring the result. If it doesn't, then the scoring function
>> >> needs to be tweaked. I am a big fan of simple user interfaces...
>> >>
>> >> Do you have some real world examples that are really hard to solve
>> >> with simple string-matching and scoring of the result as it is now
>> >> (the XMEGA example in the other thread can be done by just having a
>> >> space between the xmega and d3, so this is not really a good example).
>> >>
>> >> Having simple user interfaces is hugely important IMHO, so we should
>> >> add features and confusing user options only if the simple way of
>> >> dealing with it can't do it.
>> >>
>> >> -h
>> >>
>> >> >
>> >> > The existing behavior of Henner's component chooser wasn't changed, just
>> >> > the matching function it uses.
>> >> >
>> >> > Following Wayne's suggestion, an EDA_PATTERN_MATCH base class is defined
>> >> > in include/eda_

Re: [Kicad-developers] [PATCH] Eeschema: add wildcard and regex support to component chooser

[Henner Zeller]

On 18 December 2015 at 21:19, Henner Zeller <h.zel...@acm.org> wrote:
> On 18 December 2015 at 20:16, Chris Pavlina <pavlina.ch...@gmail.com> wrote:
>> As discussed earlier today, this patch adds support for both wildcard
>> and regular expression search to the eeschema component chooser. An
>> option is added to eeschema options to select the "Component search
>> method", which defaults to "Simple" (the original behavior). Regular
>> expression search was added as a "bonus", as it was used as a stepping
>> stone to wildcard search.
>
> Cool, I'll try it.
>
> BUT: I am skeptical I must admit, as adding these features that are
> undoublty more complicated for the non-software engineer to use and
> also to choose from. More choices for the user to handle, and I am not
> convinced yet that it is worth it.
>
> I would rather try to make the search as best as possible that a few
> words will bring the result. If it doesn't, then the scoring function
> needs to be tweaked. I am a big fan of simple user interfaces...
>
> Do you have some real world examples that are really hard to solve
> with simple string-matching and scoring of the result as it is now
> (the XMEGA example in the other thread can be done by just having a
> space between the xmega and d3, so this is not really a good example).
>
> Having simple user interfaces is hugely important IMHO, so we should
> add features and confusing user options only if the simple way of
> dealing with it can't do it.

One way for instance could be to have _all_ pattern matchers engaged
(some of them might not do anything because their patterns don't
engage or have parse errors), but if more than one matcher engages,
then this can be used as an endorsement for the scoring algorithm.

So to formalize: I am not opposed to better scoring (using additional
matchers), but by making the user interface more complicated with
options to choose (I seem somewhere in the patch that there is a new
choice box ?)
If I type Foo[0-9]bar, then automatically the regexp matcher will
generate a score for Foo7bar, but not the others, and it just works
automatically.
>
> -h
>
>>
>> The existing behavior of Henner's component chooser wasn't changed, just
>> the matching function it uses.
>>
>> Following Wayne's suggestion, an EDA_PATTERN_MATCH base class is defined
>> in include/eda_pattern_match.h, and then:
>>
>> - EDA_PATTERN_MATCH_SUBSTR implements EDA_PATTERN_MATCH with the old
>>   behavior
>>
>> - EDA_PATTERN_MATCH_REGEX implements EDA_PATTERN_MATCH providing regex
>>   search via wxRegEx and wxRE_ADVANCED.
>>
>> - EDA_PATTERN_MATCH_WILDCARD extends EDA_PATTERN_MATCH_REGEX,
>>   translating a wildcard string to a regular expression and then loading
>>   it into the latter. This allows the nice, fast, wxString-compatible,
>>   and well tested regex search to be reused for wildcard search.
>>
>> --
>> 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] Eeschema: add wildcard and regex support to component chooser

[Henner Zeller]

On 18 December 2015 at 20:16, Chris Pavlina  wrote:
> As discussed earlier today, this patch adds support for both wildcard
> and regular expression search to the eeschema component chooser. An
> option is added to eeschema options to select the "Component search
> method", which defaults to "Simple" (the original behavior). Regular
> expression search was added as a "bonus", as it was used as a stepping
> stone to wildcard search.

Cool, I'll try it.

BUT: I am skeptical I must admit, as adding these features that are
undoublty more complicated for the non-software engineer to use and
also to choose from. More choices for the user to handle, and I am not
convinced yet that it is worth it.

I would rather try to make the search as best as possible that a few
words will bring the result. If it doesn't, then the scoring function
needs to be tweaked. I am a big fan of simple user interfaces...

Do you have some real world examples that are really hard to solve
with simple string-matching and scoring of the result as it is now
(the XMEGA example in the other thread can be done by just having a
space between the xmega and d3, so this is not really a good example).

Having simple user interfaces is hugely important IMHO, so we should
add features and confusing user options only if the simple way of
dealing with it can't do it.

-h

>
> The existing behavior of Henner's component chooser wasn't changed, just
> the matching function it uses.
>
> Following Wayne's suggestion, an EDA_PATTERN_MATCH base class is defined
> in include/eda_pattern_match.h, and then:
>
> - EDA_PATTERN_MATCH_SUBSTR implements EDA_PATTERN_MATCH with the old
>   behavior
>
> - EDA_PATTERN_MATCH_REGEX implements EDA_PATTERN_MATCH providing regex
>   search via wxRegEx and wxRE_ADVANCED.
>
> - EDA_PATTERN_MATCH_WILDCARD extends EDA_PATTERN_MATCH_REGEX,
>   translating a wildcard string to a regular expression and then loading
>   it into the latter. This allows the nice, fast, wxString-compatible,
>   and well tested regex search to be reused for wildcard search.
>
> --
> 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] Eeschema: add wildcard and regex support to component chooser

[Henner Zeller]

On 18 December 2015 at 21:57, Henner Zeller <h.zel...@acm.org> wrote:
> On 18 December 2015 at 21:50, Chris Pavlina <pavlina.ch...@gmail.com> wrote:
>> On Fri, Dec 18, 2015 at 09:40:29PM -0800, Henner Zeller wrote:
>>> On 18 December 2015 at 21:33, Chris Pavlina <pavlina.ch...@gmail.com> wrote:
>>> > I'm not going to argue about search methods, it'll suffice to say I
>>> > disagree. I don't _want_ to search my library your way, and yes, I
>>> > understand that it can work.
>>> >
>>> > I'm unconvinced that adding one option box is excessive complexity. It's
>>> > not in the main UI, it's in the preferences dialog. What's wrong with
>>> > preferences? Users can ignore those. Most do. Though the preferences
>>> > dialog does need to be reorganized.
>>>
>>> The problem is, that people don't find it. They get frustrated because
>>> they want to search with regular expressions, but it doesn't work. And
>>> they never find the option to set it.
>>
>> Somehow I don't think that wildcard/regex search is going to be a big
>> advertised feature that all the kids will be flocking to kicad for. I
>> also doubt that the sort of person who would want it is the sort of
>> person who couldn't be bothered to look at the options.
>>
>>>
>>> If the dialog would do all matches in parallel and increases scores
>>> for each matcher that triggers, then you get all the simple matching I
>>> am proposing and all the extended regular expression searching that
>>> you want. And it will work automatically without anyone ever setting
>>> an option.
>>
>> Yes, and clutters up the results with false matches, just like searching
>> for "ATXMEGA*D3" by typing "ATXMEGA D3" does.
>
> But if you have all scoring functions engaged, the relevant come first.
>
>>
>> Seriously, what is it with this mailing list? Every time someone
>> suggests a simple idea, everyone immediately piles on with their
>> favorite way to overcomplicate it.
>
> Calm down. I make suggestions to _simplify_, not complicate.
>
>>
>> I just suggested adding this because I thought it'd be a simple addition
>> that might add some utility for some people. Never imagined wildcards
>> could be so controversial.
>
> As I said, I like wildcards and regexp and like to see them supported.
> But I suggested way to support them automatically.
>
>>Take it or leave it, I'm not going to keep
>> revising it to make it more complex.
>
> You don't have to. I can do that.

Attached, the simplified patch, using your new matchers:

   * Uses all your matchers, but does not need to have the factory.
   * No need for extra code to add option for users.
   * Same effect. People can use any syntax they want and get matches
accordingly.
   * It is very unlikely to get unwanted results.
   * Less code (366 vs 833 loc)
   * More user friendly to use (no search for obscure options, if
someone uses FOO*BAR or a regexp it just works as expected).

-h

>
>>
>>>
>>> -h
>>>
>>> >
>>> >
>>> > On Fri, Dec 18, 2015 at 09:19:54PM -0800, Henner Zeller wrote:
>>> >> On 18 December 2015 at 20:16, Chris Pavlina <pavlina.ch...@gmail.com> 
>>> >> wrote:
>>> >> > As discussed earlier today, this patch adds support for both wildcard
>>> >> > and regular expression search to the eeschema component chooser. An
>>> >> > option is added to eeschema options to select the "Component search
>>> >> > method", which defaults to "Simple" (the original behavior). Regular
>>> >> > expression search was added as a "bonus", as it was used as a stepping
>>> >> > stone to wildcard search.
>>> >>
>>> >> Cool, I'll try it.
>>> >>
>>> >> BUT: I am skeptical I must admit, as adding these features that are
>>> >> undoublty more complicated for the non-software engineer to use and
>>> >> also to choose from. More choices for the user to handle, and I am not
>>> >> convinced yet that it is worth it.
>>> >>
>>> >> I would rather try to make the search as best as possible that a few
>>> >> words will bring the result. If it doesn't, then the scoring function
>>> >> needs to be tweaked. I am a big fan of simple user interfaces...
>>> >>
>>> >> Do you have some real world examples that are really hard to solve
>>&

Re: [Kicad-developers] Bug: ThrowIOError with GetChars() formatting parameter

[Henner Zeller]

I now replaced the calls with wxString::Format() which is proven to
work reliably.
(see separate mail 'Patch: fix string formatting in ThrowIOError')

On 9 December 2015 at 09:15, Henner Zeller <h.zel...@acm.org> wrote:
> On 9 December 2015 at 17:18, Wayne Stambaugh <stambau...@gmail.com> wrote:
>> On 12/6/2015 8:34 PM, Henner Zeller wrote:
>>> On 4 December 2015 at 07:17, jp charras <jp.char...@wanadoo.fr> wrote:
>>>> Le 04/12/2015 14:54, Wayne Stambaugh a écrit :
>>>>> Thanks Henner.  I'll take a look at it when I get a chance.  I'm sure
>>>>> this isn't the only place this pattern is used.  If you have a patch,
>>>>> please submit it.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Wayne
>>>>>
>>>>> On 12/3/2015 3:46 AM, Henner Zeller wrote:
>>>>>> Hi,
>>>>>> Playing with the spectra import/export, I encountered a bug: in that
>>>>>> code are constructs such as
>>>>>>
>>>>>>ThrowIOError( _("some formatting %s"), GetChars( someWxString ));
>>>>>>
>>>>>> They are ultimately dealt with wxString::PrintfV( fmt, args );
>>>>>>
>>>>>> The output, however, is not as expected. A someWxString with "REF**"
>>>>>> was only displayed as "R". Changing the GetChars() to TO_UTF8() works.
>>>>>>
>>>>>> I suspect that whatever is returned by GetChars() is not properly
>>>>>> passed through the var-args argument, while the simple const char* of
>>>>>> TO_UTF8() does work. I am not sure though if that is the 'right'
>>>>>> solution as this might be different on Windows ? So I'll leave this to
>>>>>> someone more knowledgeable in wxString quirks on different platforms
>>>>
>>>> @Henner,
>>>>
>>>> GetChars is a macro (defined in macros.h)
>>>> It returns a wxChar*, which is the right type here.
>>>>
>>>> (GetChars was written to be equivalent to GetData(), during the time
>>>> GetData(), needed when using wxString::Print(), was removed from
>>>> wxWidgets, in a few 2.9.x versions)
>>>>
>>>> - How to reproduce this issue (it can be different on Linux and on 
>>>> Windows)?
>>>
>>> I don't have access to a windows machine to test, but I created a
>>> simplified code in
>>>https://gist.github.com/hzeller/e377cc8be916b191d499
>>> so that it can be tested and re-produced by others.
>>>
>>> This is the output:
>>> $ g++ -Wall -o format-test -isystem
>>> /usr/lib/x86_64-linux-gnu/wx/include/gtk2-unicode-3.0 -isystem
>>> /usr/include/wx-3.0 -D__WXGTK__ format-test.cpp
>>> -L/usr/lib/x86_64-linux-gnu/ -lwx_baseu-3.0 && ./format-test
>>> Input: format:'this is a test >%s<' and value:'SomeTest value'
>>> sizeof(wxChar) = 4
>>> wxstring::PrintfV(fmt, GetChars())  : 'this is a test >S<'
>>> wxstring::PrintfV(fmt, value.GetData())  : 'this is a test >'
>>> wxstring::PrintfV(fmt, TO_UTF8())   : 'this is a test >SomeTest value<'
>>> wxstring::Printf(fmt, wxstring) : 'this is a test >SomeTest value<'
>>> wxstring::Printf(fmt, GetChars(...)): 'this is a test >SomeTest value<'
>>> wxstring::Printf(fmt, TO_UTF8(..))  : 'this is a test >SomeTest value<'
>>>
>>> So findings
>>>   - using the PrintfV() with TO_UTF8() works (on my machine).
>>>   - GetChars() only prints the first character, then stops (I presume
>>> because that points to a multi-byte string, which has \0 every other
>>> character but then is interpreted as const char* ?)
>>>   - GetData() is worse.
>>>   - wxstring::Printf() seems to work with whatever is thrown at it.
>>>
>>>> - What happens if you replace GetChars( someWxString ) by
>>>> someWxString.GetData()?
>>>
>>> Second output above: it totally messes up the output.
>>>
>>> (this is on debian testing with wx 3.0)
>>>
>>
>> I cannot even get it to build on msys1/mingw32 (gcc 4.7.2).  I get the
>> following error:
>>
>> format-test.cpp:39:85: error: cannot pass objects of
>> non-trivially-copyable type 'const class wxCStrData' through '...'
>
> I was surprised that that compiles as well :) Maybe it is due to the
> newer compiler on debian testing that does something magic ?
> On my ubu

[Kicad-developers] Patch: fix string formatting in ThrowIOError

[Henner Zeller]

Hi,
Since the current implementation of formatting IO errors is not
working platform independently (see mail thread 'Bug: ThrowIOError
with GetChars() formatting parameter'), replaced these calls
with the working wxString::Format().

Commit message:
   o Replace questionable wxString::PrintfV() call (which doesn't work
 reliably on different platforms) with wxString::Format()
   o Extra win: due to use now of the THROW_IO_ERROR() macro, error messages
 contain line numbers.

Patch:
https://github.com/KiCad/kicad-source-mirror/compare/master...hzeller:avoid-wxstring-printfv.diff

Cheers,
  Henner.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bug: ThrowIOError with GetChars() formatting parameter

[Henner Zeller]

On 9 December 2015 at 17:18, Wayne Stambaugh <stambau...@gmail.com> wrote:
> On 12/6/2015 8:34 PM, Henner Zeller wrote:
>> On 4 December 2015 at 07:17, jp charras <jp.char...@wanadoo.fr> wrote:
>>> Le 04/12/2015 14:54, Wayne Stambaugh a écrit :
>>>> Thanks Henner.  I'll take a look at it when I get a chance.  I'm sure
>>>> this isn't the only place this pattern is used.  If you have a patch,
>>>> please submit it.
>>>>
>>>> Thanks,
>>>>
>>>> Wayne
>>>>
>>>> On 12/3/2015 3:46 AM, Henner Zeller wrote:
>>>>> Hi,
>>>>> Playing with the spectra import/export, I encountered a bug: in that
>>>>> code are constructs such as
>>>>>
>>>>>ThrowIOError( _("some formatting %s"), GetChars( someWxString ));
>>>>>
>>>>> They are ultimately dealt with wxString::PrintfV( fmt, args );
>>>>>
>>>>> The output, however, is not as expected. A someWxString with "REF**"
>>>>> was only displayed as "R". Changing the GetChars() to TO_UTF8() works.
>>>>>
>>>>> I suspect that whatever is returned by GetChars() is not properly
>>>>> passed through the var-args argument, while the simple const char* of
>>>>> TO_UTF8() does work. I am not sure though if that is the 'right'
>>>>> solution as this might be different on Windows ? So I'll leave this to
>>>>> someone more knowledgeable in wxString quirks on different platforms
>>>
>>> @Henner,
>>>
>>> GetChars is a macro (defined in macros.h)
>>> It returns a wxChar*, which is the right type here.
>>>
>>> (GetChars was written to be equivalent to GetData(), during the time
>>> GetData(), needed when using wxString::Print(), was removed from
>>> wxWidgets, in a few 2.9.x versions)
>>>
>>> - How to reproduce this issue (it can be different on Linux and on Windows)?
>>
>> I don't have access to a windows machine to test, but I created a
>> simplified code in
>>https://gist.github.com/hzeller/e377cc8be916b191d499
>> so that it can be tested and re-produced by others.
>>
>> This is the output:
>> $ g++ -Wall -o format-test -isystem
>> /usr/lib/x86_64-linux-gnu/wx/include/gtk2-unicode-3.0 -isystem
>> /usr/include/wx-3.0 -D__WXGTK__ format-test.cpp
>> -L/usr/lib/x86_64-linux-gnu/ -lwx_baseu-3.0 && ./format-test
>> Input: format:'this is a test >%s<' and value:'SomeTest value'
>> sizeof(wxChar) = 4
>> wxstring::PrintfV(fmt, GetChars())  : 'this is a test >S<'
>> wxstring::PrintfV(fmt, value.GetData())  : 'this is a test >'
>> wxstring::PrintfV(fmt, TO_UTF8())   : 'this is a test >SomeTest value<'
>> wxstring::Printf(fmt, wxstring) : 'this is a test >SomeTest value<'
>> wxstring::Printf(fmt, GetChars(...)): 'this is a test >SomeTest value<'
>> wxstring::Printf(fmt, TO_UTF8(..))  : 'this is a test >SomeTest value<'
>>
>> So findings
>>   - using the PrintfV() with TO_UTF8() works (on my machine).
>>   - GetChars() only prints the first character, then stops (I presume
>> because that points to a multi-byte string, which has \0 every other
>> character but then is interpreted as const char* ?)
>>   - GetData() is worse.
>>   - wxstring::Printf() seems to work with whatever is thrown at it.
>>
>>> - What happens if you replace GetChars( someWxString ) by
>>> someWxString.GetData()?
>>
>> Second output above: it totally messes up the output.
>>
>> (this is on debian testing with wx 3.0)
>>
>
> I cannot even get it to build on msys1/mingw32 (gcc 4.7.2).  I get the
> following error:
>
> format-test.cpp:39:85: error: cannot pass objects of
> non-trivially-copyable type 'const class wxCStrData' through '...'

I was surprised that that compiles as well :) Maybe it is due to the
newer compiler on debian testing that does something magic ?
On my ubuntu laptop with g++ 4.9.1, it doesn't compile that line
either. But commenting that out, it shows the same output than on the
other Linux machines.

>
> Here is the output using msys2/mingw32 wxWidgets 3.0.2:
>
> Input: format:'this is a test >%s<' and value:'SomeTest value'
> sizeof(wxChar) = zd
> wxstring::PrintfV(fmt, GetChars())  : 'this is a test >SomeTest value<'
> wxstring::PrintfV(fmt, value.GetData())  : 'this is a test >�(<'
> wxstring::PrintfV(fmt, TO_UTF8())   : 'this is a test >潓敭敔瑳瘠污敵<'
> wxstring::Printf(fmt

Re: [Kicad-developers] Eeschema refactor.

[Henner Zeller]

Hi Wayne,
Do you have a todo-list somewhere on the things you intend to work on
? I think everyone on this list has a rough idea of TODOs they want to
work on (I know I do, but I only have limited time), but if we put
them somewhere easy to manage (maybe even the bugtracker, but I think
it sucks big time), then this might be good.

On 8 December 2015 at 15:58, Wayne Stambaugh  wrote:
> Yesterday I committed the first of a series of patches that are part of
> the Eeschema refactor work.  As of right now I have 41 patches queued up
> with more to come.

Wow, that sounds prolific!

>  I will apply them slowly over the next few months
> just in case I managed to break anything.  The first few patches should
> be pretty benign but as time goes by, they will have the potential to
> become more disruptive.  If you find anything that is broken, please let
> me know right away so I can get it fixed.  You should be able to see a
> pattern pretty quickly with the first few patches.  I will slowly roll
> the functionality of SCH_SHEET_PATH, SCH_SHEET_LIST, and SCH_SCREENS
> into the SCH_SHEET object where the entire schematic hierarchy will
> live.  Once that is complete, I will create a top level SCHEMATIC object
> that will act as the top level container similar in scope to the BOARD
> object in Pcbnew.

Nice!

>  Hopefully this transition will be fairly smooth so I
> can start on the schematic I/O manager and the new file formats sometime
> later this year.
>
> ___
> 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: fix Python demo script to call SetOptions()

[Henner Zeller]

Hi,
Recently, the mergeNPTH option was removed, then re-added to the
Python implementation of the EXCELLON_WRITER.
The demo script did not keep up with that :)

Find patch here:

https://github.com/KiCad/kicad-source-mirror/compare/master...hzeller:fix-demo-python-script-setoptions.diff

-henner

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bug: ThrowIOError with GetChars() formatting parameter

[Henner Zeller]

On 4 December 2015 at 07:17, jp charras <jp.char...@wanadoo.fr> wrote:
> Le 04/12/2015 14:54, Wayne Stambaugh a écrit :
>> Thanks Henner.  I'll take a look at it when I get a chance.  I'm sure
>> this isn't the only place this pattern is used.  If you have a patch,
>> please submit it.
>>
>> Thanks,
>>
>> Wayne
>>
>> On 12/3/2015 3:46 AM, Henner Zeller wrote:
>>> Hi,
>>> Playing with the spectra import/export, I encountered a bug: in that
>>> code are constructs such as
>>>
>>>ThrowIOError( _("some formatting %s"), GetChars( someWxString ));
>>>
>>> They are ultimately dealt with wxString::PrintfV( fmt, args );
>>>
>>> The output, however, is not as expected. A someWxString with "REF**"
>>> was only displayed as "R". Changing the GetChars() to TO_UTF8() works.
>>>
>>> I suspect that whatever is returned by GetChars() is not properly
>>> passed through the var-args argument, while the simple const char* of
>>> TO_UTF8() does work. I am not sure though if that is the 'right'
>>> solution as this might be different on Windows ? So I'll leave this to
>>> someone more knowledgeable in wxString quirks on different platforms
>
> @Henner,
>
> GetChars is a macro (defined in macros.h)
> It returns a wxChar*, which is the right type here.
>
> (GetChars was written to be equivalent to GetData(), during the time
> GetData(), needed when using wxString::Print(), was removed from
> wxWidgets, in a few 2.9.x versions)
>
> - How to reproduce this issue (it can be different on Linux and on Windows)?

I don't have access to a windows machine to test, but I created a
simplified code in
   https://gist.github.com/hzeller/e377cc8be916b191d499
so that it can be tested and re-produced by others.

This is the output:
$ g++ -Wall -o format-test -isystem
/usr/lib/x86_64-linux-gnu/wx/include/gtk2-unicode-3.0 -isystem
/usr/include/wx-3.0 -D__WXGTK__ format-test.cpp
-L/usr/lib/x86_64-linux-gnu/ -lwx_baseu-3.0 && ./format-test
Input: format:'this is a test >%s<' and value:'SomeTest value'
sizeof(wxChar) = 4
wxstring::PrintfV(fmt, GetChars())  : 'this is a test >S<'
wxstring::PrintfV(fmt, value.GetData())  : 'this is a test >'
wxstring::PrintfV(fmt, TO_UTF8())   : 'this is a test >SomeTest value<'
wxstring::Printf(fmt, wxstring) : 'this is a test >SomeTest value<'
wxstring::Printf(fmt, GetChars(...)): 'this is a test >SomeTest value<'
wxstring::Printf(fmt, TO_UTF8(..))  : 'this is a test >SomeTest value<'

So findings
  - using the PrintfV() with TO_UTF8() works (on my machine).
  - GetChars() only prints the first character, then stops (I presume
because that points to a multi-byte string, which has \0 every other
character but then is interpreted as const char* ?)
  - GetData() is worse.
  - wxstring::Printf() seems to work with whatever is thrown at it.

> - What happens if you replace GetChars( someWxString ) by
> someWxString.GetData()?

Second output above: it totally messes up the output.

(this is on debian testing with wx 3.0)

-h
>
> --
> Jean-Pierre CHARRAS
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] ancient autorouter code

[Henner Zeller]

On 31 July 2015 at 08:47, Wayne Stambaugh  wrote:
> I'm confused, are we talking about the freerouting.net link or KiCad's
> internal autorouter?  If the link to freerouting.net is still active, it
> should be removed from KiCad since it is no longer active.  I thought
> this was removed already.

I had a look: the freeroute program still exists, but it is now a GNU
licenced code out there ( https://github.com/nikropht/FreeRouting ) -
it is possible to run as standalone on your computer.

>From what it looks like, there was an online version available that
doesn't exist anymore, so the button 'Export ... and launch Freeroute'
should probably be removed (or the FreeRouting program hacked so that
it can run as a daemon listening on a socket for a local network
service).

So for Kicad
  - remove the middle button in the Free-Route dialog that sends it to
the external router
 - The menu button 'Freeroute' should be renamed 'External routing
(Specctra export)' or something, so that it is more neutral.

-h
> On 7/31/2015 10:51 AM, Al Thomason wrote:
>> Is this still the link to: http://www.freerouting.net/  ?
>>
>> If so, there was some CnD letters as well as perhaps other problems for the
>> author - in the end, this resource has been taken off-line.  See above URL
>> for more details.
>>
>> -al-
>>
>>
>> -Original Message-
>> From: Kicad-developers
>> [mailto:kicad-developers-bounces+thomason.al=gmail@lists.launchpad.net]
>> On Behalf Of Wayne Stambaugh
>> Sent: Friday, July 31, 2015 5:36 AM
>> To: kicad-developers@lists.launchpad.net
>> Subject: Re: [Kicad-developers] ancient autorouter code
>>
>> I haven't used the autorouter in a long time but it should still function
>> properly despite it's limited usefulness.  I see no reason to remove it for
>> the stable release unless it is completely broken.  For some really simple
>> boards it still may be useful.
>>
>> On 7/30/2015 8:52 PM, Cirilo Bernardo wrote:
>>> As long as I can remember the docs have mentioned a built-in autorouter.
>>> For just as long I've never been aware of anyone using it or improving
>>> the code. Could we kill this before a stable release?
>>>
>>> - Cirilo
>>
>>
>>
>> ___
>> 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] ancient autorouter code

[Henner Zeller]

On 6 December 2015 at 20:58, Adam Wolf <adamw...@feelslikeburning.com> wrote:
> I believe that there was integration done so that if you click the
> autorouter button, it tells you in the status bar to put the jar in a
> certain path, at which point the button works like it did before--actually,
> a little better, because for some reason Java remembers the path and I don't
> need to browse to the project every time I open it up.

That would indeed be good, as the file browser is pretty annoying that way.

Sounds like documentation would be good somewhere. Does anyone know
how this is supposed to work ?
(I recently had a small throwaway board where I didn't mind a crappy
autorouter result).

-h

>
> I don't remember when this was but this was after the online service went
> down.
>
> Adam Wolf
>
> On Sun, Dec 6, 2015 at 5:04 PM, Henner Zeller <h.zel...@acm.org> wrote:
>>
>> On 31 July 2015 at 08:47, Wayne Stambaugh <stambau...@gmail.com> wrote:
>> > I'm confused, are we talking about the freerouting.net link or KiCad's
>> > internal autorouter?  If the link to freerouting.net is still active, it
>> > should be removed from KiCad since it is no longer active.  I thought
>> > this was removed already.
>>
>> I had a look: the freeroute program still exists, but it is now a GNU
>> licenced code out there ( https://github.com/nikropht/FreeRouting ) -
>> it is possible to run as standalone on your computer.
>>
>> From what it looks like, there was an online version available that
>> doesn't exist anymore, so the button 'Export ... and launch Freeroute'
>> should probably be removed (or the FreeRouting program hacked so that
>> it can run as a daemon listening on a socket for a local network
>> service).
>>
>> So for Kicad
>>   - remove the middle button in the Free-Route dialog that sends it to
>> the external router
>>  - The menu button 'Freeroute' should be renamed 'External routing
>> (Specctra export)' or something, so that it is more neutral.
>>
>> -h
>> > On 7/31/2015 10:51 AM, Al Thomason wrote:
>> >> Is this still the link to: http://www.freerouting.net/  ?
>> >>
>> >> If so, there was some CnD letters as well as perhaps other problems for
>> >> the
>> >> author - in the end, this resource has been taken off-line.  See above
>> >> URL
>> >> for more details.
>> >>
>> >> -al-
>> >>
>> >>
>> >> -Original Message-
>> >> From: Kicad-developers
>> >>
>> >> [mailto:kicad-developers-bounces+thomason.al=gmail@lists.launchpad.net]
>> >> On Behalf Of Wayne Stambaugh
>> >> Sent: Friday, July 31, 2015 5:36 AM
>> >> To: kicad-developers@lists.launchpad.net
>> >> Subject: Re: [Kicad-developers] ancient autorouter code
>> >>
>> >> I haven't used the autorouter in a long time but it should still
>> >> function
>> >> properly despite it's limited usefulness.  I see no reason to remove it
>> >> for
>> >> the stable release unless it is completely broken.  For some really
>> >> simple
>> >> boards it still may be useful.
>> >>
>> >> On 7/30/2015 8:52 PM, Cirilo Bernardo wrote:
>> >>> As long as I can remember the docs have mentioned a built-in
>> >>> autorouter.
>> >>> For just as long I've never been aware of anyone using it or improving
>> >>> the code. Could we kill this before a stable release?
>> >>>
>> >>> - Cirilo
>> >>
>> >>
>> >>
>> >> ___
>> >> 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] Bug: ThrowIOError with GetChars() formatting parameter

[Henner Zeller]

Hi,
Playing with the spectra import/export, I encountered a bug: in that
code are constructs such as

   ThrowIOError( _("some formatting %s"), GetChars( someWxString ));

They are ultimately dealt with wxString::PrintfV( fmt, args );

The output, however, is not as expected. A someWxString with "REF**"
was only displayed as "R". Changing the GetChars() to TO_UTF8() works.

I suspect that whatever is returned by GetChars() is not properly
passed through the var-args argument, while the simple const char* of
TO_UTF8() does work. I am not sure though if that is the 'right'
solution as this might be different on Windows ? So I'll leave this to
someone more knowledgeable in wxString quirks on different platforms
...

-h

___
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] 3D-Viewer Raytraced render

[Henner Zeller]

On 27 October 2015 at 15:27, Mário Luzeiro  wrote:
> Hello all,
>
> I would like to show you some screenshots of the progress of a 3d-viewer 
> render based on raytracing (with some vitamins) that I am working on:
> https://meocloud.pt/link/aaf06e3f-e308-40c8-bddb-f8aa762b4a16/20151027_3d-viewer/
> (please download the file image if you want see it in full resolution)
>
> To keep this email short, I will not add details, please feel free to make 
> any questions.
>
> There are (at moment) two modes of rendering: preview (while moving) or 
> quality rendering. In preview mode it render a fast draft  in order to get 
> some interactive framerate while adjusting the view of the board. So the 
> screenshots label as 'preview' shows it to compare draft/quality.
>
> The quality rendering time.. depends on how many CPUs you have and (special) 
> how fast your cache is. In my laptop, 8 cpu processor, it can take longer 
> than a eye blink.. ..probably two or three eye blinks.
>
> If you would like to try it in your machine, you can try built my branch:
> https://code.launchpad.net/~mrluzeiro/kicad/kicad_new3d-viewer
> (probably have issues to build on windows)

This is great news. My machine doesn't have a working GPU (iMac5k GPU
is not supported yet by the AMD Linux driver), so I am looking forward
trying out your branch for a faster and also improved viewing
experience.

>
> There are still lot of room for improvements, ideas and things to do ... 
> special, add of 3D models (Cirilo is working on path, plugins and cache of 
> models, I plan to start next working on a parser or adding some support to 
> display the 3D models by the render... )
>
> I would welcome anyone interested in this areas to join us to speed up the 
> development or add a little more of improvements.
>
> Cheers,
> Mario Luzeiro
>
> ___
> 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: make handling of SetUseGerberExtensions() work

[Henner Zeller]

On 20 October 2015 at 11:34, jp charras <jp.char...@wanadoo.fr> wrote:
> Le 20/10/2015 06:45, Henner Zeller a écrit :
>> Hi,
>> When setting the SetUseGerberExtensions() in python, the choice was
>> not honored. This is fixing it.
>>
>> Suggested commit message:
>> Fix Plotcontroller to make SetUseGerberExtensions() work as expected.
>>
>> Find patch here:
>> https://github.com/hzeller/kicad/compare/master...hzeller:fix-usegerberextension-scripting.diff
>>
>> -h
>
> Thanks.
>
> I committed a fix derived from your patch, among other fixes in rev 6272.
>
> Can you test it ?

Yes it works, thanks!

I noticed that you internally renamed the GetGerberExtension() to
GetGerberProtelExtension(). I think this is a much better name and
less confusing. It also makes it easier to relate the UI (which talks
about Protel).

I think we should go a step further while it doesn't hurt too much yet:
Given that we haven't released it too much yet to the public (well the
users are probably limited), I think there is a good opportunity _now_
that we also rename the external API for the plot properties:
{Set,Get}UseGerberExtensions() to {Set,Get}UseGerberProtelExtensions().

The name 'GerberExtensions' is very ambiguous and it is not very clear
what they mean (I would've assumed just *.gbr when reading it), while
ProtelExtension would be very specific and clear.

(We might keep the {Set,Get}UseGerberExtensions() functions at first
in the Python API, but output a loud warning that the name changed,
and remove it entirely soon).

WDYT ?
-h

>
>
> --
> 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: make handling of SetUseGerberExtensions() work

[Henner Zeller]

On 20 October 2015 at 13:17, Nick Østergaard <oe.n...@gmail.com> wrote:
> I think the proposed naming makes sense. I don't think we need to mark
> it as deprecated, we could just remove it. I have not heard of a lot
> of users that have discovered the python API, so I think the impact of
> removing it when we have not yet made the stable release yet is very
> limited.

Also, it didn't work since JP submitted the patch :) So, yes, we should
probably rename it immediately with no deprecation period.

> But if you wan to have a go with trying out how to warn about
> deprecated funtions, go ahead. That is just my personal comment on
> this matter.
>
> 2015-10-20 21:39 GMT+02:00 Henner Zeller <h.zel...@acm.org>:
>> On 20 October 2015 at 11:34, jp charras <jp.char...@wanadoo.fr> wrote:
>>> Le 20/10/2015 06:45, Henner Zeller a écrit :
>>>> Hi,
>>>> When setting the SetUseGerberExtensions() in python, the choice was
>>>> not honored. This is fixing it.
>>>>
>>>> Suggested commit message:
>>>> Fix Plotcontroller to make SetUseGerberExtensions() work as expected.
>>>>
>>>> Find patch here:
>>>> https://github.com/hzeller/kicad/compare/master...hzeller:fix-usegerberextension-scripting.diff
>>>>
>>>> -h
>>>
>>> Thanks.
>>>
>>> I committed a fix derived from your patch, among other fixes in rev 6272.
>>>
>>> Can you test it ?
>>
>> Yes it works, thanks!
>>
>> I noticed that you internally renamed the GetGerberExtension() to
>> GetGerberProtelExtension(). I think this is a much better name and
>> less confusing. It also makes it easier to relate the UI (which talks
>> about Protel).
>>
>> I think we should go a step further while it doesn't hurt too much yet:
>> Given that we haven't released it too much yet to the public (well the
>> users are probably limited), I think there is a good opportunity _now_
>> that we also rename the external API for the plot properties:
>> {Set,Get}UseGerberExtensions() to {Set,Get}UseGerberProtelExtensions().
>>
>> The name 'GerberExtensions' is very ambiguous and it is not very clear
>> what they mean (I would've assumed just *.gbr when reading it), while
>> ProtelExtension would be very specific and clear.
>>
>> (We might keep the {Set,Get}UseGerberExtensions() functions at first
>> in the Python API, but output a loud warning that the name changed,
>> and remove it entirely soon).
>>
>> WDYT ?
>> -h
>>
>>>
>>>
>>> --
>>> Jean-Pierre CHARRAS
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
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: make handling of SetUseGerberExtensions() work

[Henner Zeller]

On 20 October 2015 at 13:49, Henner Zeller <h.zel...@acm.org> wrote:
> On 20 October 2015 at 13:17, Nick Østergaard <oe.n...@gmail.com> wrote:
>> I think the proposed naming makes sense. I don't think we need to mark
>> it as deprecated, we could just remove it. I have not heard of a lot
>> of users that have discovered the python API, so I think the impact of
>> removing it when we have not yet made the stable release yet is very
>> limited.
>
> Also, it didn't work since JP submitted the patch :) So, yes, we should
> probably rename it immediately with no deprecation period.

Ok, suggested patch here:

https://github.com/hzeller/kicad/compare/master...hzeller:rename-to-protel-extensions.diff

Also includes a call to set this property in the sample script, so
that it is discoverable (with value 'False',
so behavior of existing script doesn't change).

Suggested commit message:

Rename {Set,Get}GerberExtensions() to {Set,Get}GerberProtelExtensions()
in public API.


-h

>
>> But if you wan to have a go with trying out how to warn about
>> deprecated funtions, go ahead. That is just my personal comment on
>> this matter.
>>
>> 2015-10-20 21:39 GMT+02:00 Henner Zeller <h.zel...@acm.org>:
>>> On 20 October 2015 at 11:34, jp charras <jp.char...@wanadoo.fr> wrote:
>>>> Le 20/10/2015 06:45, Henner Zeller a écrit :
>>>>> Hi,
>>>>> When setting the SetUseGerberExtensions() in python, the choice was
>>>>> not honored. This is fixing it.
>>>>>
>>>>> Suggested commit message:
>>>>> Fix Plotcontroller to make SetUseGerberExtensions() work as expected.
>>>>>
>>>>> Find patch here:
>>>>> https://github.com/hzeller/kicad/compare/master...hzeller:fix-usegerberextension-scripting.diff
>>>>>
>>>>> -h
>>>>
>>>> Thanks.
>>>>
>>>> I committed a fix derived from your patch, among other fixes in rev 6272.
>>>>
>>>> Can you test it ?
>>>
>>> Yes it works, thanks!
>>>
>>> I noticed that you internally renamed the GetGerberExtension() to
>>> GetGerberProtelExtension(). I think this is a much better name and
>>> less confusing. It also makes it easier to relate the UI (which talks
>>> about Protel).
>>>
>>> I think we should go a step further while it doesn't hurt too much yet:
>>> Given that we haven't released it too much yet to the public (well the
>>> users are probably limited), I think there is a good opportunity _now_
>>> that we also rename the external API for the plot properties:
>>> {Set,Get}UseGerberExtensions() to {Set,Get}UseGerberProtelExtensions().
>>>
>>> The name 'GerberExtensions' is very ambiguous and it is not very clear
>>> what they mean (I would've assumed just *.gbr when reading it), while
>>> ProtelExtension would be very specific and clear.
>>>
>>> (We might keep the {Set,Get}UseGerberExtensions() functions at first
>>> in the Python API, but output a loud warning that the name changed,
>>> and remove it entirely soon).
>>>
>>> WDYT ?
>>> -h
>>>
>>>>
>>>>
>>>> --
>>>> Jean-Pierre CHARRAS
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp

___
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: make handling of SetUseGerberExtensions() work

[Henner Zeller]

Hi,
When setting the SetUseGerberExtensions() in python, the choice was
not honored. This is fixing it.

Suggested commit message:
Fix Plotcontroller to make SetUseGerberExtensions() work as expected.

Find patch here:
https://github.com/hzeller/kicad/compare/master...hzeller:fix-usegerberextension-scripting.diff

-h

___
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] Call for help, no programming experience required.

[Henner Zeller]

On 1 October 2015 at 13:15, Chris Pavlina  wrote:
> It's a right shame we don't have any standalone project archive format that
> holds *everything*. That would be *very* useful for this sort of thing, as
> well as just generally making sure projects can always be opened.
>
> I wonder if there is any developer interest in that besides me. It's
> definitely on my list of things I'd like to work on post-release,

+1 that is definitely something to be considered.

> but I
> don't have much time lately...
>
> On Oct 1, 2015 3:52 PM, "nnn"  wrote:
>>
>> Why not to add 3d files (from some old revision of library) to projects
>> folder and use paths relative to KIPRJMOD? If demos will refer to some
>> special revision of library with 3d models they will break each time the
>> models are moved or renamed.
>>
>>
>> W dniu 01.10.2015 o 16:20, Wayne Stambaugh pisze:
>>>
>>> I just committed a fix for broken 3D model link in the interf_u demo
>>> https://bugs.launchpad.net/kicad/+bug/1500956.  While I was at it, I
>>> looked at the rest of the demos that have board files and they are
>>> broken (one partially) as well.  Here is an opportunity for someone to
>>> help out the project and no programming experience is require.  All you
>>> need to know is how to associate 3D models with footprints in Pcbnew and
>>> how to use bzr to create branch and a patch (well documented many
>>> places).  If someone has time to do this before the stable release, it
>>> really would be nice if our demos showed off the 3D models.
>>>
>>> Thanks,
>>>
>>> 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
>>
>>
>>
>> ___
>> 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

[Henner Zeller]

On 4 August 2015 at 07:28, Carl Poirier carl.poirie...@gmail.com wrote:

 Hi,

 This is just to let you know that this has been merged. Sorry for it
 taking so long.


Thanks for merging my library cleanup patch! This way, we don't need the
(more hacky) workaround in the KiCAD application to 'manually' remove the
prefices there.

-h


 Regards,

 Carl

 On Fri, Jun 26, 2015 at 3:20 PM, Wayne Stambaugh stambau...@gmail.com
 wrote:

 Indeed!  In fact my couple of beer suggestion is sounding like a pretty
 good idea right about now. :)

 On 6/26/2015 3:11 PM, Adam Wolf wrote:
  Not only does no good deed go unpunished, every change breaks someone's
  workflow :)
 
  https://xkcd.com/1172/
 
  Adam Wolf
  Cofounder and Engineer
  WL
 
  On Fri, Jun 26, 2015 at 2:09 PM, Wayne Stambaugh stambau...@gmail.com
  mailto:stambau...@gmail.com wrote:
 
  On 6/26/2015 2:59 PM, Vesa Solonen wrote:
   26/06/15, 21:54, Adam Wolf kirjoitti:
   I think it is unfortunate that a request to the library
 maintainers
   requested by Wayne is responded to with a one line dismissal of:
  
   You know my opinion and it is immutable. Sorry.
  
   Adam Wolf
   Cofounder and Engineer
   WL
  
   On Fri, Jun 26, 2015 at 11:08 AM, Henner Zeller 
 h.zel...@acm.org mailto:h.zel...@acm.org
   mailto:h.zel...@acm.org mailto:h.zel...@acm.org wrote:
  
   ... Looks like library maintainers don't like it; see thread
 here:
   https://github.com/KiCad/kicad-library/pull/231
  
   -h
  
   Give it two days to sink in. Friday evenings may not be the best
 time
   either... ;)
  
   -Vesa
  
 
  Two days and a couple of beers. :)
 
  I'm going to avoid a pissing contest at this juncture in order to
 focus
  on the stable release.  I understand where Kerusey's frustration is
  coming from.  No one wants to see their efforts removed from the
 project
  but his response is not in the best interest of the project even if
 he
  is correct.  Henner, could you rework your patch to include a
 checkbox
  to hide the redundant description field information in your
 component
  search dialog.  Please make the default setting disabled so no one
 has a
  stroke.  No good deed goes unpunished.  Sig!
 
 
  ___
  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


___
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: improve library install script a little

[Henner Zeller]

Hi,
Some small changes for the library-repos-install.sh script.

https://github.com/hzeller/kicad/compare/master...hzeller:script-no-grep-dependency.diff

Suggested commit message:

o library install script improvements
   - Make WORKING_TREES configurable with environment variable to
 simplify external install scripts.
   - Don't use grep but native sed functionality to find relevant
 lines in github JSON (grep can create trouble if there is a
 global --color=always setting)

(guess how I found out about the color setting haha).

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

[Henner Zeller]

[Adding kicad-devel back; context:
https://github.com/KiCad/kicad-library/pull/231 ]

On 4 August 2015 at 08:41, Kerusey Karyu keruseyka...@o2.pl wrote:

 Henner Zeller w dniu Tue, 4 Aug 2015 07:48:54 -0700 napisał:

  Thanks for merging my library cleanup patch! This way, we don't need
  the (more hacky) workaround in the KiCAD application to 'manually'
  remove the prefices there.
 

 Let me speak the final words:
 And in this way the group got rid one of a translator, library
 maintainer and contributor. Every revolution destroys their children...

 Best Regards
 Kerusey Karyu


I am sorry that you feel that way and I am probably not too qualified to
respond here as I am just contributing a patch without knowledge of
possible prior context around - I guess you didn't mean to privately send
it to me, so I added the devel group back. I certainly didn't mean to
create any bad feelings here, just propose a reasonable patch.

My reason for this change is simple: it removes redundancy (which is always
good when maintaining data). And with that, it allows to show more relevant
information in the limited space in the component chooser. Several KiCAD
developers felt the same way.

The redundant data didn't serve any apparent purpose; in the pull request,
you were vehemently against the change, but couldn't state a reason why it
would be useful to keep it the way it was. Maybe everybody is blind to the
actual reason, but if you don't state it, people will go with the more
reasonable choice for them.

I presume that you spent quite some time in the past adding these as
searching used to be very tedious - which is the what you said in the pull
request. And of course that means that you are attached to the work that
went into it. But shouldn't we all be happy to be able to remove a
workaround when the original problem (tedious searching) is fixed ?

I can't comment on your decision to stop contributing, the group is
probably more qualified for it. If this pull request is the trigger, then
this is a sad outcome. As a user, I thank you for your tremendous
contribution to the KiCAD libraries and wish that some healthy discussion
can keep you on-board.

Thanks,
  Henner.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] Skip redundant repetition of component name in component chooser

[Henner Zeller]

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?

Here would be an alternative approach ... fixing the library. If
library maintainers are ok with it, I can send it as pull request on
github.

Essentially: remove all the component names as first element in the
description. They are redundant, and it is also error prone to
maintain.

https://github.com/hzeller/kicad-library/compare/suggestion-remove-repeated-component-name.diff

-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] Cleanup: remove unnecessary macros

[Henner Zeller]

On 25 June 2015 at 23:45, jp charras jp.char...@wanadoo.fr wrote:
 Le 26/06/2015 07:40, Chris Pavlina a écrit :
 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

 I fully agree to replace EXCHG by std::swap ( EXCHG come from the early
 times when Kicad was written in C).


 I am *not* convinced by replacing
 m_pos.x -= aYaxis_position;
 NEGATE(  m_pos.x );
 m_pos.x += aYaxis_position;

 by
 m_pos.x = 2 * aYaxis_position - m_pos.x;

 When you read the last form, it is not clear this is a mirroring
 relative to the aYaxis_position X position.

 At least for me, it is not a lot clearer..., this is quite the opposite.

 Perhaps a macro like MIRROR( m_pos.x, aYaxis_position )

.. or a type-safe inline function.

 is a lot clearer...

 By the way, for me:
 x = -x looks better than x *= -1
 an should be faster to calculate.

 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

___
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] cvpcb netlist behavior

[Henner Zeller]

On 26 June 2015 at 07:29, jp charras jp.char...@wanadoo.fr wrote:
 Le 26/06/2015 16:14, Chris Pavlina a écrit :
 Hi,

 Lately I've noticed a whole bunch of people coming into the IRC channel
 confused by the new behavior of cvpcb. Since it now pushes changes back
 to eeschema instead of writing a file, there is an extra step: you have
 to go back into eeschema and export the netlist again. A lot of people
 are seeing the Cannot add new component due to missing footprint
 messages and thinking there's a bug.

 Any chance of adjusting this behavior before the release to stop the
 confusion? Perhaps cvpcb could trigger a netlist write on save, or maybe
 pcbnew could use kiway to see the update footprints and pull them in /
 warn about them.

 --
 Chris

 What do you mean by
 you have to go back into eeschema and export the netlist again

 You have to export the netlist only once.
 Cvpcb do not use the current netlist, and when closing it, you are in
 Eeschema.

Well, previously, people just wrote the *.cmp file, went to pcbnew,
imported that and were happy.

Now, the footprint associations are in the net file, so they have to
export a fresh netfile and import that in pcbnew. That is the
additional step.

So I think making it simpler (or automatically trigger) to export a
netlist would be good in that case.

-h



 --
 Jean-Pierre CHARRAS

 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] Skip redundant repetition of component name in component chooser

[Henner Zeller]

On 26 June 2015 at 04:49, Wayne Stambaugh stambau...@gmail.com wrote:
 On 6/26/2015 3:53 AM, jp charras wrote:
 Le 26/06/2015 09:37, Vesa Solonen a écrit :
 26/06/15, 09:55, Henner Zeller kirjoitti:

 Here would be an alternative approach ... fixing the library. If
 library maintainers are ok with it, I can send it as pull request on
 github.

 Essentially: remove all the component names as first element in the
 description. They are redundant, and it is also error prone to
 maintain.

 Full support from me even though I haven't been maintaining much...

 -Vesa


 Full support from me too.

 A good fix is better than a workaround.



 +1

 Would our library maintainers please make this happen?  Thanks.

Ok, created library pull request
  https://github.com/KiCad/kicad-library/pull/231

-h

___
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

[Henner Zeller]

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

[Henner Zeller]

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

[Henner Zeller]

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

[Henner Zeller]

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] Skip redundant repetition of component name in component chooser

[Henner Zeller]

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

Re: [Kicad-developers] PATCH: better annotation dialog checkbox messaging

[Henner Zeller]

On 22 June 2015 at 08:42, Wayne Stambaugh stambau...@gmail.com wrote:
 On 6/20/2015 4:38 PM, Henner Zeller wrote:
 Hi,
 The checkbox labels in the annotation dialog are hard to understand
 because they are passive voice and not very clear (What does 'Silent
 mode' mean ?).
 Also, the default for the 'Automatically close dialog' (which is
 false) doesn't really make sense in regluar work. So I changed it.

 Patch
 https://github.com/hzeller/kicad/compare/better-annotation-dialog-checkbox-messaging.diff

 Suggested commit message:
 ---
 Change messaging in Dialog checkbox labelling in Annotation dialog
 to more easily digestable active speech
- 'Silent mode' - 'Always ask for confirmation'. Default on
  (Same behavior as before, though arguably, it is very annoying and
  should probably be default off)
- 'Automatically close dialog' - 'Keep this dialog open'
  Also changed the default to _not_ keep the dialog open (what is
  keeping it open even be useful for ?)
 

 (I wonder, is there ever a reason to keep the annotation dialog open ?
 This only really makes sense if this is a non-modal dialog).

 I don't understand why the annotation dialog would stay open as opposed
 to any other modal dialog.

Exactly, this is why I made the change.

  The annotate button should perform the
 annotation and close the dialog box.  I would have no problem with that
 change.

I can't think of a reason why the user should want to keep the dialog
open at all (maybe there were historical reasons ? - someone on the
mailing list might know).
Are there ever non-modal invocations of this dialog ?

If there are no such reasons, I think the next step is to get rid of
this option entirely.

-h



 -h

 ___
 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: remove intermediate modal message in creating NET file that needs annotation first

[Henner Zeller]

On 22 June 2015 at 09:39, Wayne Stambaugh stambau...@gmail.com wrote:
 Henner,

 This patch fails to apply cleanly against your
 better-annotation-dialog-checkbox-messaging.diff patch.

I think it conflicted with the library rescue improvements patch as
there were changes in the vicinity.

Updated the patch. Can you try again ?
  
https://github.com/hzeller/kicad/compare/remove-unnecessary-intermediate-step.diff

-h

 Wayne

 On 6/20/2015 6:57 PM, Henner Zeller wrote:
 Hi,
 When writing a NET file, eeschema notices if not everything is
 annotated, so sends the user to annotate the schematic.

 However, it does so by asking this question in a modal dialog box
 first, and _then_ opens the annotation dialog, which is quite some
 annoying sequence.
 In particular if you go through it many times a day :)

 So I removed that superfluous message box, but instead added the
 message to the annotation dialog in that case. The user still can
 cancel there if they want.

 (See also my 'Possibly low-hanging fruit usability improvement' mail today)

 Patch is here:

 https://github.com/hzeller/kicad/compare/remove-unnecessary-intermediate-step.diff

 Suggested commit message
 ---
 Remove one unnecessary step in the workflow 'exporting NET file
 that requires annotation first'.
 ---

 -h

 ___
 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: remove intermediate modal message in creating NET file that needs annotation first

[Henner Zeller]

On 22 June 2015 at 11:25, Wayne Stambaugh stambau...@gmail.com wrote:

 On 6/22/2015 1:05 PM, Henner Zeller wrote:
 On 22 June 2015 at 09:39, Wayne Stambaugh stambau...@gmail.com wrote:
 Henner,

 This patch fails to apply cleanly against your
 better-annotation-dialog-checkbox-messaging.diff patch.

 I think it conflicted with the library rescue improvements patch as
 there were changes in the vicinity.

 Updated the patch. Can you try again ?
   
 https://github.com/hzeller/kicad/compare/remove-unnecessary-intermediate-step.diff

 -h

 One small fix I would like to see on this patch is to hide the user
 message text control without the dead space at the top of the dialog
 box.  I believe if you put the static text control in it's own sizer,
 you can hide the sizer and the spacing will take care of itself.  Maybe
 you can just hide the static text control.  You may have to call one of
 the wxWindows fit functions to get this work properly but it would make
 for a nicer looking dialog.

Just hiding did the trick. Updated patch on
  
https://github.com/hzeller/kicad/compare/remove-unnecessary-intermediate-step.diff




 Wayne

 On 6/20/2015 6:57 PM, Henner Zeller wrote:
 Hi,
 When writing a NET file, eeschema notices if not everything is
 annotated, so sends the user to annotate the schematic.

 However, it does so by asking this question in a modal dialog box
 first, and _then_ opens the annotation dialog, which is quite some
 annoying sequence.
 In particular if you go through it many times a day :)

 So I removed that superfluous message box, but instead added the
 message to the annotation dialog in that case. The user still can
 cancel there if they want.

 (See also my 'Possibly low-hanging fruit usability improvement' mail today)

 Patch is here:

 https://github.com/hzeller/kicad/compare/remove-unnecessary-intermediate-step.diff

 Suggested commit message
 ---
 Remove one unnecessary step in the workflow 'exporting NET file
 that requires annotation first'.
 ---

 -h

 ___
 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] Possibly low-hanging fruit usability improvement

[Henner Zeller]

Hi,
So I know we're about about get ready for the stable release, but
there are two things that are possibly low-hanging fruit usability
improvements, that we might consider.

A lot of usability problems I run into are a series of modal dialogs I
have to go through for common tasks, this addresses the ones that
annoy me the most.

I am happy to help working on the implementation on at least on of
them if the consensus is that it make sense before the stable release.
I personally think it does ...

== Exporting Netlist. ==

Exporting a netlist is pretty involved right now
  - Press 'export Netlist button'
  - Get a modal dialog to choose if I want pcbnew format or three
others I usually don't care about unless I want to export something.
So just pressing the [Generate] button
  - Get _another_ modal dialog that asks me the filename to save it
as. Which _maybe_ makes sense when I choose one of the export options,
but not when I am in the workflow of getting a netlist out to be used
in pcbnew.

So I suggest
  - Have the 'export Netlist button' just export the netlist in kicad
format the default $(schematic-name).net filename. Single button press
for the common task. Down from three actions to one. The status
message should just indicate that it save the net file with number of
nets (right now, it only shows number of nets)

   - Have the current workflow in the menu as 'Export Netlist...' or something

== Annotation while exporting Netlist ==

When exporting the netlist, and not everything is annotated, the
workflow currently is as follows
  1) Press annotation button, press generate, press save (three steps,
that would now be one step if above is implemented)
  2) kicad notices that not everything is annotated and pops up a
modal dialog on top of the kicad control application (for some reason,
not on the eeschema), telling that items are not annotated and if I
would like to do that. Select 'Yes'.
  3) Then the annotation dialog pops up.

I suggest to leave out the intermediate step and directly open the
annotation dialog but with the additional message on top. This cuts
out one click, and the distracting fact that the previous window
popped up at a very different place on the screen.

What do you think ?

-h

___
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: better annotation dialog checkbox messaging

[Henner Zeller]

Hi,
The checkbox labels in the annotation dialog are hard to understand
because they are passive voice and not very clear (What does 'Silent
mode' mean ?).
Also, the default for the 'Automatically close dialog' (which is
false) doesn't really make sense in regluar work. So I changed it.

Patch
https://github.com/hzeller/kicad/compare/better-annotation-dialog-checkbox-messaging.diff

Suggested commit message:
---
Change messaging in Dialog checkbox labelling in Annotation dialog
to more easily digestable active speech
   - 'Silent mode' - 'Always ask for confirmation'. Default on
 (Same behavior as before, though arguably, it is very annoying and
 should probably be default off)
   - 'Automatically close dialog' - 'Keep this dialog open'
 Also changed the default to _not_ keep the dialog open (what is
 keeping it open even be useful for ?)


(I wonder, is there ever a reason to keep the annotation dialog open ?
This only really makes sense if this is a non-modal dialog).

-h

___
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: remove intermediate modal message in creating NET file that needs annotation first

[Henner Zeller]

Hi,
When writing a NET file, eeschema notices if not everything is
annotated, so sends the user to annotate the schematic.

However, it does so by asking this question in a modal dialog box
first, and _then_ opens the annotation dialog, which is quite some
annoying sequence.
In particular if you go through it many times a day :)

So I removed that superfluous message box, but instead added the
message to the annotation dialog in that case. The user still can
cancel there if they want.

(See also my 'Possibly low-hanging fruit usability improvement' mail today)

Patch is here:

https://github.com/hzeller/kicad/compare/remove-unnecessary-intermediate-step.diff

Suggested commit message
---
Remove one unnecessary step in the workflow 'exporting NET file
that requires annotation first'.
---

-h

___
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] Possibly low-hanging fruit usability improvement

[Henner Zeller]

On 20 June 2015 at 10:58, Henner Zeller h.zel...@acm.org wrote:
 Hi,
 So I know we're about about get ready for the stable release, but
 there are two things that are possibly low-hanging fruit usability
 improvements, that we might consider.

 A lot of usability problems I run into are a series of modal dialogs I
 have to go through for common tasks, this addresses the ones that
 annoy me the most.

 I am happy to help working on the implementation on at least on of
 them if the consensus is that it make sense before the stable release.
 I personally think it does ...

 == Exporting Netlist. ==

 Exporting a netlist is pretty involved right now
   - Press 'export Netlist button'
   - Get a modal dialog to choose if I want pcbnew format or three
 others I usually don't care about unless I want to export something.
 So just pressing the [Generate] button
   - Get _another_ modal dialog that asks me the filename to save it
 as. Which _maybe_ makes sense when I choose one of the export options,
 but not when I am in the workflow of getting a netlist out to be used
 in pcbnew.

 So I suggest
   - Have the 'export Netlist button' just export the netlist in kicad
 format the default $(schematic-name).net filename. Single button press
 for the common task. Down from three actions to one. The status
 message should just indicate that it save the net file with number of
 nets (right now, it only shows number of nets)

- Have the current workflow in the menu as 'Export Netlist...' or something

 == Annotation while exporting Netlist ==

 When exporting the netlist, and not everything is annotated, the
 workflow currently is as follows
   1) Press annotation button, press generate, press save (three steps,
 that would now be one step if above is implemented)
   2) kicad notices that not everything is annotated and pops up a
 modal dialog on top of the kicad control application (for some reason,
 not on the eeschema), telling that items are not annotated and if I
 would like to do that. Select 'Yes'.
   3) Then the annotation dialog pops up.

 I suggest to leave out the intermediate step and directly open the
 annotation dialog but with the additional message on top. This cuts
 out one click, and the distracting fact that the previous window
 popped up at a very different place on the screen.

This second point is addressed in patch
https://github.com/hzeller/kicad/compare/remove-unnecessary-intermediate-step.diff

-h

___
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 naming in component tree search container

[Henner Zeller]

Hi,
Looking at my old code in the component tree search container, it
looks like in the meantime it acquired two styles of member variable
naming; the old without the m_* prefix is now accompanied with
apparently the new preferred style with an m_* prefix.

This is a no-op change that just fixes all private member variables to
be the same style with the m_* prefix.

Patch here:

https://github.com/hzeller/kicad/compare/cleanup-common-prefix-instance-variables.diff

Suggested commit message
-
Member variables within component search tree were named inconsistently.
Now prefix all member variables with m_* which seems to be the current style.
---

-h

___
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] eeschema cmp-[back] button obsolete ?

[Henner Zeller]

Hi,
If I understand it correctly, cvpcb now directly stores footprint
edits back in eeschema, so there are no *.cmp files to import
(typically), but the [back] button still is a prominent member of the
button bar.
I suppose it can go, and the import from legacy *.cmp more buried in
some less-used menu ?

-h

___
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] eeschema cmp-[back] button obsolete ?

[Henner Zeller]

On 18 June 2015 at 10:13, Wayne Stambaugh stambau...@gmail.com wrote:
 Yes, hitting the save button in CvPcb sends a KiwayExpress message to
 Eeschema with the footprint assignments.

 The back import button has to remain for legacy designs and users who
 don't import the .cmp file into the schematic and use the s-expr netlist
 to load footprints in Pcbnew.  It can also be used to back import
 footprint changes made in Pcbnew.

Should we consider a whizzard that comes up when it sees a *.sch file
opened with a *.cmp file also lying around
and offers help merging these ? The whizzard only shows up if there
are footprints missing in the *.sch file that are
defined in the *.cmp file (the typical problem of someone migrating
from the 'old way'). Next time, that automatically
is not needed anymore.

Otherwise I fear it is harder for people to discover what to do.
Also it allows to quicker move users to the new way of doing things,
and makes sure to have them migrated before
they delete the assumed ephemeral *.cmp file (which is for instance a
file I never checked into version control).

-h


 We could consider moving it to a less used menu but for short term while
 users are busy back importing their .cmp files, leaving it on the
 toolbar is probably best.

 On 6/18/2015 12:10 PM, Henner Zeller wrote:
 Hi,
 If I understand it correctly, cvpcb now directly stores footprint
 edits back in eeschema, so there are no *.cmp files to import
 (typically), but the [back] button still is a prominent member of the
 button bar.
 I suppose it can go, and the import from legacy *.cmp more buried in
 some less-used menu ?

 -h

 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp


 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] PATCH: fix that the whole file changes on each save in pcbnew

[Henner Zeller]

On 18 June 2015 at 12:25, Wayne Stambaugh stambau...@gmail.com wrote:
 Henner,

 Good catch.  I'm not sure how this one slipped through the cracks.

 I committed your patch in the product branch r5783.  I did have to fix
 some coding policy issues (curly bracket placement).  Please keep that
 in mind in future patches.

Ugh, the Kicad coding standards get me every time. I need to get that
into my muscle memory again when working on the code...

-h

___
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: fix that the whole file changes on each save in pcbnew

[Henner Zeller]

Hi,
When using version control, I noticed that whenever I safe the file,
almost every line changed, even if there are only tiny changes. This
is very annoying, in particular with version control, as it is
impossible to see what changed (also it makes it virtually impossible
to merge changes manually).

Turns out the segments are alternating stored front to back, then back
to front. Reason is that while reading the file, the BOARD::Add()
function is called with ADD_APPEND by the PCB_PARSER, however, that
flag is ignored.
So each time in reading, the sequence of segments is turned upside down.

Patch attached.

Henner.

(that the API provides both at the flick of an integer value is
probably something that should be changed to two different method
names to make that more explicit; but that is a refactoring change
after the release).


patch-fix-alternating-save-sequence-segments.patch.gz
Description: GNU Zip compressed data
___
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] Best way to set up a canonical library path ?

[Henner Zeller]

Hi,
So while developing and setting up a new system, it is not really
clear to me how to set up all the paths. Right now I can't seem to
find a simple way, only something that feels a bit too complicated.

1) Installing libraries
(I do _not_ use the git-plugin but rather prefer local installation)

To get a fresh setup of libraries, I am running scripts/library-repos-install.sh
I am doing that with a custom path (WORKING_TREE=/usr/local/share/kicad)

under $WORKING_DIR, it creates library-repos, under which it unpacks

  $WORKING_TREE/library-repos/kicad-library
with schematic symbols and 3d packages
and unpacks all pretty directories in there as well:

  $WORKING_TREE/library-repos/*.pretty

so far so good.

2) setting the environment variables

Now running a freshly compiled KiCad does of course not find the
libraries. In fact, without any environment variables present, it
apparently assumes these:

KIGITHUB=https://github.com/KiCad
KISYS3DMOD=/usr/local/modules/packages3d
KISYSMOD=/usr/local/modules

(which it writes to ~/.config/kicad/kcad_common). This seems to be
bogus to me; I can imagine that it extracts that from the compile
PREFIX somehow, but I'd expect it to append a share/kicad or something
to it.

After copying the fp-lib-table and setting the enviroment variable as
suggested in the script

cp $WORKING_TREES/library-repos/kicad-library/template/fp-lib-table.for-pretty
~/.config/kicad/fp-lib-table
export KISYSMOD=$WORKING_TREES/library-repos

.. eeschema still does not find the libraries.

for that, I have found that I can set KICAD to that directory
export KICAD=$WORKING_TREES/library-repos/kicad-library

Now, 3D viewing _still_ does not work. Yet another environment
variable has to be set
export KISYS3DMOD=$WORKING_TREES/library-repos/kicad-library/modules/packages3d

3) Findings
Kicad only works with the libraries with a little of manual-work.
Three environment variables have to be set to get going. Given
WORKING_TREES as the chosen location in the install script, these are
the environment variables:

export KICAD=$WORKING_TREES/library-repos/kicad-library
export KISYSMOD=$WORKING_TREES/library-repos
export KISYS3DMOD=$WORKING_TREES/library-repos/kicad-library/modules/packages3d

4) Question
Am I am doing something wrong here, or is this really needed this way ?

5) Suggestion
I know I have not been actively developing recently, so I can't really
complain. But I would like to see it working this way:

- We have a defined standard layout of how libraries are checked
out/installed locally. Say in $PREFIX/share/kicad. The install script
does already something like that, so that could be the defined
standard way (though some re-structuring might be useful).
- There is only _one_ environment variable to be set, pointing to
the root of this directory (KICAD_SYSTEM_LIBS or something)
- This environment variable is pre-set to $PREFIX/share/kicad (or
to the eqivalent path on where typically data files reside on other
platforms).

Would this be a good goal before a new, stable release ? I think it
will help users and make software-packagers happy.

Cheers,
  Henner.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Schematic Symbol Philosophy?

[Henner Zeller]

On 5 June 2015 at 11:00, Andy Peters de...@latke.net wrote:


  On Jun 4, 2015, at 9:26 PM, Chris Pavlina pavlina.ch...@gmail.com
 wrote:
 
  The assignment of footprints to schematic symbols is largely a KiCad
  quirk. Many other tools consider a component to be a single package
  containing symbol and footprint. In my own library I have a part per
  actual electronic part (one called MMBT3904, for instance), which
  already has the Footprint field set from the very beginning, no mucking
  about with the nightmare that is cvpcb.
 
  Also, footprints are much more critical, in that you have to get all the
  dimensions very correct, so it makes much more sense in terms of being
  less error-prone to have multiple symbols linked to one footprint than
  one symbol linked to multiple footprints.

 At risk of reiterating myself again, what Chris describes above is how
 professional engineering groups do their libraries. Every company I’ve
 worked for has a vetted parts list and the PCB layout library includes only
 those parts. The symbols and footprints are married to a part number. Under
 no circumstance would someone choose, say, an NPN transistor from a library
 and then later match it to a footprint and to something that can be
 ordered. The chance of an expensive fuck-up happening is way too high.


Agreed. The way this internally should be represented is something like
   IRFZ44N = (generic PowerMosfet with logic names) + (G=1 D=2 S=3 pin
assignment) + TO220 with pin 1,2,3.

That way, it minimizes the repetition of the symbol definition, but then
ties the important information that makes a particular product the way it
is together.
___
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] Schematic Symbol Philosophy?

[Henner Zeller]

On 5 June 2015 at 11:54, Chris Pavlina pavlina.ch...@gmail.com wrote:
 On Fri, Jun 05, 2015 at 02:31:06PM -0400, Wayne Stambaugh wrote:
 On 6/5/2015 2:00 PM, Andy Peters wrote:
 
  *snip *

 *snip* Trying to provide a fully defined symbol
 for every transistor would be a huge under taking.  Our solution may not
 be ideal but I'm not sure I want to sift through thousands (tens of
 thousands?) of transistor part numbers to find what I'm looking for.

 You should never have to sift! We need to create a standardized way to
 write description that is easily searched. This is how I manage my
 library - it's quite large, but I know how the descriptions work and I
 can just start typing what I'm looking for.

 I wonder how well Henner's component chooser search code would handle
that
 number of symbols.

 Optimize it if it can't! Searching through even *millions* of data
 points is a solved problem in computing.

As I said, I wouldn't worry about that. In my day-job I am working
with billions of things to search from, so this is peanuts.

-h

___
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] Schematic Symbol Philosophy?

[Henner Zeller]

Hi,
I stumbled about a similar things with double-diodes. I see why it is done,
and this is one acceptable solution to the problem at hand.

But it is hard to navigate.

I have a long-term suggestion (that I am happy to help implement), and a
short-term suggestion to get things out of the door quickly for a stable
release, but helps users to not be confused and gives us a chance to
improve things later.

Longer term (after the next stable release), it makes sense to re-evaluate
data-structures. It would probably be best to simplify the proliferation of
symbols by separating symbol from pin assignments+possible footprints.

So associate the schematic symbol with a number of variant footprints,
which essentially adds a sub-relation, something like

  symbol (generic FET for instance)  -  (multiple variants of assignment
to D=pin1 G=pin2 S=pin3; package hints TO92, TO220...)

(I think this is how it is mostly done in other tools as it helps to have
simple symbol _and_ a way to associate to a number of footprints). So each
symbol can have a number of separate logical to pin-assignment.

Main advantage for the user is, that they can see a tree view: they choose
a symbol, then the sub-variant that applies to their case (pin-assignment).
There or in pcbnew they then finally choose the package.

Anyway, details need to be hashed out and require some discussion. And
certainly not something to change now in preparation for a good next
release.

In the meantime, while that is not in place yet, how about this:

   - we store one optional additional field in a schematic symbol, think of
it as a 'tag' that ties symbols together into one family. In Adams'
example, that could be for instance Q_PMOS. All the symbols are still
separate, but they have this 'unifying' field that associates things across
symbols. For the younger audience: think of it as a hashtag :).

   - The component chooser (which I have largely contributed in its current
form) can use this additional information to present these components under
one sub-tree. So the tag has no semantic meaning right now, it is only used
to better display things.

That way we have
  1) A much more 'logical' way to present these components to a user
without making their heads explode.
  2) Almost no implementation overhead for an upcoming release (and
importantly: very slim chance to introduce new bugs while stabilizing). No
data structure is fundamentally changed, but we just add another optional
field (most components never set this).
  3) a chance in the future to automatically adapt schematics to a possibly
new long-term data structure later.

If this sounds like an acceptable solution, I am happy to work on it.

-h

On 4 June 2015 at 20:23, Adam Wolf adamw...@feelslikeburning.com wrote:

 Hi folks,

 I was using KiCad to make a board today (yeah, the novelty of actually
 *using* it!), and I noticed that there's been some changes in schematic
 symbols--and I'm wondering if it was on purpose.

 I was adding a pmos to my schematic, and I noticed there are:

 Q_PMOS_DGS
 Q_PMOS_DSG
 Q_PMOS_GDS
 Q_PMOS_GSD
 Q_PMOS_SDG
 Q_PMOS_SGD

 and the change is basically to change the pin numbers.

 Years ago, I thought it was that the schematic was a logical
 representation of your circuit, and the assignment of footprints to
 schematic symbols was where you chose parts, especially for things like
 fets.

 Is this a transitory thing, or is this the way we've chosen to set up the
 official kicad libraries?

 This isn't criticism, more something I was a little confused by and
 decided I'd check on.

 Thanks!

 Adam Wolf

 ___
 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] tiny PATCH: correct comment describing destination of fp-lib-table

[Henner Zeller]

On 17 October 2014 11:50, Wayne Stambaugh stambau...@verizon.net wrote:
 Patch committed in product branch r5199.  Thank you for your
 contribution to KiCad.

I'll see if I can work a bit on my TODOs that I have collected for
KiCAD in the next couple of weeks.

(Just did a fresh compile today and install and install of the
libraries, but for some reason only the power-library shows up in
eeschema - is there some other recent change search-path here ?)

-h

___
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] tiny PATCH: correct comment describing destination of fp-lib-table

[Henner Zeller]

On 17 October 2014 11:57, Nick Østergaard oe.n...@gmail.com wrote:
 Hi Henner

 I noticed that this is the case for eeschema standalone only, so if
 you start eeschema from kicad it loads the rest just fine. I am not
 sure when this started.

Good finding. I do very much prefer to start the programs
independently, so I'll have a look what is differently.


 Nick

 2014-10-17 20:53 GMT+02:00 Henner Zeller h.zel...@acm.org:
 On 17 October 2014 11:50, Wayne Stambaugh stambau...@verizon.net wrote:
 Patch committed in product branch r5199.  Thank you for your
 contribution to KiCad.

 I'll see if I can work a bit on my TODOs that I have collected for
 KiCAD in the next couple of weeks.

 (Just did a fresh compile today and install and install of the
 libraries, but for some reason only the power-library shows up in
 eeschema - is there some other recent change search-path here ?)

 -h

 ___
 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] tiny PATCH: correct comment describing destination of fp-lib-table

[Henner Zeller]

On 17 October 2014 12:31, Wayne Stambaugh stambau...@verizon.net wrote:
 This is most likely due to Dick's kiway work.  One thing to keep in mind
 is that the stand alone applications are free to operate outside the
 scope of a project.  In other words, if you are running Eeschema in
 stand alone mode, it will look to for a project file in the same
 directory as the schematic that was opened.  Otherwise, no project is
 assumed.  However, when Eeschema is launched by the KiCad application
 launcher, it's behavior is different because this is always done in the
 context of the currently loaded project.  It's possible that something
 go missed during this transition.  However, this behavior should not be
 changed.

So starting eeschema standalone is supposed to be broken, or just the behavior
to look for the current project file is not to be changed ?
I think if eeschema doesn't find one, it should just assume the
default (whatever the template is).

Given that the project file most of the time never changes but just contains the
stuff copied from the template, relying on it to be there sounds like
a bad idea.

In particular I think a project file should mostly be optional
and probably only be stored by the toplevel kicad binary if it
actually is different than
the template to avoid clutter.

(I never understood what the project file is for btw, it seems like
the *.sch and *.pcb_new
are sufficient for everything (and then a *.net and *.cmp as
intermediate files)))


 On 10/17/2014 3:02 PM, Henner Zeller wrote:
 On 17 October 2014 11:57, Nick Østergaard oe.n...@gmail.com wrote:
 Hi Henner

 I noticed that this is the case for eeschema standalone only, so if
 you start eeschema from kicad it loads the rest just fine. I am not
 sure when this started.

 Good finding. I do very much prefer to start the programs
 independently, so I'll have a look what is differently.


 Nick

 2014-10-17 20:53 GMT+02:00 Henner Zeller h.zel...@acm.org:
 On 17 October 2014 11:50, Wayne Stambaugh stambau...@verizon.net wrote:
 Patch committed in product branch r5199.  Thank you for your
 contribution to KiCad.

 I'll see if I can work a bit on my TODOs that I have collected for
 KiCAD in the next couple of weeks.

 Is one of the things on your TODO list to fix the component selection
 dialog to only show the first instance of a component in the library
 path order list when duplicate names are found?

It wasn't, but now it is on my TODO :)

Is there a bug-number with the details somewhere ?

  There is currently a
 bug (which is actually a well known bug in the design of Eeschema but
 that fix will not happen until the new file formats are in place) that
 allows the user to select a component that will not actually be used in
 the schematic.  To work around this bug, you should not display any
 components with duplicate names following the first one found in the
 library search order.  In other words you cannot do a simple sort by
 component name, you must remove all subsequent duplicate components
 names from the selection lists.  I know this not elegant but this will
 cause less confusion than the user getting the wrong component in their
 schematic.  A user warning when duplicate component names may be useful.
  Of course this doesn't prevent the user from inadvertently change the
 sort order of their libraries and getting a different component.


 (Just did a fresh compile today and install and install of the
 libraries, but for some reason only the power-library shows up in
 eeschema - is there some other recent change search-path here ?)

 -h

 ___
 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] tiny PATCH: correct comment describing destination of fp-lib-table

[Henner Zeller]

Hi,
The scripts/library-repos-install.sh describes in a comment where to
copy the fp-lib-table.
It still describes the old location ~/fp-lib-table instead of
~/.config/kicad/fp-lib-table

View here:
https://github.com/hzeller/kicad/compare/master...new-config-location

Download here:
https://github.com/hzeller/kicad/compare/master...new-config-location.diff

Cheers,
  Henner.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Usability test.

[Henner Zeller]

I just quickly scanned through it. I noticed you scanned through the
component tree for component selection - You should try to use the
search-as-you-type feature in the filter box for component selection,
it really is very quick to narrow down your choices.

-h

On 9 September 2014 13:54, Tim Hutt tdh...@gmail.com wrote:
 Hi,

 I've been looking for a good free EDA software for ages, and currently use
 Designspark PCB, which is freeware but not open source (although the only
 limitation is an unobtrusive RS splash advert on startup). It is ok though -
 and orders of magnitude better than Eagle. I tried gEDA years ago and it was
 worthless.

 Anyway, I've been following CERN's work on Kicad, and thought I'd give Kicad
 a try. These sorts of programs always seem to fail on basic usability things
 (like how to copy/paste) so I recorded my first ever Kicad session!
 Hopefully it will be valuable so you can see what new users thing when
 trying Kicad (assuming you care).

 It's 30 mins. Somewhat low quality youtube (it downscaled 1024p to 720p
 stupidly):

 https://www.youtube.com/watch?v=k93cSNXEFUk

 Original (better quality):
 https://www.dropbox.com/s/jymyxaoe1mg98qh/Kicad_Newbie_Part_One.mp4?dl=0

 I hope I don't seem too critical in the video. Although Kicad did have some
 of the same crazy usability issues that seem to plague all EDA apps (failed
 the copy/paste test!), it did seem fairly clean and non-buggy and fixing the
 usability issues is probably not too hard (/me tentatively raises
 volunteering hand).

 What do you guys think?

 Cheers,

 Tim

 PS: Kicad-winbuilder is awesome. Well done whoever is responsible for that!

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

[Henner Zeller]

On 27 August 2014 12:22, Ian ian.oh...@gmail.com wrote:
 Hi Jean-Pierre,

 I noticed that the emails you send to the list from your @yahoo.com address
 get classified as Spam by gmail.  Emails from your address
 jp.char...@wanadoo.fr make it through fine.  When I open the emails that
 make it to Spam, gmail says:

 Our systems couldn't verify that this message was really sent by yahoo.com.
 You might want to avoid clicking links or replying with personal
 information..

This usually would show up if you pretend to send something with a
@yahoo.com address without actually going through their SMTP server.

I think the problem is the bugtracker: it sends messages not from some
kicad-bugtracker@... address, but sends it as-if it was coming from a
particular user. Which is bad and rightfully is warned about being
potential SPAM, as it impersonates someone.

Also, the bugtracker always sends stuff directly to users (instead to
a mailing-list of subscribed users), which I find as well disturbing
-- that way all bugtracker mails always show up as directly sent to me
and it is harder to filter.

That bugtracker has some serious mail configuration issues, it behaves
very badly.

-h


 The same happens to emails from Cirilo Bernardo who also has a @yahoo.com
 address.  I'm not sure if this is helpful, but it's a datapoint at least.

 -Ian




 On Wed, Aug 27, 2014 at 11:36 AM, jp charras jp.char...@wanadoo.fr wrote:

 Since some time, I do not receive all mails from the mailing list or bug
 list.

 From mailing list perhaps 20% are lost.
 Perhaps 10% from the bug list.
 (I see that when I read the bug reports or the mailing list with firefox)

 I do not know the reason of this issue (this is not due to a spam filter).

 So I certainly not sent a response to some mails.
 Guys who asked me something have to resend their mails.
 Sorry.

 (I still can read the bug reports or the mailing list with firefox, but
 to send a response to a mail I did not received is not easy)

 --
 Jean-Pierre CHARRAS

 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp



 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp


___
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: opening *.pro in current directory gives error message

[Henner Zeller]

On 28 July 2014 07:16, Dick Hollenbeck d...@softplc.com wrote:

 On 07/28/2014 08:58 AM, jp charras wrote:
  Le 28/07/2014 15:20, Dick Hollenbeck a écrit :
  Thanks Henner:
 
  I'll look at this now.  The surprise is the inconsistency of the file
 dialog, which
  normally returns a full path, but here not.  An assert would have
 caught that assumption,
  my mistake.
 
  In the multiple open projects scenario, changing the directory (CWD)
 will go away.
 
  So I won't use your patch as is.  But thanks for the diagnosis.
 
  PROJECT::SetProjectFullName() requires a full path.  So we'll have to
 come up with that.
 
  I'll fix this this morning.
 
  Dick
 
  In fact I know one case where a path is not usually given:
  When you run kicad (and only kicad) by hand from a command line and your
  command is:
  kicad myproject.pro
 
  and myproject.pro is in the cwd.
 

 Henner,

 I was unable to duplicate the wxFileDialog behavior but I believe it could
 be version
 dependent and needs to be guarded against non-the-less.


It happened to me when I open kicad on the commandline with a *.pro file in
the same directory (essentially what jp said)
   kicad myproject.pro

in that case it boils down that the kernel is called with
  chdir();
 (as can be seen with strace)

... which returns the error. Maybe older Linux kernels were permissive
being called with an empty string. Or other operating systems.
In user level that was wxWidgets 3.0.1.


 I also protect against JP's concern in rev 5033.


 I will look at eeschema and pcbnew separately as part of my big pending
 work.


 ___
 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: opening *.pro in current directory gives error message

[Henner Zeller]

Hi,
Opening a foo.pro file in the current directory
   kicad foo.pro
gives an error message (Directory not found).

The reason is simple: calling wxSetWorkingDirectory() with an empty string
causes that problem.
This might be due to version of wxwidgets; I have version 3.0 whatever is
currently on debian testing.
Arguably, that should be fixed in wxwidgets (I'll check out that code later
and look for a solution there).

But for now, a fix for the immediate problem

View patch:
https://github.com/hzeller/kicad/compare/fix-error-message-on-opening-file-in-cwd

Download diff:
https://github.com/hzeller/kicad/compare/fix-error-message-on-opening-file-in-cwd.diff

This is against current head.

Cheers,
  Henner.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Static initialization order fiasco

[Henner Zeller]

On 12 April 2014 13:46, Lorenzo Marcantonio l.marcanto...@logossrl.com wrote:
 On Sat, Apr 12, 2014 at 12:56:24PM -0700, Alexander Lunev wrote:
 As it turned out, the issue is with undefined static initialization order.

 Yay for usual C++ sickness on 'obvious' details... IIRC it usually warns
 for these things. Maybe similar ones and not this in particular.

 C++ is becoming unmanageable (worse than Java, I'd say)

No, this is just a matter of using the language correctly.

Static initialization for instance should really be used sparsely and
only if you know what you're doing
(not sure it this fits my observations in KiCad code though :) ).

-h


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

___
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: improve keyboard handling - simulate mouseclick with RETURN

[Henner Zeller]

On 6 April 2014 23:21, jp charras jp.char...@wanadoo.fr wrote:
 Le 07/04/2014 07:52, Henner Zeller a écrit :
 On 1 April 2014 15:33, José Eduardo S. C. Xavier
 josescxav...@hotmail.com wrote:
 I thought it need to be on the main repo to get merged. I'll test it and
 report.


 2014-04-01 23:31 GMT+01:00 José Eduardo S. C. Xavier
 josescxav...@hotmail.com:

 Hi :)
 That is a really nice feature. Can you add it to the bzr repo?

 There was some discussion how to improve it earlier in the thread, but
 I got busy with actually making a board with KiCad (
 https://github.com/hzeller/bumps ) the last couple of free-time slots,
 so that I haven't come to this change yet. I plan to make it a bit
 nicer by actually registering a hot key (let's call that hot-key
 'Return' :) ) which then does the
 whatever-the-left-mouse-button-would-finish business.
 So it will not be much change, but I need to get around doing it.

 (having said that: this patch should work perfectly fine if you patch
 it in your code - I am using it all the time)


 Since bzr 4780, I added 2 new user definable hotkeys (  Ret and End ) to
 simulate Single Left Click and Double Left Click.

Ah, cool, so I can abandon the patch, as the functionality is now already there.
Thanks JP!


 Although the proposed patch works, it is not good because all hot keys
 should be user definable in Kicad.

 And when definable, they also appear in hot key list ( hotkey ? command
 to show this list)


 --
 Jean-Pierre CHARRAS

 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] PATCH: improve keyboard handling - simulate mouseclick with RETURN

[Henner Zeller]

On 1 April 2014 15:33, José Eduardo S. C. Xavier
josescxav...@hotmail.com wrote:
 I thought it need to be on the main repo to get merged. I'll test it and
 report.


 2014-04-01 23:31 GMT+01:00 José Eduardo S. C. Xavier
 josescxav...@hotmail.com:

 Hi :)
 That is a really nice feature. Can you add it to the bzr repo?

There was some discussion how to improve it earlier in the thread, but
I got busy with actually making a board with KiCad (
https://github.com/hzeller/bumps ) the last couple of free-time slots,
so that I haven't come to this change yet. I plan to make it a bit
nicer by actually registering a hot key (let's call that hot-key
'Return' :) ) which then does the
whatever-the-left-mouse-button-would-finish business.
So it will not be much change, but I need to get around doing it.

(having said that: this patch should work perfectly fine if you patch
it in your code - I am using it all the time)



 2014-03-06 23:45 GMT+00:00 Henner Zeller h.zel...@acm.org:

 On 3 March 2014 06:53, Wayne Stambaugh stambau...@verizon.net wrote:
  On 3/2/2014 2:29 AM, Henner Zeller wrote:
  Hi,
  For small changes, or when I only have a touchpad available, I like to
  use the keyboard for editing tasks, so I appreciate that the
  cursor-keys control the cross-hair similar to the mouse.
 
  However to finish a move initiated with 'm' followed by cursor
  movements, one still has to press the mouse-button, thus having to
  leave the keyboard and probably mess up the precise placement. This
  slows down editing and is inconsistent.
 
  This patch wires the 'Return' key as if the left mouse button was
  pressed (in eeschema and pcbnew).
 
  Commit message:
  Have the RETURN-key in editing tasks behave like a mouse-click at
  the same position.
 
  View here
 
  https://github.com/hzeller/kicad/compare/master...enter-is-like-mouseclick
 
  Download here:
 
  https://github.com/hzeller/kicad/compare/master...enter-is-like-mouseclick.diff
 
  -h
 
  Hey Henner,
 
  You also need to add your change to the schematic component library
  editor and board footprint editor so they behave the same way.  The
  functions you are looking for are:
 
  FOOTPRINT_EDIT_FRAME::GeneralControle()
 
  and:
 
  LIB_EDIT_FRAME::GeneralControle()

 Alright, will have a look at these.

 
  This way the the component and footprint editors will have the same
  behavior as the schematic and board editors.  Also, did you verify
  there
  are no other behavior issues with menus (both regular and context) with
  your patch.  Once a key is routed to the hotkey handler, it does not
  get
  passed on to the rest of the event handler chain so your patch may
  cause
  some odd behavior with other main frame controls.

 I didn't notice any oddities so far (I am using it locally). The menus
 react normally w.r.t. cursor keys and return to select as they get the
 event first.
 Consuming the enter key here would mean that if someone defined a
 hotkey for 'enter' wouldn't work (which should be very unlikely, but,
 well, at least it is a possibility). Still I think the advantage is
 more important than potential disadvantages.

 Alternatively, we could have a hotkey 'finish current action' or
 similar, that by default is wired to 'Return' - and which does exactly
 the finishing-mouseclick thing I now have hardwired in the
 conrole-functions. That way, people are free to wire it to some other
 key if desired.


 -h

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

 ___
 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: improve keyboard handling - simulate mouseclick with RETURN

[Henner Zeller]

On 3 March 2014 06:53, Wayne Stambaugh stambau...@verizon.net wrote:
 On 3/2/2014 2:29 AM, Henner Zeller wrote:
 Hi,
 For small changes, or when I only have a touchpad available, I like to
 use the keyboard for editing tasks, so I appreciate that the
 cursor-keys control the cross-hair similar to the mouse.

 However to finish a move initiated with 'm' followed by cursor
 movements, one still has to press the mouse-button, thus having to
 leave the keyboard and probably mess up the precise placement. This
 slows down editing and is inconsistent.

 This patch wires the 'Return' key as if the left mouse button was
 pressed (in eeschema and pcbnew).

 Commit message:
 Have the RETURN-key in editing tasks behave like a mouse-click at
 the same position.

 View here
 https://github.com/hzeller/kicad/compare/master...enter-is-like-mouseclick

 Download here:
 https://github.com/hzeller/kicad/compare/master...enter-is-like-mouseclick.diff

 -h

 Hey Henner,

 You also need to add your change to the schematic component library
 editor and board footprint editor so they behave the same way.  The
 functions you are looking for are:

 FOOTPRINT_EDIT_FRAME::GeneralControle()

 and:

 LIB_EDIT_FRAME::GeneralControle()

Alright, will have a look at these.


 This way the the component and footprint editors will have the same
 behavior as the schematic and board editors.  Also, did you verify there
 are no other behavior issues with menus (both regular and context) with
 your patch.  Once a key is routed to the hotkey handler, it does not get
 passed on to the rest of the event handler chain so your patch may cause
 some odd behavior with other main frame controls.

I didn't notice any oddities so far (I am using it locally). The menus
react normally w.r.t. cursor keys and return to select as they get the
event first.
Consuming the enter key here would mean that if someone defined a
hotkey for 'enter' wouldn't work (which should be very unlikely, but,
well, at least it is a possibility). Still I think the advantage is
more important than potential disadvantages.

Alternatively, we could have a hotkey 'finish current action' or
similar, that by default is wired to 'Return' - and which does exactly
the finishing-mouseclick thing I now have hardwired in the
conrole-functions. That way, people are free to wire it to some other
key if desired.


-h


 Thanks,

 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

___
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] last kicad not building on last Debian 64

[Henner Zeller]

This should be fixed with bzr4715

On 23 February 2014 03:29, Fabrizio Tappero fabrizio.tapp...@gmail.com wrote:
 Hello guys,
 the last kicad version wont build on last debian 64


 fabrizio@fab:~$ cd kicad_sources/
 fabrizio@fab:~/kicad_sources$ ./kicad-install.sh --install-or-update
 step 1) installing pre-requisites
 [sudo] password for fabrizio:
 Reading package lists... Done
 Building dependency tree
 Reading state information... Done
 build-essential is already the newest version.
 libbz2-dev is already the newest version.
 bzr is already the newest version.
 bzrtools is already the newest version.
 libcairo2-dev is already the newest version.
 cmake is already the newest version.
 cmake-curses-gui is already the newest version.
 debhelper is already the newest version.
 doxygen is already the newest version.
 libglew-dev is already the newest version.
 grep is already the newest version.
 libssl-dev is already the newest version.
 libwxgtk2.8-dev is already the newest version.
 python-wxgtk2.8 is already the newest version.
 The following packages were automatically installed and are no longer 
 required:
   libconfuse-common libconfuse0 libgtksourceview2.0-0
   libgtksourceview2.0-common mate-dialogs pluma-common python-gtksourceview2
 Use 'apt-get autoremove' to remove them.
 0 upgraded, 0 newly installed, 0 to remove and 6 not upgraded.
 Fabrizio Tappero fabrizio.tapp...@gmail.com
 step 2) make /home/fabrizio/kicad_sources if it does not exist
 step 3) checking out the source code from launchpad repo...
 Tree is up to date at revision 4714 of branch
 http://bazaar.launchpad.net/~kicad-product-committers/kicad/product
  local source working tree updated.
  M  library/microchip_pic18mcu.dcm
  M  library/microchip_pic18mcu.lib
 All changes applied successfully.
 Updated to revision 322 of branch
 http://bazaar.launchpad.net/~kicad-product-committers/kicad/library
  kicad-lib repo updated.
 step 5) checking out the documentation from launchpad repo...
 Tree is up to date at revision 545 of branch
 http://bazaar.launchpad.net/~kicad-developers/kicad/doc
  docs working tree updated.
 step 6) compiling source code...
 [  0%] Built target lib-dependencies
 [  1%] Built target boost
 [  1%] Built target lib_dxf
 [  2%] Built target potrace
 [  2%] [  2%] Built target idfrect
 Built target idfcyl
 [ 33%] [ 33%] Generating headers containing GLSL source code
 Built target bitmaps
 Headers are up-to-date
 [ 33%] Built target shader_headers
 [ 34%] Built target avhttp
 [ 34%] Built target 3d-viewer
 [ 34%] Built target polygon
 [ 36%] Built target pcad2kicadpcb
 [ 37%] Built target dxf2idf
 [ 41%] Built target pcbcommon
 [ 42%] Built target pnsrouter
 [ 42%] Built target github_plugin
 [ 43%] Built target gal
 [ 49%] Built target common
 [ 50%] Built target kicad
 [ 52%] Built target cvpcb
 [ 56%] Built target gerbview
 [ 58%] Built target pl_editor
 Scanning dependencies of target bitmap2component
 [ 58%] Building CXX object
 bitmap2component/CMakeFiles/bitmap2component.dir/bitmap2component.cpp.o
 [ 58%] Building CXX object
 eeschema/CMakeFiles/eeschema.dir/component_tree_search_container.cpp.o
 [ 72%] Built target _pcbnew
 [ 72%] Building CXX object
 bitmap2component/CMakeFiles/bitmap2component.dir/bitmap2cmp_gui_base.cpp.o
 /home/fabrizio/kicad_sources/kicad.bzr/eeschema/component_tree_search_container.cpp:
 In member function 'void
 COMPONENT_TREE_SEARCH_CONTAINER::AddAliasList(const wxString, const
 wxArrayString, CMP_LIBRARY*)':
 /home/fabrizio/kicad_sources/kicad.bzr/eeschema/component_tree_search_container.cpp:195:1:
 error: invalid operands of types 'const wxChar* {aka const wchar_t*}'
 and 'const wchar_t [2]' to binary 'operator+'
 make[2]: *** 
 [eeschema/CMakeFiles/eeschema.dir/component_tree_search_container.cpp.o]
 Error 1
 make[1]: *** [eeschema/CMakeFiles/eeschema.dir/all] Error 2
 make[1]: *** Waiting for unfinished jobs
 [ 72%] Building CXX object
 bitmap2component/CMakeFiles/bitmap2component.dir/bitmap2cmp_gui.cpp.o
 [ 87%] Built target pcbnew
 Linking CXX executable bitmap2component
 [ 87%] Built target bitmap2component
 make: *** [all] Error 2

 ___
 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] Henner's component chooser for CvPcb...

[Henner Zeller]

On Feb 23, 2014 10:55 AM, Lorenzo Marcantonio l.marcanto...@logossrl.com
wrote:

 On Sun, Feb 23, 2014 at 08:34:49PM +0200, Vesa Solonen wrote:
  Just throwing an opinion here, I think functionality of Henner's fine
  component chooser would make an immense usability enhancement for CvPcb
  footprint selection.

 Addon to the opinion: junk the whole cvpcb program and set the
 footprints directly in eeschema :D

 Anyway the same 'mechanism' could be applied to footprint selection,
 I agree. I fear there is some/a lot impedance mismatch with the internal
 data structure, however...

Agree, cvpcb functionality should ideally be provided in eeschema. And
should be  user friendly. I do have this on my list...


 --
 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
___
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] Henner's component chooser for CvPcb...

[Henner Zeller]

On 23 February 2014 15:03, Fabrizio Tappero fabrizio.tapp...@gmail.com wrote:
 Man... just now that I've made a great icon for cvpcb... I personally like a
 lot cvpcb. it is one of those things that make KiCad good !

I don't think that the functionality of what cvpcb does now
will/should go away entirely. Having a tabular view of the whole BOM
essentially and quickly be able to review and change the one or other
footprint is great and needed, in particular in the final passes of a
project. Though it should not be an external program as it is now,
essentially communicating back and forth with files, which makes the
process tedious and error prone.

Being able to quickly choose the footprint while choosing a particular
component is useful in many other cases; you typically want to choose
an initial footprint for your component; often you already know,
because you spent some time choosing that component because of
different footprint choices. In that case, having it simple to select
the footprint while choosing the component is another important thing.

Like all tools, KiCad should allow to work in top-down and bottom-up
ways, as the iteration in the process of creating a great board goes
in these waves.

Anyway, let's wait unit the DLL-ification is in before we discuss the
details of how things could be addressed in the different angles of
these use-cases.

-h


 my 2c

 Fabrizio


 On Sun, Feb 23, 2014 at 9:58 PM, Wayne Stambaugh stambau...@verizon.net
 wrote:

 On 2/23/2014 1:55 PM, Lorenzo Marcantonio wrote:
  On Sun, Feb 23, 2014 at 08:34:49PM +0200, Vesa Solonen wrote:
  Just throwing an opinion here, I think functionality of Henner's fine
  component chooser would make an immense usability enhancement for CvPcb
  footprint selection.
 
  Addon to the opinion: junk the whole cvpcb program and set the
  footprints directly in eeschema :D
 
  Anyway the same 'mechanism' could be applied to footprint selection,
  I agree. I fear there is some/a lot impedance mismatch with the internal
  data structure, however...
 

 This has already been discussed and it slated to happen after Dick's DLL
 work is complete.  This task will be simplified once both the schematic
 and board base code can be run from the same process.  That's why it
 hasn't happened yet.  But getting rid of CvPcb has agreed upon a long
 time ago.  Given Henner's excellent work on the component selection
 dialog, I have all the confidence that he would do a fine job on a
 footprint selection dialog.

 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



 ___
 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