Re: [Kicad-developers] 3D refactor

[Cirilo Bernardo]

On Tue, Feb 23, 2016 at 3:00 AM, Wayne Stambaugh 
wrote:

> Cirilo,
>
> I have one last change request that I missed in my previous review.
> Please change your debugging output method.  Windows apps have no
> concept of stdout even when run from the command line.  wxLogTrace is
> the preferred method for debugging output.  It solves two problems.  The
> debugging strings are redirected to the correct output on all supported
> platforms and the debugging output is turned off by default.  Turning on
> the debugging output is as simple as:
>
> export WXTRACE="SOME_DEBUGGING_OUTPUT_TO_ENABLE"
>
> The is handy so I don't have to sift through everyone's debugging output
> to find what I'm looking for.  You just need to pick a unique string not
> used by any other kicad wxLogTrace calls to enable tracing of your
> debugging output.
>
>
The 3d_initial_merge branch has been updated to use wxLogTrace;
it has also been synchronized to the main branch r6527.  The latest
revision for the 3d_initial_merge branch is r6527. The branch builds
successfully and I have tested the previewer with various VRML1/2 and
X3D models.

- Cirilo



> I'm still not thrilled about using a list of paths to search for 3D
> model files.  This is broken in the same way the the component library
> search path ordering is broken in Eeschema.  Since it's no worse than
> what we have now and fixes some of the current 3D model file loading
> issues, I'm willing to commit it but in the long run I think we really
> need to think about this more carefully and come up with a better way to
> resolve 3D model file names.
>
> Cheers,
>
> Wayne
>
> On 2/21/2016 7:28 PM, Cirilo Bernardo wrote:
> > Hi Folks,
> >
> >  Any thoughts on merging the 3d_initial_merge branch? Between
> > mainly Mario and myself and a few reports by others (nickoe,
> > reportingsjr) we have sorted out quite a few bugs and other
> > deficiencies but I think the only way to get more testing from users
> > is to merge the code. I believe that the new parsers all offer much
> > better specifications compliance compared to the old parsers and
> > the code is more robust. As an example, there is this post by a
> > user:
> >
> > https://forum.kicad.info/t/trouble-with-3d-models-vrml/2320/7
> >
> >  The user's models, D_Pak.wrl (VRML1) and D_Pakx.wrl (VRML2)
> > load and display correctly in the file preview which uses the new
> > parsers. In the legacy parsers, D_Pak.wrl causes a segfault and
> > D_Pakx.wrl does not display correctly. Note: the 3d_initial_merge
> > branch still uses the legacy 3DViewer so the 3DViewer will segfault
> > on the D_Pak.wrl model, but for me this only serves as a reminder
> > of some of the improvements gained with the new 3D plugin system.
> >
> > - 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] Python functionality on Windows

[Torsten Hüter]

Hi Wayne,
 
this is of course true, but seems to be a misunderstanding - he needs 
pythonw.exe but not a python variant that is build with MSVC.
And this executable is also provided by MSYS2, just look in the folder 
msys64\mingw64\bin for instance (python2w.exe).
The difference is explained here: https://docs.python.org/2/using/windows.html
 
All other libraries that he needs are there as well (python2-pip, wxPython 
etc.). I've shortly tried to install odfpy with pip on MSYS2 and that was 
working well. So that's perhaps mainly an issue for the Windows package 
maintainers.
 
In my opinion - ideally a concept should be written, which Python libraries 
should be included / what should be wrapped by SWIG/Python.
 
Thanks,
Torsten
 

Konstantin,

I have no interest in using the native windows Python because the amount
of effort to implement this would not be trivial. We would have to
completely overhaul the build system for wxPython and the kicad python
scripting on windows builds to compile an link against the the native
system Python libraries which are built with MSVC. I don't know if you
have ever attempted to do this but I have and it's a nightmare to build
native Python libraries with the GNU tool chain on Windows. I'm not
saying that if someone provided a complete native python build solution
that didn't break the msys2/mingw builds that I wouldn't accept it but
I'm not going to work on it and I would rather the kicad developers work
on more pressing matters. If you want an integrated Python solution,
try installing msys2/mingw32 (or mingw64) and build and install kicad
from source. This way you have a full python implementation along with
pip and setuptool support. This is what I use and it works almost as
well as the native window Python solution.

Cheers,

Wayne
 

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

Re: [Kicad-developers] [PATCH] Fix lp:1529159

[Bernhard Stegmaier]

> On 22 Feb 2016, at 22:09, Wayne Stambaugh  wrote:
> 
> I'm not.  I will add a note about the wxWidgets bug so whenever we set
> the minimum wxWidgets version to 3.0.3 or later, it can be removed.

Just noticed your commit… unfortunately, the comment is very misleading now.

The mentioned
   http://trac.wxwidgets.org/ticket/16329
of the bug report has nothing to do with the zero sized bitmap problem… I 
didn’t find any existing wxWidgets ticket for the zero size problem.


Regards,
Bernhard

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

Re: [Kicad-developers] [PATCH] Fix lp:1529159

[Wayne Stambaugh]

On 2/22/2016 4:07 PM, Clemens Koller wrote:
> Hello, Wayne!
> 
> On 2016-02-22 20:23, Wayne Stambaugh wrote:
>> Anyone else see any issues with this patch?  I just tested it on windows
>> and I didn't see any issues.  Since this only seems to be an issue on
>> OSX, maybe we should wrap this in an #ifdef/#endif as much as I don't
>> like them.
> 
> I don't see a reason to wrap that. Don't draw a zero sized object seems
> to be fair. I would even consider to emit a warning in debug mode when this
> triggers...

I'm not.  I will add a note about the wxWidgets bug so whenever we set
the minimum wxWidgets version to 3.0.3 or later, it can be removed.

> 
> Regards,
> 
> Clemens
> 
>>
>> On 2/20/2016 8:13 AM, Bernhard Stegmaier wrote:
>>> Hi,
>>>
>>> attached a patch to fix lp:1529159, it is still reproducible with a current 
>>> wxWidgets master.
>>> Credits go to the author of the bug report, I just did change the condition 
>>> to immediately return if one of the sizes is zero (and create the patch).
>>>
>>> Of course, it could be argued if the real fix for this should go into OS X 
>>> wxWidgets (I guess it should), but not trying to draw something zero sized 
>>> at all doesn’t seem like a bad thing in general.
>>>
>>>
>>> Regards,
>>> Bernhard
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://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 lp:1529159

[Clemens Koller]

Hello, Wayne!

On 2016-02-22 20:23, Wayne Stambaugh wrote:
> Anyone else see any issues with this patch?  I just tested it on windows
> and I didn't see any issues.  Since this only seems to be an issue on
> OSX, maybe we should wrap this in an #ifdef/#endif as much as I don't
> like them.

I don't see a reason to wrap that. Don't draw a zero sized object seems
to be fair. I would even consider to emit a warning in debug mode when this
triggers...

Regards,

Clemens

> 
> On 2/20/2016 8:13 AM, Bernhard Stegmaier wrote:
>> Hi,
>>
>> attached a patch to fix lp:1529159, it is still reproducible with a current 
>> wxWidgets master.
>> Credits go to the author of the bug report, I just did change the condition 
>> to immediately return if one of the sizes is zero (and create the patch).
>>
>> Of course, it could be argued if the real fix for this should go into OS X 
>> wxWidgets (I guess it should), but not trying to draw something zero sized 
>> at all doesn’t seem like a bad thing in general.
>>
>>
>> Regards,
>> Bernhard
>>
>>
>>
>>
>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

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

Re: [Kicad-developers] 3D refactor

[easyw]

just to let you know there are some kicad's users asking for what I 
suggested


1) pivot center of rotation
https://forum.kicad.info/t/3d-new-library-for-mechanical-cad-exporting-and-enclosure-design/1763/20

2) show/hide enclosures
https://forum.kicad.info/t/3d-new-library-for-mechanical-cad-exporting-and-enclosure-design/1763/33

Regards
Maurice

___
Mailing list: https://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 1545468] Re: CK1202_V1.pcb: distribution of non-free file in examples

[Alexander Lunev]

OK. I think we can rely on a preserved copy of the file in the Kicad repo 
history where from it can be recovered in case of unavailability of the file in 
the origin (http://www.pcadbegin.webtm.ru/schetchik.php?scach=1). New demo 
files are fine, however CK1202_V1.pcb, as I said, is still used for regression 
testing in case of pcad2kicad source code modification/enhancement.

Best regards,Alexander.

On Monday, February 22, 2016 10:41 PM, jp charras  
wrote:
 

 Le 22/02/2016 20:07, Alexander Lunev a écrit :
> Hi all, I do not fully understand why this file should be removed. 
> Jean-Pierre, initially YOU suggested me to upload 1 or 2 demo board
> files to allow developers to test pcad2kicad import (see your e-mail
> dated 28-Jun-2012). I considered your suggestion reasonable and tried
> to search for demo files in the Internet. I found only one here:
> http://www.pcadbegin.webtm.ru/schetchik.php?scach=1 To commit this
> demo file, first I requested a permission from the author, Andrey
> Manin. I got his permission by e-mail on 06-Aug-2012. As I uploaded
> that demo file, it has been already using for regression testing.
> 
> Best regards, Alexander.

Yes, I remember, and thanks you to take the time to find an available
test file.

Looks like sometimes, Linux maintainers are picky about licenses.

Because the license of this file is unknown (no info about this license
on the Andrey Manin's site)  and to avoid questions about licenses of a
few files again and again, I removed it although I am thinking there is
no problem about the license of this file.

(An other doc file was removed for this reason)

 However the link to this file is in the file
pcbnew/pcad2kicad_plugin/files.txt.

We also have now a few other files available on the kicad bug tracker,
so this file, which was very useful for testers some times ago, is now
not so important for tests (it was more important when the plug-in was
written).

-- 
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] New Feature: Touchpad Panning

[Bernhard Stegmaier]

The retina patch is unrelated.
It should (still) apply without any conflicts (I guess/hope, I didn’t try).
If it doesn’t, I can generate a new one.

Attached a new patch against rev6578.


Regards,
Bernhard



touchpad-panning.patch
Description: Binary data



> On 22.02.2016, at 16:42, Wayne Stambaugh  wrote:
> 
> Bernhard,
> 
> I'll wait until this evening that way I can test it on linux and
> windows.  Does the touchpad panning patch need to be applied before the
> retina patch?
> 
> Thanks,
> 
> Wayne
> 
> On 2/22/2016 10:08 AM, Bernhard Stegmaier wrote:
>> Sure, no problem. I'll send an updated version this evening.
>> 
>> You also could pull it directly from
>>  https://github.com/bstegmaier75/kicad-source-mirror/tree/touchpad-panning
>> Updated this weekend...
>> 
>> 
>> Regards,
>> Bernhard
>> 
>> On 2016-02-22 15:34, Wayne Stambaugh wrote:
>>> Bernhard,
>>> 
>>> This patch no longer applies cleanly.  Would you please rebase it so I
>>> can test it?
>>> 
>>> Thanks,
>>> 
>>> Wayne
>>> 
>>> On 2/20/2016 7:56 AM, Bernhard Stegmaier wrote:
 Any plans/comments whether this one will get merged?
 
> On 12.02.2016, at 20:38, Bernhard Stegmaier
>  wrote:
> 
> Hi all,
> 
> attached a patch to add a new feature “touchpad panning”.
> When enabled, you can pan in x/y-direction by just using usual
> 2-finger touchpad gestures without shift/ctrl modifiers instead of
> scroll wheel zoom.
> 
> It is particularly useful on OS X, because any Apple touchpad/mouse
> supports these 2-finger gestures (1-finger with MagicMouse).
> It makes KiCad behave more like any other regular OS X application
> and has been requested for some time by some/many OS X users.
> 
> It is built on top of platform independent wxWidgets functions, so
> it should work also on any other platform and device supporting x/y
> mousewheel events and is not restricted to OS X.
> 
> I added preference options to each application like the other
> pan/zoom options (and a menu entry for 3d-Viewer).
> If disabled, panning/scrolling should work the same as without the
> patch.
> 
> I tested it on
> * OS X with touchpad, MagicMouse, MightMouse
> * OS X with normal PC mouse
> * Linux running inside a VirtualBox on OS X (debian testing with
> xfce desktop)
> 
> I would be great if someone could test it on native Windows/Linux
> with a touchpad.
> It should be OK, the only problem that I could imagine is that
> panning speed might have to be adapted (frequency/granularity of
> mousewheel events could be different between OS X and other
> platforms, there are already some platform specific adaptions in the
> code before the patch).
> 
> Of course, any other feedback is also welcome!
> 
> Note:
> This patch contains the patch discussed in the other mail thread,
> which disables framerate throttling in GAL on OS X.
> 
> 
> Regards,
> Bernhard
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
 
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp
 
>>> 
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://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 refactor

[Cirilo Bernardo]

On Tue, Feb 23, 2016 at 3:00 AM, Wayne Stambaugh 
wrote:

> Cirilo,
>
> I have one last change request that I missed in my previous review.
> Please change your debugging output method.  Windows apps have no
> concept of stdout even when run from the command line.  wxLogTrace is
> the preferred method for debugging output.  It solves two problems.  The
> debugging strings are redirected to the correct output on all supported
> platforms and the debugging output is turned off by default.  Turning on
> the debugging output is as simple as:
>
> export WXTRACE="SOME_DEBUGGING_OUTPUT_TO_ENABLE"
>
> The is handy so I don't have to sift through everyone's debugging output
> to find what I'm looking for.  You just need to pick a unique string not
> used by any other kicad wxLogTrace calls to enable tracing of your
> debugging output.
>

No problem, I'll get to work on that.

- Cirilo


>
> I'm still not thrilled about using a list of paths to search for 3D
> model files.  This is broken in the same way the the component library
> search path ordering is broken in Eeschema.  Since it's no worse than
> what we have now and fixes some of the current 3D model file loading
> issues, I'm willing to commit it but in the long run I think we really
> need to think about this more carefully and come up with a better way to
> resolve 3D model file names.
>
> Cheers,
>
> Wayne
>
> On 2/21/2016 7:28 PM, Cirilo Bernardo wrote:
> > Hi Folks,
> >
> >  Any thoughts on merging the 3d_initial_merge branch? Between
> > mainly Mario and myself and a few reports by others (nickoe,
> > reportingsjr) we have sorted out quite a few bugs and other
> > deficiencies but I think the only way to get more testing from users
> > is to merge the code. I believe that the new parsers all offer much
> > better specifications compliance compared to the old parsers and
> > the code is more robust. As an example, there is this post by a
> > user:
> >
> > https://forum.kicad.info/t/trouble-with-3d-models-vrml/2320/7
> >
> >  The user's models, D_Pak.wrl (VRML1) and D_Pakx.wrl (VRML2)
> > load and display correctly in the file preview which uses the new
> > parsers. In the legacy parsers, D_Pak.wrl causes a segfault and
> > D_Pakx.wrl does not display correctly. Note: the 3d_initial_merge
> > branch still uses the legacy 3DViewer so the 3DViewer will segfault
> > on the D_Pak.wrl model, but for me this only serves as a reminder
> > of some of the improvements gained with the new 3D plugin system.
> >
> > - 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] [Bug 1545468] Re: CK1202_V1.pcb: distribution of non-free file in examples

[jp charras]

Le 22/02/2016 20:07, Alexander Lunev a écrit :
> Hi all, I do not fully understand why this file should be removed. 
> Jean-Pierre, initially YOU suggested me to upload 1 or 2 demo board
> files to allow developers to test pcad2kicad import (see your e-mail
> dated 28-Jun-2012). I considered your suggestion reasonable and tried
> to search for demo files in the Internet. I found only one here:
> http://www.pcadbegin.webtm.ru/schetchik.php?scach=1 To commit this
> demo file, first I requested a permission from the author, Andrey
> Manin. I got his permission by e-mail on 06-Aug-2012. As I uploaded
> that demo file, it has been already using for regression testing.
> 
> Best regards, Alexander.

Yes, I remember, and thanks you to take the time to find an available
test file.

Looks like sometimes, Linux maintainers are picky about licenses.

Because the license of this file is unknown (no info about this license
on the Andrey Manin's site)  and to avoid questions about licenses of a
few files again and again, I removed it although I am thinking there is
no problem about the license of this file.

(An other doc file was removed for this reason)

 However the link to this file is in the file
pcbnew/pcad2kicad_plugin/files.txt.

We also have now a few other files available on the kicad bug tracker,
so this file, which was very useful for testers some times ago, is now
not so important for tests (it was more important when the plug-in was
written).

-- 
Jean-Pierre CHARRAS

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

Re: [Kicad-developers] [PATCH] Fix lp:1529159

[Wayne Stambaugh]

Anyone else see any issues with this patch?  I just tested it on windows
and I didn't see any issues.  Since this only seems to be an issue on
OSX, maybe we should wrap this in an #ifdef/#endif as much as I don't
like them.

On 2/20/2016 8:13 AM, Bernhard Stegmaier wrote:
> Hi,
> 
> attached a patch to fix lp:1529159, it is still reproducible with a current 
> wxWidgets master.
> Credits go to the author of the bug report, I just did change the condition 
> to immediately return if one of the sizes is zero (and create the patch).
> 
> Of course, it could be argued if the real fix for this should go into OS X 
> wxWidgets (I guess it should), but not trying to draw something zero sized at 
> all doesn’t seem like a bad thing in general.
> 
> 
> Regards,
> Bernhard
> 
> 
> 
> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

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

Re: [Kicad-developers] [PATCH] fix position of text and refdes from PCAD import

[Wayne Stambaugh]

Eldar,

There is something unsettling about your patch.  Why are there different
scalars applied when calculating the length of the text versus the
height?  This would suggest the PCAD file format does not use the same
units for text height, text width, and text position.  It appears to me
that you have determined the text position and size scalars by comparing
the KiCad output with the output of some other EDA application.  If the
PCAD units are mm, inches, mils, etc, the size and position numbers
should be scaled to nanometers which are the units used in Pcbnew.  When
I see things like / 3, / 1.8, and / 1.4 in two consecutive lines of code
translating coordinates, that raises a red flag.

Cheers,

Wayne

On 2/22/2016 11:56 AM, Eldar Khayrullin wrote:
> Hello. Patch attached.
> P.S. need work to correct a justification of text and text size (I do) 
> 
> 
> ___
> Mailing list: https://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: added QFNFootprintWizard

[Mikael Arguedas]

Hi guys,

Here is an updated version of the script including the thermal vias (can be
enabled/disabled using a boolean parameter).

Regards,
Mikael

On Fri, Feb 19, 2016 at 9:51 AM, jp charras  wrote:

> Le 18/02/2016 20:09, Mikael Arguedas a écrit :
> > Hi guys,
> >
> > The patches this plugin was relying on have all been merged.
> > I updated this patch to accordingly.
> >
> > Cheers,
> > Mikael
> >
> > On Tue, Feb 16, 2016 at 3:34 PM, Mikael Arguedas <
> mikael.argue...@gmail.com>
> > wrote:
> >
> >> Hi guys,
> >>
> >> Here is an updated version of this new qfn wizard.
> >> Changes:
> >>  - fixed thermal pad numbering when no subdivision are requested (epad
> >> subdiv x= 0|1 or epad subdiv y =0|1). thanks to Peter Horvath testing.
> >> - set the attribute to SMD
> >> - round the courtyard to land on a 0.05mm grid (this feature relies on
> the
> >> patch of this thread
> >> )
> >>
> >> Could you please let us know if you want to integrate/support wizards
> for
> >> components having thermal pads? I noticed that Maurice worked on similar
> >> kind of plugins in the past but they have never been merged.
> >>
> >> If you do want to integrate them, Peter and I are willing to add several
> >> features to this plugin and it's equivalent for SON footprints
> "son_wizard"
> >> plugin:
> >> - placing thermal vias centered on the thermal pad array
> >> - add a possibility of "outward extension" of the pad for people willing
> >> to generate HandSoldering version of the footprints
> >>
> >> Thanks!
> >> Mikael
>
>
> I am thinking an option to build the exposed pad with thermal vias (for
> us, small round pads inside the EPad), is a very interesting feature.
>
> Previous pythons plugons scripts I tried did not work well.
>
> 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
>
=== modified file 'pcbnew/scripting/plugins/PadArray.py'
--- pcbnew/scripting/plugins/PadArray.py	2015-10-31 11:54:48 +
+++ pcbnew/scripting/plugins/PadArray.py	2016-02-22 18:11:53 +
@@ -168,6 +168,12 @@
 pad.SetPadName(self.GetName(x,y))
 self.AddPad(pad)
 
+class EPADGridArray(PadGridArray):
+
+  def NamingFunction(self, nx, ny):
+return self.firstPadNum
+
+
 
 class PadZGridArray(PadArray):
 

=== added file 'pcbnew/scripting/plugins/qfn_wizard.py'
--- pcbnew/scripting/plugins/qfn_wizard.py	1970-01-01 00:00:00 +
+++ pcbnew/scripting/plugins/qfn_wizard.py	2016-02-22 18:18:29 +
@@ -0,0 +1,173 @@
+#  This program is free software; you can redistribute it and/or modify
+#  it under the terms of the GNU General Public License as published by
+#  the Free Software Foundation; either version 2 of the License, or
+#  (at your option) any later version.
+#
+#  This program is distributed in the hope that it will be useful,
+#  but WITHOUT ANY WARRANTY; without even the implied warranty of
+#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+#  GNU General Public License for more details.
+#
+#  You should have received a copy of the GNU General Public License
+#  along with this program; if not, write to the Free Software
+#  Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+#  MA 02110-1301, USA.
+#
+
+from __future__ import division
+import pcbnew
+
+import HelpfulFootprintWizardPlugin as HFPW
+import PadArray as PA
+
+class QFNWizard(HFPW.HelpfulFootprintWizardPlugin):
+
+def GetName(self):
+return "QFN"
+
+def GetDescription(self):
+return "Quad Flat No-lead footprint wizard"
+
+def GenerateParameterList(self):
+self.AddParam("Pads", "n", self.uNatural, 100)
+self.AddParam("Pads", "pad pitch", self.uMM, 0.5)
+self.AddParam("Pads", "pad width", self.uMM, 0.25)
+self.AddParam("Pads", "pad length", self.uMM, 1.5)
+self.AddParam("Pads", "oval", self.uBool, True)
+self.AddParam("Pads", "thermal vias", self.uBool, True)
+self.AddParam("Pads", "epad subdiv x", self.uNatural, 2)
+self.AddParam("Pads", "epad subdiv y", self.uNatural, 2)
+
+self.AddParam("Package", "package width", self.uMM, 14)
+self.AddParam("Package", "package height", self.uMM, 14)
+self.AddParam("Package", "courtyard margin", self.uMM, 1)
+
+def CheckParameters(self):
+self.CheckParamInt("Pads", "*n", is_multiple_of=4)
+self.CheckParamBool("Pads", "*oval")
+
+def GetValue(self):
+return "QFN_%d" % self.parameters["Pads"]["*n"]
+
+def BuildThisFootprint(self):
+pads = self.parameters["Pads"]
+
+pad_pitch = pads["pad pitch"]
+pad_length = pads["pad length"]
+pad_width = pads["pad width"]
+
+ 

Re: [Kicad-developers] S-Expression schematic format specification

[Wayne Stambaugh]

Russell,

Attached is the latest revision of the new schematic and component
library file formats.  Please search the developers mailing list as this
has been discussed to death so you don't ask for the same changes that
have already been discussed.  I have asked everyone to hold off
commenting on them until I announce that I am ready to resume the
discussion for the final draft.  There is plenty of reading to do to
cover all of the prior discussion.

Cheers,

Wayn

On 2/20/2016 6:23 AM, Russell Oliver wrote:
> Hi All, 
> 
> I was looking through the roadmap for Kicad 5 and saw that work is being
> done on the new schematic format. I was wondering if the draft
> specification is available anywhere and whether I could assist in
> developing it. 
> 
> 
> Regards
> Russell Oliver
> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


eeschema_schematic_sexpr_file_format_EN.odt
Description: application/vnd.oasis.opendocument.text


eeschema_symbol_library_sexpr_format_EN.odt
Description: application/vnd.oasis.opendocument.text
___
Mailing list: https://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 position of text and refdes from PCAD import

[Eldar Khayrullin]

Next patch continue fixing bug https://bugs.launchpad.net/kicad/+bug/1547822

> On Feb 22 2016, at 7:55 pm, Eldar Khayrullin
eldar.khayrul...@mail.ru wrote:  
Hello. Patch attached.  
P.S. need work to correct a justification of text and text size (I do)  

>From 766b6e5b5859b8209f5fac79655295aa057a671f Mon Sep 17 00:00:00 2001
From: Eldar Khayrullin 
Date: Mon, 22 Feb 2016 20:38:22 +0300
Subject: [PATCH] Fix bug #1547822: refdes and value fields are set to
 invisible in new PCAD file format

---
 pcbnew/pcad2kicadpcb_plugin/pcb.cpp | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/pcbnew/pcad2kicadpcb_plugin/pcb.cpp b/pcbnew/pcad2kicadpcb_plugin/pcb.cpp
index 41f79d2..6d00cbd 100644
--- a/pcbnew/pcad2kicadpcb_plugin/pcb.cpp
+++ b/pcbnew/pcad2kicadpcb_plugin/pcb.cpp
@@ -166,7 +166,7 @@ void PCB::SetTextProperty( XNODE*   aNode, TTEXTVALUE* aTextValue,
wxString aActualConversion )
 {
 XNODE*  tNode, * t1Node;
-wxStringn, pn, propValue, str;
+wxStringn, nnew, pn, propValue, str;
 
 // aNode is pattern now
 tNode   = aNode;
@@ -199,6 +199,7 @@ void PCB::SetTextProperty( XNODE*   aNode, TTEXTVALUE* aTextValue,
 str = aTextValue->text;
 str.Trim( false );
 str.Trim( true );
+nnew= n; // new file version
 n   = n + wxT( ' ' ) + str; // changed in new file version.
 tNode   = NULL;
 }
@@ -219,7 +220,7 @@ void PCB::SetTextProperty( XNODE*   aNode, TTEXTVALUE* aTextValue,
 propValue.Trim( false );
 propValue.Trim( true );
 
-if( propValue == n )
+if( propValue == n || propValue == nnew )
 break;
 
 tNode = tNode->GetNext();
-- 
2.5.0

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

[Kicad-developers] [PATCH] fix position of text and refdes from PCAD import

[Eldar Khayrullin]

Hello. Patch attached.  
P.S. need work to correct a justification of text and text size (I do)  

>From f5647e191d15e833164076fcd8f35981513e4a98 Mon Sep 17 00:00:00 2001
From: Eldar Khayrullin 
Date: Mon, 22 Feb 2016 19:46:16 +0300
Subject: [PATCH] Fix position of text and refdes for PCAD import

---
 pcbnew/pcad2kicadpcb_plugin/pcad2kicad_common.cpp | 64 ++-
 pcbnew/pcad2kicadpcb_plugin/pcad2kicad_common.h   |  2 +-
 pcbnew/pcad2kicadpcb_plugin/pcb_component.h   |  6 +--
 pcbnew/pcad2kicadpcb_plugin/pcb_module.cpp| 17 --
 pcbnew/pcad2kicadpcb_plugin/pcb_text.cpp  | 12 +++--
 5 files changed, 50 insertions(+), 51 deletions(-)

diff --git a/pcbnew/pcad2kicadpcb_plugin/pcad2kicad_common.cpp b/pcbnew/pcad2kicadpcb_plugin/pcad2kicad_common.cpp
index f588bbc..5fbae08 100644
--- a/pcbnew/pcad2kicadpcb_plugin/pcad2kicad_common.cpp
+++ b/pcbnew/pcad2kicadpcb_plugin/pcad2kicad_common.cpp
@@ -368,47 +368,37 @@ void SetFontProperty( XNODE*aNode,
 }
 
 
-void CorrectTextPosition( TTEXTVALUE* aValue, int aRotation )
+void CorrectTextPosition( TTEXTVALUE* aValue )
 {
-aValue->correctedPositionX  = aValue->textPositionX;
-aValue->correctedPositionY  = aValue->textPositionY;
-aValue->correctedPositionY  = aValue->correctedPositionY - KiROUND(
-(double) aValue->textHeight / 3.0 );
-aValue->correctedPositionX = aValue->correctedPositionX +
- KiROUND( ( (double) aValue->text.Len() /
-1.4 ) * ( (double) aValue->textHeight / 1.8 ) );
-
-if( aRotation == 900 )
-{
-aValue->correctedPositionX  = -aValue->textPositionY;
-aValue->correctedPositionY  = aValue->textPositionX;
-aValue->correctedPositionX  = aValue->correctedPositionX + KiROUND(
-(double) aValue->textHeight / 3.0 );
-aValue->correctedPositionY = aValue->correctedPositionY +
- KiROUND( ( (double) aValue->text.Len() /
-1.4 ) * ( (double) aValue->textHeight / 1.8 ) );
-}
+int cm = aValue->mirror ? -1 : 1;
+int cl = KiROUND( ( (double) aValue->text.Len() / 1.4 ) *
+  ( (double) aValue->textHeight / 1.8 ) );
+int ch = KiROUND( (double) aValue->textHeight / 3.0 );
 
-if( aRotation == 1800 )
-{
-aValue->correctedPositionX  = -aValue->textPositionX;
-aValue->correctedPositionY  = -aValue->textPositionY;
-aValue->correctedPositionY  = aValue->correctedPositionY +
-  KiROUND( (double) aValue->textHeight / 3.0 );
-aValue->correctedPositionX = aValue->correctedPositionX -
- KiROUND( ( (double) aValue->text.Len() /
-1.4 ) * ( (double) aValue->textHeight / 1.8 ) );
-}
+aValue->correctedPositionX = aValue->textPositionX;
+aValue->correctedPositionY = aValue->textPositionY;
 
-if( aRotation == 2700 )
+/* standart justification (bottom left corner) */
+switch( aValue->textRotation )
 {
-aValue->correctedPositionX  = aValue->textPositionY;
-aValue->correctedPositionY  = -aValue->textPositionX;
-aValue->correctedPositionX  = aValue->correctedPositionX +
-  KiROUND( (double) aValue->textHeight / 1.0 );
-aValue->correctedPositionY = aValue->correctedPositionY -
- KiROUND( ( (double) aValue->text.Len() /
-3.4 ) * ( (double) aValue->textHeight / 1.8 ) );
+case 0:
+aValue->correctedPositionX += cl * cm;
+aValue->correctedPositionY -= ch;
+break;
+case 900:
+aValue->correctedPositionX -= ch * cm;
+aValue->correctedPositionY -= cl;
+break;
+case 1800:
+aValue->correctedPositionX -= cl * cm;
+aValue->correctedPositionY += ch;
+break;
+case 2700:
+aValue->correctedPositionX += ch * cm;
+aValue->correctedPositionY += cl;
+break;
+default:
+break;
 }
 }
 
diff --git a/pcbnew/pcad2kicadpcb_plugin/pcad2kicad_common.h b/pcbnew/pcad2kicadpcb_plugin/pcad2kicad_common.h
index 30ce190..af758ed 100644
--- a/pcbnew/pcad2kicadpcb_plugin/pcad2kicad_common.h
+++ b/pcbnew/pcad2kicadpcb_plugin/pcad2kicad_common.h
@@ -77,7 +77,7 @@ extern void SetFontProperty( XNODE* aNode,
  TTEXTVALUE*aTextValue,
  wxString   aDefaultMeasurementUnit,
  wxString   aActualConversion );
-extern void CorrectTextPosition( TTEXTVALUE* aValue, int aRotation );
+extern void CorrectTextPosition( TTEXTVALUE* aValue );
 
 extern XNODE*   FindNode( XNODE* aChild, wxString aTag );
 

Re: [Kicad-developers] Does auto placement feature still exist?

[Nick Østergaard]

Yes, but only in the legacy (default) canvas IIRC.

2016-02-19 17:18 GMT+01:00 Dan Walmsley :
> Iv seen some tutorials online suggesting kicad *had* an autoplacement
> feature, but iv not been able to get this to work in current version.
>
> Does this feature still exist?
>
> Thanks
>
> Dan
>
> ___
> Mailing list: https://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 01/19] Replace DrawPinShape enum with PinShape

[jp charras]

Le 22/02/2016 14:40, Simon Richter a écrit :
> Hi,
> 
> On 19.02.2016 18:27, jp charras wrote:
> 
>> Could you modify your changes to be compliant with our coding
>> style policy, when changing enum names?
> 
> Sure -- do we really want enum names to be uppercase like class
> names, or is that going to lead to confusion?

We try to have only one coding style.
Currently the coding style for enum is (see coding-style-policy.md):

"## 2.1 Class, Type Definitions, Name Space, and Macro Names ##
{#definitions}
Class, typedef, enum, name space, and macro names should be comprised of
all capital letters."

Confusion exists more surely when there is more than one coding style
in sources.

Of course, due to the fact a lot of code was written before the coding
style doc, you can find enums and class names in lower chars.
But when modifying the enum or class names, or creating new
enum/classes, using our Kicad current coding style is a good thing.

Confusion can be minimized by good names (too short names create
confusion), for instance some enums used to define a type of item use
names line PIN_TYPE_T  (_T for item Type, in this example).

I do not yet know a coding style which is able to avoid any confusion.

> 
>> Also can you group yours patches relative to the same thing (5
>> patches to move an enum in a header and change its name is too
>> much for me).
> 
> Can do -- my goal was to keep the reviews short and independent -- 
> applying them in order gives a working state after every patch, so
> if there is only time to look at one, this doesn't break anything,
> and as long as I keep them separately in my repository, I can also
> still easily rebase stuff in case one of them is rejected.
> 
> The general direction I'm heading off is:
> 
> - keep enum values in a header of at least similar name so they can
> be easily found - keep UI code (lookup of localized names and
> bitmaps) separate from data structures - create dedicated widget
> classes that initialize themselves and enforce typesafe accesses
> 
> If all of these sound good, I can merge the changes to have fewer 
> commits in total.
> 
> Simon

Currently I have no objection.

-- 
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] 3D refactor

[Wayne Stambaugh]

Cirilo,

I have one last change request that I missed in my previous review.
Please change your debugging output method.  Windows apps have no
concept of stdout even when run from the command line.  wxLogTrace is
the preferred method for debugging output.  It solves two problems.  The
debugging strings are redirected to the correct output on all supported
platforms and the debugging output is turned off by default.  Turning on
the debugging output is as simple as:

export WXTRACE="SOME_DEBUGGING_OUTPUT_TO_ENABLE"

The is handy so I don't have to sift through everyone's debugging output
to find what I'm looking for.  You just need to pick a unique string not
used by any other kicad wxLogTrace calls to enable tracing of your
debugging output.

I'm still not thrilled about using a list of paths to search for 3D
model files.  This is broken in the same way the the component library
search path ordering is broken in Eeschema.  Since it's no worse than
what we have now and fixes some of the current 3D model file loading
issues, I'm willing to commit it but in the long run I think we really
need to think about this more carefully and come up with a better way to
resolve 3D model file names.

Cheers,

Wayne

On 2/21/2016 7:28 PM, Cirilo Bernardo wrote:
> Hi Folks,
> 
>  Any thoughts on merging the 3d_initial_merge branch? Between
> mainly Mario and myself and a few reports by others (nickoe,
> reportingsjr) we have sorted out quite a few bugs and other
> deficiencies but I think the only way to get more testing from users
> is to merge the code. I believe that the new parsers all offer much
> better specifications compliance compared to the old parsers and
> the code is more robust. As an example, there is this post by a
> user:
> 
> https://forum.kicad.info/t/trouble-with-3d-models-vrml/2320/7
> 
>  The user's models, D_Pak.wrl (VRML1) and D_Pakx.wrl (VRML2)
> load and display correctly in the file preview which uses the new
> parsers. In the legacy parsers, D_Pak.wrl causes a segfault and
> D_Pakx.wrl does not display correctly. Note: the 3d_initial_merge
> branch still uses the legacy 3DViewer so the 3DViewer will segfault
> on the D_Pak.wrl model, but for me this only serves as a reminder
> of some of the improvements gained with the new 3D plugin system.
> 
> - 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] [PATCH] New Feature: Touchpad Panning

[Wayne Stambaugh]

Bernhard,

I'll wait until this evening that way I can test it on linux and
windows.  Does the touchpad panning patch need to be applied before the
retina patch?

Thanks,

Wayne

On 2/22/2016 10:08 AM, Bernhard Stegmaier wrote:
> Sure, no problem. I'll send an updated version this evening.
> 
> You also could pull it directly from
>   https://github.com/bstegmaier75/kicad-source-mirror/tree/touchpad-panning
> Updated this weekend...
> 
> 
> Regards,
> Bernhard
> 
> On 2016-02-22 15:34, Wayne Stambaugh wrote:
>> Bernhard,
>>
>> This patch no longer applies cleanly.  Would you please rebase it so I
>> can test it?
>>
>> Thanks,
>>
>> Wayne
>>
>> On 2/20/2016 7:56 AM, Bernhard Stegmaier wrote:
>>> Any plans/comments whether this one will get merged?
>>>
 On 12.02.2016, at 20:38, Bernhard Stegmaier
  wrote:

 Hi all,

 attached a patch to add a new feature “touchpad panning”.
 When enabled, you can pan in x/y-direction by just using usual
 2-finger touchpad gestures without shift/ctrl modifiers instead of
 scroll wheel zoom.

 It is particularly useful on OS X, because any Apple touchpad/mouse
 supports these 2-finger gestures (1-finger with MagicMouse).
 It makes KiCad behave more like any other regular OS X application
 and has been requested for some time by some/many OS X users.

 It is built on top of platform independent wxWidgets functions, so
 it should work also on any other platform and device supporting x/y
 mousewheel events and is not restricted to OS X.

 I added preference options to each application like the other
 pan/zoom options (and a menu entry for 3d-Viewer).
 If disabled, panning/scrolling should work the same as without the
 patch.

 I tested it on
 * OS X with touchpad, MagicMouse, MightMouse
 * OS X with normal PC mouse
 * Linux running inside a VirtualBox on OS X (debian testing with
 xfce desktop)

 I would be great if someone could test it on native Windows/Linux
 with a touchpad.
 It should be OK, the only problem that I could imagine is that
 panning speed might have to be adapted (frequency/granularity of
 mousewheel events could be different between OS X and other
 platforms, there are already some platform specific adaptions in the
 code before the patch).

 Of course, any other feedback is also welcome!

 Note:
 This patch contains the patch discussed in the other mail thread,
 which disables framerate throttling in GAL on OS X.


 Regards,
 Bernhard

 

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

___
Mailing list: https://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 functionality on Windows

[Константин Барановский]

>
> Wayne Stambaugh:


> I have no interest in using the native windows Python because the amount
> of effort to implement this would not be trivial.  We would have to
> completely overhaul the build system for wxPython and the kicad python
> scripting on windows builds to compile an link against the the native
> system Python libraries which are built with MSVC...


Ok, thank you Wayne. Now I see that better still to use system-wide python
installation.

Regards, Konstantin.
___
Mailing list: https://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] New Feature: Touchpad Panning

[Bernhard Stegmaier]

Sure, no problem. I'll send an updated version this evening.

You also could pull it directly from
  
https://github.com/bstegmaier75/kicad-source-mirror/tree/touchpad-panning

Updated this weekend...


Regards,
Bernhard

On 2016-02-22 15:34, Wayne Stambaugh wrote:

Bernhard,

This patch no longer applies cleanly.  Would you please rebase it so I
can test it?

Thanks,

Wayne

On 2/20/2016 7:56 AM, Bernhard Stegmaier wrote:

Any plans/comments whether this one will get merged?

On 12.02.2016, at 20:38, Bernhard Stegmaier  
wrote:


Hi all,

attached a patch to add a new feature “touchpad panning”.
When enabled, you can pan in x/y-direction by just using usual 
2-finger touchpad gestures without shift/ctrl modifiers instead of 
scroll wheel zoom.


It is particularly useful on OS X, because any Apple touchpad/mouse 
supports these 2-finger gestures (1-finger with MagicMouse).
It makes KiCad behave more like any other regular OS X application 
and has been requested for some time by some/many OS X users.


It is built on top of platform independent wxWidgets functions, so it 
should work also on any other platform and device supporting x/y 
mousewheel events and is not restricted to OS X.


I added preference options to each application like the other 
pan/zoom options (and a menu entry for 3d-Viewer).
If disabled, panning/scrolling should work the same as without the 
patch.


I tested it on
* OS X with touchpad, MagicMouse, MightMouse
* OS X with normal PC mouse
* Linux running inside a VirtualBox on OS X (debian testing with xfce 
desktop)


I would be great if someone could test it on native Windows/Linux 
with a touchpad.
It should be OK, the only problem that I could imagine is that 
panning speed might have to be adapted (frequency/granularity of 
mousewheel events could be different between OS X and other 
platforms, there are already some platform specific adaptions in the 
code before the patch).


Of course, any other feedback is also welcome!

Note:
This patch contains the patch discussed in the other mail thread, 
which disables framerate throttling in GAL on OS X.



Regards,
Bernhard



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



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



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


___
Mailing list: https://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] New Feature: Touchpad Panning

[Wayne Stambaugh]

Bernhard,

This patch no longer applies cleanly.  Would you please rebase it so I
can test it?

Thanks,

Wayne

On 2/20/2016 7:56 AM, Bernhard Stegmaier wrote:
> Any plans/comments whether this one will get merged?
> 
>> On 12.02.2016, at 20:38, Bernhard Stegmaier  wrote:
>>
>> Hi all,
>>
>> attached a patch to add a new feature “touchpad panning”.
>> When enabled, you can pan in x/y-direction by just using usual 2-finger 
>> touchpad gestures without shift/ctrl modifiers instead of scroll wheel zoom.
>>
>> It is particularly useful on OS X, because any Apple touchpad/mouse supports 
>> these 2-finger gestures (1-finger with MagicMouse). 
>> It makes KiCad behave more like any other regular OS X application and has 
>> been requested for some time by some/many OS X users.
>>
>> It is built on top of platform independent wxWidgets functions, so it should 
>> work also on any other platform and device supporting x/y mousewheel events 
>> and is not restricted to OS X.
>>
>> I added preference options to each application like the other pan/zoom 
>> options (and a menu entry for 3d-Viewer).
>> If disabled, panning/scrolling should work the same as without the patch.
>>
>> I tested it on
>> * OS X with touchpad, MagicMouse, MightMouse
>> * OS X with normal PC mouse
>> * Linux running inside a VirtualBox on OS X (debian testing with xfce 
>> desktop)
>>
>> I would be great if someone could test it on native Windows/Linux with a 
>> touchpad.
>> It should be OK, the only problem that I could imagine is that panning speed 
>> might have to be adapted (frequency/granularity of mousewheel events could 
>> be different between OS X and other platforms, there are already some 
>> platform specific adaptions in the code before the patch).
>>
>> Of course, any other feedback is also welcome!
>>
>> Note:
>> This patch contains the patch discussed in the other mail thread, which 
>> disables framerate throttling in GAL on OS X.
>>
>>
>> Regards,
>> Bernhard
>>
>> 
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

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

Re: [Kicad-developers] KiCad GUI Translation HOWTO error (docs.kicad-pcb.org)

[Marco Ciampa]

On Mon, Feb 22, 2016 at 12:03:16PM +0100, i...@elektroquark.com wrote:
> Hello,
> 
> In the KiCad GUI Translation HOWTO guide here:
> 
> http://docs.kicad-pcb.org/en/gui_translation_howto.html
> 
> Point 4.6, Keyword Configuration, is missing the "_HKI" key, so when
> translation with Poedit some text related to hotkeys are not loaded.

Nice catch, I'll add that, thanks!

Anyway, I already do not use poedit for po string update anymore but the
small script that I left on the root of the i18n repo. Probably it will
be added to the cmake build scripts to automate the strings update
procedure.

Regards,

--


Marco Ciampa

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

++
| GNU/Linux User  #78271 |
| FSFE fellow   #364 |
++


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

Re: [Kicad-developers] [PATCH] New Feature: Touchpad Panning

[Wayne Stambaugh]

On 2/22/2016 8:57 AM, Tomasz Wlostowski wrote:
> On 20.02.2016 13:56, Bernhard Stegmaier wrote:
>> Any plans/comments whether this one will get merged?
> 
> Hi Bernard,
> 
> I don't have a Mac, so I can't test the OSX changes myself, but as no
> one among the OSX Kicad has complained for the last 2 weeks, I'd vote
> for merging it...

Has any one tested it on windows and/or linux?  There are quite a few
changes that are not OSX specific so we need to make sure it doesn't
break the existing behavior before I commit it.  I'll try to test it
today on windows.

> 
> Cheers,
> Tom
>>
>>> On 12.02.2016, at 20:38, Bernhard Stegmaier  wrote:
>>>
>>> Hi all,
>>>
>>> attached a patch to add a new feature “touchpad panning”.
>>> When enabled, you can pan in x/y-direction by just using usual 2-finger 
>>> touchpad gestures without shift/ctrl modifiers instead of scroll wheel zoom.
>>>
>>> It is particularly useful on OS X, because any Apple touchpad/mouse 
>>> supports these 2-finger gestures (1-finger with MagicMouse). 
>>> It makes KiCad behave more like any other regular OS X application and has 
>>> been requested for some time by some/many OS X users.
>>>
>>> It is built on top of platform independent wxWidgets functions, so it 
>>> should work also on any other platform and device supporting x/y mousewheel 
>>> events and is not restricted to OS X.
>>>
>>> I added preference options to each application like the other pan/zoom 
>>> options (and a menu entry for 3d-Viewer).
>>> If disabled, panning/scrolling should work the same as without the patch.
>>>
>>> I tested it on
>>> * OS X with touchpad, MagicMouse, MightMouse
>>> * OS X with normal PC mouse
>>> * Linux running inside a VirtualBox on OS X (debian testing with xfce 
>>> desktop)
>>>
>>> I would be great if someone could test it on native Windows/Linux with a 
>>> touchpad.
>>> It should be OK, the only problem that I could imagine is that panning 
>>> speed might have to be adapted (frequency/granularity of mousewheel events 
>>> could be different between OS X and other platforms, there are already some 
>>> platform specific adaptions in the code before the patch).
>>>
>>> Of course, any other feedback is also welcome!
>>>
>>> Note:
>>> This patch contains the patch discussed in the other mail thread, which 
>>> disables framerate throttling in GAL on OS X.
>>>
>>>
>>> Regards,
>>> Bernhard
>>>
>>> 
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://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] New Feature: Touchpad Panning

[Tomasz Wlostowski]

On 20.02.2016 13:56, Bernhard Stegmaier wrote:
> Any plans/comments whether this one will get merged?

Hi Bernard,

I don't have a Mac, so I can't test the OSX changes myself, but as no
one among the OSX Kicad has complained for the last 2 weeks, I'd vote
for merging it...

Cheers,
Tom
> 
>> On 12.02.2016, at 20:38, Bernhard Stegmaier  wrote:
>>
>> Hi all,
>>
>> attached a patch to add a new feature “touchpad panning”.
>> When enabled, you can pan in x/y-direction by just using usual 2-finger 
>> touchpad gestures without shift/ctrl modifiers instead of scroll wheel zoom.
>>
>> It is particularly useful on OS X, because any Apple touchpad/mouse supports 
>> these 2-finger gestures (1-finger with MagicMouse). 
>> It makes KiCad behave more like any other regular OS X application and has 
>> been requested for some time by some/many OS X users.
>>
>> It is built on top of platform independent wxWidgets functions, so it should 
>> work also on any other platform and device supporting x/y mousewheel events 
>> and is not restricted to OS X.
>>
>> I added preference options to each application like the other pan/zoom 
>> options (and a menu entry for 3d-Viewer).
>> If disabled, panning/scrolling should work the same as without the patch.
>>
>> I tested it on
>> * OS X with touchpad, MagicMouse, MightMouse
>> * OS X with normal PC mouse
>> * Linux running inside a VirtualBox on OS X (debian testing with xfce 
>> desktop)
>>
>> I would be great if someone could test it on native Windows/Linux with a 
>> touchpad.
>> It should be OK, the only problem that I could imagine is that panning speed 
>> might have to be adapted (frequency/granularity of mousewheel events could 
>> be different between OS X and other platforms, there are already some 
>> platform specific adaptions in the code before the patch).
>>
>> Of course, any other feedback is also welcome!
>>
>> Note:
>> This patch contains the patch discussed in the other mail thread, which 
>> disables framerate throttling in GAL on OS X.
>>
>>
>> Regards,
>> Bernhard
>>
>> 
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


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

Re: [Kicad-developers] [PATCH 01/19] Replace DrawPinShape enum with PinShape

[Simon Richter]

Hi,

On 19.02.2016 18:27, jp charras wrote:

> Could you modify your changes to be compliant with our coding style
> policy, when changing enum names?

Sure -- do we really want enum names to be uppercase like class names,
or is that going to lead to confusion?

> Also can you group yours patches relative to the same thing (5 patches
> to move an enum in a header and change its name is too much for me).

Can do -- my goal was to keep the reviews short and independent --
applying them in order gives a working state after every patch, so if
there is only time to look at one, this doesn't break anything, and as
long as I keep them separately in my repository, I can also still easily
rebase stuff in case one of them is rejected.

The general direction I'm heading off is:

 - keep enum values in a header of at least similar name so they can be
easily found
 - keep UI code (lookup of localized names and bitmaps) separate from
data structures
 - create dedicated widget classes that initialize themselves and
enforce typesafe accesses

If all of these sound good, I can merge the changes to have fewer
commits in total.

   Simon



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

Re: [Kicad-developers] [PATCH] Separate ElectricPinType and TypeSheetLabel

[Simon Richter]

Hi,

On 19.02.2016 21:40, Wayne Stambaugh wrote:

> I asked JP to take a look at this patch for me and he went ahead and
> fixed it which caught me a bit off guard.  Apparently your patch had
> some issues in the ERC.  I apologize for the confusion.  I'm assuming
> you will have to revise your PinShape and electrical type patches to
> work with JP's changes.

JP's patch seems to be more correct -- my assumption was that if the
label orientation is copied to the ElectricalType field, it is also used
for that (because otherwise there'd be no point copying it).

If it isn't used, then simply using the enum type to make sure that no
incompatible enum values are assigned, and fixing the two instances
(init and sheet label orientation) is the right way to go.

In the long run, it might be nice to warn people about sheet labels with
the wrong orientation.

My other patches have been rebased on top, I can easily resubmit them.

   Simon




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

Re: [Kicad-developers] 3D refactor

[easyw]

Hi Cirilo,
I tested Mario branch and I found something that I think it would be 
nice to implement:


1) 3d-viewer 'Fit in Page' option doesn't fit correctly the board and 
moreover resets the zoom, but not the board orientation (as it is done 
in standard kicad 3d-viewer)

2) 3d-viewer-Render Option-Render material Properties
   doesn't work
I think is still an useful option because of the following reasons:
  a) a lot of 3d-models in official libs (not mine 3D MCAD libs) have 
bad material properties, so not implementing this feature will give you 
a lot of 'rumors' from kicad users
  b) when inspecting a board in 3d-viewer I don't like been 'flashed' 
from pads and pins reflex ... properties are useful only to get a 
realistic screenshot of the board and parts
  c) as I already mailed to Mario, disable material properties could be 
*very* useful for toggle the visibility of e.g. enclosure objects
  if you put an enclosure transparency value to 100%, it will not be 
displayed if material properties are on, but it will appear if the 
material properties are off... that will give kicad the ability to 
switch ON/OFF enclosure for a better mechanical design (ability that 
Altium has)
3) pivot center of rotation: it would be nice/necessary to add a pivot 
center of rotation for board an parts (as it is available in most (E)CAD 
sw) to let user to inspect objects on the perimeter of the board (option 
much more necessary when the board it is not small)

use zoom 'Fit in Page' to reset the pivot

Regards
Maurice


On 22/02/2016 01.28, Cirilo Bernardo wrote:

Hi Folks,

  Any thoughts on merging the 3d_initial_merge branch? Between
mainly Mario and myself and a few reports by others (nickoe,
reportingsjr) we have sorted out quite a few bugs and other
deficiencies but I think the only way to get more testing from users
is to merge the code. I believe that the new parsers all offer much
better specifications compliance compared to the old parsers and
the code is more robust. As an example, there is this post by a
user:

https://forum.kicad.info/t/trouble-with-3d-models-vrml/2320/7

  The user's models, D_Pak.wrl (VRML1) and D_Pakx.wrl (VRML2)
load and display correctly in the file preview which uses the new
parsers. In the legacy parsers, D_Pak.wrl causes a segfault and
D_Pakx.wrl does not display correctly. Note: the 3d_initial_merge
branch still uses the legacy 3DViewer so the 3DViewer will segfault
on the D_Pak.wrl model, but for me this only serves as a reminder
of some of the improvements gained with the new 3D plugin system.

- 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] KiCad GUI Translation HOWTO error (docs.kicad-pcb.org)

[Nick Østergaard]

Ohh, I guess this is related to the issue you mentioned earlier with
hotkeys not being translated.

2016-02-22 12:03 GMT+01:00  :
> Hello,
>
> In the KiCad GUI Translation HOWTO guide here:
>
> http://docs.kicad-pcb.org/en/gui_translation_howto.html
>
> Point 4.6, Keyword Configuration, is missing the "_HKI" key, so when
> translation with Poedit some text related to hotkeys are not loaded.
>
>
> Iñigo.
>
> ___
> Mailing list: https://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] KiCad GUI Translation HOWTO error (docs.kicad-pcb.org)

[ifs]

Hello,

In the KiCad GUI Translation HOWTO guide here:

http://docs.kicad-pcb.org/en/gui_translation_howto.html

Point 4.6, Keyword Configuration, is missing the "_HKI" key, so when 
translation with Poedit some text related to hotkeys are not loaded.



Iñigo.

___
Mailing list: https://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] Are some of the hotkey names hardcoded?

[ifs]

Your poedit config is missing some paths and keywords.

Attached my setup.


_HKI was it.
Thak you J.P.

Iñigo.

___
Mailing list: https://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 functionality on Windows

[Wayne Stambaugh]

Konstantin,

I have no interest in using the native windows Python because the amount
of effort to implement this would not be trivial.  We would have to
completely overhaul the build system for wxPython and the kicad python
scripting on windows builds to compile an link against the the native
system Python libraries which are built with MSVC.  I don't know if you
have ever attempted to do this but I have and it's a nightmare to build
native Python libraries with the GNU tool chain on Windows.  I'm not
saying that if someone provided a complete native python build solution
that didn't break the msys2/mingw builds that I wouldn't accept it but
I'm not going to work on it and I would rather the kicad developers work
on more pressing matters.  If you want an integrated Python solution,
try installing msys2/mingw32 (or mingw64) and build and install kicad
from source.  This way you have a full python implementation along with
pip and setuptool support.  This is what I use and it works almost as
well as the native window Python solution.

Cheers,

Wayne

On 2/19/2016 1:31 AM, Константин Барановский wrote:
> Hi!
> 
> Can anyone tell me, whether may I wait to get full featured python
> integration into KiCAD on Windows or not? If not, I will look for other
> ways to solve problem.
> 
> Regards, Konstantin.
> 
> 2016-02-17 21:11 GMT+02:00 Константин Барановский
> >:
> 
> Thanks for your message, Nick.
> 
> In this case support of python from pcbnew is not used. 
> It (should) works in the next sequence:
> 1) start eeschema;
> 2) launch kicadbom2spec as BOM plugin from eeschema;
> 3) it launches as separate python app and get scematic file to
> processing.
> Now kicadbom2spec installs as separate program, independent of
> KiCAD. It also installs system wide python, wxpython and odfpy.
> On linux I can setup it as BOM plugin to eeschema without any problem.
> But when I trying to do it on Windows, I get trouble - kicad uses it
> own python instead the systemwide.
> 
> For me best variant is installing kicadbom2spec as plugin to KiCAD
> and use it own python, wxpython and other. To realize this build-in
> python must be full featured.
> 
> I know, those messages looks egoistic, but I started this thread
> because think, that full featured python may be helpfull for other
> users.
> 
> Regards, Konstantin.
> 
> 
> 2016-02-17 19:36 GMT+02:00 Nick Østergaard  >:
> 
> Hi Konstantin,
> 
> I think I remember other people having similar wishes for this.
> But I
> am not sure it will be the proper solution to include pip in the
> installation. My reasoning is that when the kicad install is
> uninstalled and you reinstall kicad you will loose the packages you
> installed with pip (I think). Do you follow my concern?
> 
> Are you using the python console inside pcbnew for this script?
> 
> I am thinking it might be better to actually use a python install
> outside the kicad install, and only add the pcbnew module to the
> python module path thingie.
> 
> Nick
> 
> 2016-02-17 13:13 GMT+01:00 Константин Барановский
>  >:
> > Hello!
> >
> > Some time ago I wrote small program on python that creates the
> list of the
> > components formatted to according to GOST. It's named
> "kicadbom2spec" and
> > available here.
> > kicadbom2spec uses python, wxpython and odfpy for working.
> > Now I'm trying to install it beside KiCAD and use the common
> python and
> > wxpython. But KiCAD's python don't contain pythonw for working
> with
> > graphical interfaces. Also missing pip for easily installing
> needed packages
> > (in my case it is odfpy).
> >
> > So, can you integrate full python (including pip and other
> options) into
> > KiCAD? I think, users will be happy to feel full power of the
> python in
> > KiCAD.
> >
> > Regards, Konstantin.
> >
> > ___
> > Mailing list: https://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 

Re: [Kicad-developers] PATCH: added QFNFootprintWizard

[jp charras]

Le 18/02/2016 20:09, Mikael Arguedas a écrit :
> Hi guys,
> 
> The patches this plugin was relying on have all been merged.
> I updated this patch to accordingly.
> 
> Cheers,
> Mikael
> 
> On Tue, Feb 16, 2016 at 3:34 PM, Mikael Arguedas 
> wrote:
> 
>> Hi guys,
>>
>> Here is an updated version of this new qfn wizard.
>> Changes:
>>  - fixed thermal pad numbering when no subdivision are requested (epad
>> subdiv x= 0|1 or epad subdiv y =0|1). thanks to Peter Horvath testing.
>> - set the attribute to SMD
>> - round the courtyard to land on a 0.05mm grid (this feature relies on the
>> patch of this thread
>> )
>>
>> Could you please let us know if you want to integrate/support wizards for
>> components having thermal pads? I noticed that Maurice worked on similar
>> kind of plugins in the past but they have never been merged.
>>
>> If you do want to integrate them, Peter and I are willing to add several
>> features to this plugin and it's equivalent for SON footprints "son_wizard"
>> plugin:
>> - placing thermal vias centered on the thermal pad array
>> - add a possibility of "outward extension" of the pad for people willing
>> to generate HandSoldering version of the footprints
>>
>> Thanks!
>> Mikael


I am thinking an option to build the exposed pad with thermal vias (for
us, small round pads inside the EPad), is a very interesting feature.

Previous pythons plugons scripts I tried did not work well.

Thanks.


-- 
Jean-Pierre CHARRAS

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

Re: [Kicad-developers] ERC and labels

[jp charras]

Le 19/02/2016 22:05, Simon Richter a écrit :
> Hi,
> 
> I'm rebasing my patch stack on top of the latest changes and am 
> wondering about the interaction between the ERC and labels.
> 
> Could we simplify the ERC with the changes I've submitted,
> effectively treating labels similar to pins, and assigning them a
> virtual electrical type, depending on their orientation?
> 
> Simon
> 

Well, what do you mean by "simplify the ERC"?
There is no code to compare electrical type of labels.
You cannot make less than no code.

Hierarchical, global and pin sheet labels have no electrical type.
They just have a shape, to help the reader to analyze the schematic.
From the electrical point of view, there are equivalent to a wire
between 2 similar labels.

They are not similar to pins: you can connect 2 pin sheet labels with
an output shape, and do not create any design issue (this is not the
case when connecting 2 output pins).

Moreover, a sheet pin "output" label should be connected to an output
pin in the sub-hierarchy (through a Hlabel) to be an actual output
label, and this is not compatible with the proposal "labels similar to
pins"

Actual ERC issues are already taken in account by comparing pin
electrical types.

Connecting 2 pin sheet labels with an output shape (2 pin output sheet
labels) could be only seen as "Bad Schematic Practice" (BSP Check?),
just like drawing a wire, bus or label which overlap a component.

But BSPC (certainly a very useful tool, when we see some
schematics...) is an other topic than ERC.

-- 
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] Are some of the hotkey names hardcoded?

[jp charras]

Le 18/02/2016 11:48, i...@elektroquark.com a écrit :
> 2016-02-18 11:25 egunean, Nick Østergaard-(e)k idatzi du:
>> Could you give an example of the hotkey you think are missing?
> 
> Hi Nick,
> 
> Screenshots of "Edit Hotkeys" dialog attached, both English and Spanish
> versions. "List current keys" shows same behavior.
> 
> Iñigo.

Your poedit config is missing some paths and keywords.

Attached my setup.

-- 
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] Pin Table: Make pin position and pin type columns sortable

[Wayne Stambaugh]

Patch committed in product branch r6569.  Thanks.

On 2/16/2016 1:34 PM, Simon Richter wrote:
> ---
>  eeschema/dialogs/dialog_lib_edit_pin_table.cpp | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


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

Re: [Kicad-developers] [PATCH] Pin Table: Make pin position and pin type columns sortable

[jp charras]

Le 16/02/2016 19:34, Simon Richter a écrit :
> ---
>  eeschema/dialogs/dialog_lib_edit_pin_table.cpp | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 

Committed. Thanks.


-- 
Jean-Pierre CHARRAS

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

Re: [Kicad-developers] PATCH: length matching tolerance

[Mikael Arguedas]

Hi guys,

This patch has been tested under Linux but not on Windows or OSX. I don't
see what can possibly go wrong but better safe than sorry.
Can anyone give it a try on those platforms ?

Cheers,
Mikael

On Fri, Feb 12, 2016 at 6:19 PM, Mikael Arguedas 
wrote:

> Hi guys,
>
> This patch adds a tolerance field to the length matching dialog and set
> the pns settings accordingly.
>
> Cheers,
> Mikael
>
> PS: promise my next contributions will be by submitting branches for
> review and not patch files by email
>
___
Mailing list: https://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] Stable release 4.0.2

[Carl Poirier]

Tagging only X.0.0 for kicad-library could work. As for the pretties, we
desperately need some popup warning the user to update the fp-lib-table if
some Github repositories are not found.

On Fri, Feb 19, 2016 at 7:57 AM, Wayne Stambaugh 
wrote:

> I just checked and the library has been tagged with 4.0.2 but there were
> changes to device.lib since 4.0.1.  It looks like the POT component was
> resized which most likely will fire a component recovery for users who
> have POTs in their schematics.  I think we should ship component
> libraries that do not trigger a recovery during the 4 series stable
> releases so it looks like you should pull the 4.0.1 library for
> packaging for the remainder of version 4 stable releases.  I'll see if I
> can come up with a reasonable policy to eliminate confusion in the
> future.  We probably should just tag the library at X.0.0 when the
> stable version is released and use that for the entire stable release
> series to prevent any surprises for the user.  The other option is to
> create separate library packages and let the user assume the risk when
> updating the libraries.
>
> On 2/19/2016 1:39 AM, Nick Østergaard wrote:
> > I need a clear answer. If we don't want to update, then we shall move
> > the tag on the libs to the 4.0.1 tag on the libs.
> >
> > 2016-02-15 19:36 GMT+01:00 Wayne Stambaugh :
> >> I'm not sure how much of a difference it makes with the github libraries
> >> since the contents of the libraries can change even if you don't update
> >> your fp-lib-table.  Shipping the updated fp-lib-table wont make any
> >> difference unless the user chooses to copy the new one.  The schematic
> >> libraries however are a different matter.  We should probably keep those
> >> the same through out the entire stable 4 release series rather than
> >> breaking users schematics.  I know Chris's rescue code goes a long way
> >> in mitigating this issue but I would still like to avoid users having to
> >> rescue a schematic during a stable release series.
> >>
> >> On 2/15/2016 1:29 PM, Carl Poirier wrote:
> >>> The pretty repository with the old name still exists for as long as
> >>> needed. My question is about having lib differences between bugfix
> >>> releases. In this case, the fp-lib-table will be updated so that 4.0.3
> >>> will use the renamed lib whereas 4.0.2 uses the old lib.
> >>>
> >>> Regards,
> >>>
> >>> Carl
> >>>
> >>> On Mon, Feb 15, 2016 at 2:40 AM, Nick Østergaard  >>> > wrote:
> >>>
> >>> 2016-02-14 17:07 GMT+01:00 Carl Poirier  >>> >:
> >>> > We have some new libraries to add to the fp-lib-table and one to
> rename. If
> >>> > we do so now, when we'll be tagging 4.0.3, it will include the
> changes.
> >>> >
> >>> > Would this be permitted in such a release? If not, what about
> version 4.1?
> >>>
> >>> I am not exactly sure, but what about we just do not perform the
> >>> rename (for the release), but just add the new ones, then there is
> >>> little change for the user to experience errors, or am I mistaken?
> >>>
> >>> > On Sun, Feb 14, 2016 at 7:10 AM, Nick Østergaard
> >>> > wrote:
> >>> >>
> >>> >> 2016-02-14 12:18 GMT+01:00 Nick Østergaard  >>> >:
> >>> >> > Ok, so we tag the latest snapshot of the libraries as
> suggested
> >>> by the
> >>> >> > librarians, and will do the same with the docs to get the
> >>> latest fixes
> >>> >> > and translations there too.
> >>> >> >
> >>> >> > Wayne, I wonder why you tagged the release kicad-4.0.2 instead
> >>> of just
> >>> >> > 4.0.2 as you did for 4.0.0 and 4.0.1.
> >>> >>
> >>> >> Hmm, I think that is just a name set in the lp web ui, which
> can be
> >>> >> edited.
> >>> >>
> >>> >> > 2016-02-13 22:59 GMT+01:00 Wayne Stambaugh
> >>> >:
> >>> >> >> Did we tag 4.0.1?  I thought we just tagged 4.0 and used it
> >>> for 4.0.1
> >>> >> >> but I'm not sure.  I don't think the docs have any of the new
> >>> stuff
> >>> >> >> like
> >>> >> >> the one button board update yet so it may be OK to tag the
> >>> docs 4.0.2.
> >>> >> >>
> >>> >> >> On 2/13/2016 4:56 PM, Nick Østergaard wrote:
> >>> >> >>> I expect we tag a new snapshot of the libraries and docs
> again.
> >>> >> >>>
> >>> >> >>> 2016-02-13 22:51 GMT+01:00 Wayne Stambaugh
> >>> >:
> >>> >>  Just a heads up, stable version 4.0.2 has been released.
> >>> This is a
> >>> >>  bug
> >>> >>  fix release so when the build devs get a chance, please
> >>> create builds
> >>> >>  for the new stable release packages.  

Re: [Kicad-developers] KiCad in Spanish, again.

[Mark Roszko]

>I think your proposals are fine,

I actually think we should not end up having a separate submenu entry
for every possible kicad forum language but rather just change it to a
"Community Forums" page where we link to each langauge specific one.

___
Mailing list: https://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] Separate ElectricPinType and TypeSheetLabel

[Wayne Stambaugh]

Simon,

I asked JP to take a look at this patch for me and he went ahead and
fixed it which caught me a bit off guard.  Apparently your patch had
some issues in the ERC.  I apologize for the confusion.  I'm assuming
you will have to revise your PinShape and electrical type patches to
work with JP's changes.

Thanks,

Wayne

On 2/16/2016 1:34 PM, Simon Richter wrote:
> 
> These enums are silently treated as equivalent in the ERC, because the
> values are casted to integers. This works for the most part, because the
> values are similar, but this is in no way enforced, and there is a small
> inconsistency (NET_UNSPECIFIED vs PIN_PASSIVE).
> 
> This turns the storage into a discriminated union, and provides an accessor
> method that checks that a meaningful value can be returned and returns an
> ElectricPinType in any case.
> ---
>  eeschema/class_netlist_object.cpp | 36 ++--
>  eeschema/class_netlist_object.h   |  3 +++
>  eeschema/erc.cpp  |  8 
>  3 files changed, 41 insertions(+), 6 deletions(-)
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


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

Re: [Kicad-developers] [PATCH] Separate ElectricPinType and TypeSheetLabel

[jp charras]

Le 16/02/2016 19:34, Simon Richter a écrit :
> 
> These enums are silently treated as equivalent in the ERC, because the
> values are casted to integers. This works for the most part, because the
> values are similar, but this is in no way enforced, and there is a small
> inconsistency (NET_UNSPECIFIED vs PIN_PASSIVE).
> 
> This turns the storage into a discriminated union, and provides an accessor
> method that checks that a meaningful value can be returned and returns an
> ElectricPinType in any case.
> ---
>  eeschema/class_netlist_object.cpp | 36 ++--
>  eeschema/class_netlist_object.h   |  3 +++
>  eeschema/erc.cpp  |  8 
>  3 files changed, 41 insertions(+), 6 deletions(-)

Simon,
Thanks for your patch.

However, I committed a different change, because ElectricPinType enum
(now ELECTRICAL_PINTYPE enum) is not used by ERC for sheet labels.

So I removed the useless and questionable copy of Sheet label shape to
the m_Eectrical_Type member of NETLIST_OBJECT, and ELECTRICAL_PINTYPE
enum is no more casted to int in code.


-- 
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] KiCad in Spanish, again.

[Iñigo]

Hi Inigo,


Hi Miguel Ángel,

I registered some time ago kicad.es  with that 
intention, if you want we could try ti bring it up together,
It’s a bit cumbersome to comply with all the regulations in EU 
currently (data protection registration

for the forum database of users, complying with the cookie law, etc…).


I surpassed all those legal requirements with a COM domain hosted in USA.
I don't know the legal implications if kicad.es is hosted out of EU land.
Any lawyer here that can help us? ;)
OTOH I have no problems moving the Spanish forum to the kicad.es site, 
of course.



   Best regards, and .. Buen trabajo!!! ;)


No, muchas gracias por vuestra aportación a KiCad, lo mío es un grano de 
arena en la playa.


Un saludo.
Iñigo.


Miguel Ángel,


On 19 Feb 2016, at 08:44, i...@elektroquark.com 
 wrote:


Hi Nick,



I think your proposals are fine, I have just been a bit busy and sort
of forgot this, and still a bit busy. Could you prepare a pull request
on https://github.com/KiCad/kicad-website?


Of course, and don't worry please. I only wanted the message not to 
be lost in space without any comment.



But I wonder, why did HaD start to have articles in other languages?
Are they intending to do that to all articles or what is the point? Or
was this just a gimmick to present the spanish kicad forum?


No idea. I have no relation with Hackaday, I only sent them a note 
about the Spanish translation and forum.


Iñigo.

2016-02-19 7:26 GMT+01:00 Iñigo >:

Hello,
No comments?
Regards,
Iñigo.
___
Hello,
A couple of notes...
- The KiCad Spanish translation was featured on hackaday.com 
 (first message
ever in Spanish on hackaday). Maybe it is of interest to publish it 
on the

KiCad webpage in the (DISCOVER->IN THE MEDIA) section.
Link:http://hackaday.com/2016/02/11/kicad-traducido-al-espanol/ 

- There has been some interest among some users about a Spanish 
forum about
KiCad, so I published one here: www.elektroquark.com/forokicad 
. It's

starting now but, could it be linked from the COMMUNITY section?
Thank you.
Iñigo.
___
Mailing list: https://launchpad.net/~kicad-developers 

Post to : kicad-developers@lists.launchpad.net 

Unsubscribe : https://launchpad.net/~kicad-developers 


More help   : https://help.launchpad.net/ListHelp



___
Mailing list: https://launchpad.net/~kicad-developers 

Post to : kicad-developers@lists.launchpad.net 

Unsubscribe : https://launchpad.net/~kicad-developers 


More help   : https://help.launchpad.net/ListHelp




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

Re: [Kicad-developers] Python functionality on Windows

[xarx]

If it is only about pythonw, the fix is actually very simple on Windows. I
submitted a patch into the Winbuilder bug-tracker,
https://github.com/nickoe/KiCad-Winbuilder/issues/28. Perhaps, the fix can be
equally simple on other platforms, I have no idea how the build is performed
there.

   Martin.

- Původní zpráva -
Odesílatel:



Příjemce: Nick stergaard 
Datum: Fri, 19 Feb 2016 10:30:43 +0200
Předmět: Re: [Kicad-developers] Python functionality on Windows


> > I am not exactly sure what pythonw is, could you refresh? Is this a
> > special windows version?
> >
> 
> python.exe is a console (terminal) application for launching CLI-type
> scripts:
> 1. Unless run from an existing console window, python.exe opens a new
> console window.
> 2. Standard streams sys.stdin, sys.stdout and sys.stderr are connected to
> the console window.
> 3. Execution is synchronous:
> 3.1. If a new console window was created, it stays open until the script
> terminates.
> 3.2. When invoked from an existing console window, the prompt is blocked
> until the script terminates.
> 
> pythonw.exe is a GUI app for launching GUI/no-UI-at-all scripts:
> 1. NO console window is opened.
> 2. Execution is asynchronous:
> 2.1. When invoked from a console window, the script is merely launched and
> the prompt returns right away, whether the script is still running or not.
> 3. Standard streams sys.stdin, sys.stdout and sys.stderr are NOT available.
> 3.1. Caution: Unless you take extra steps, this has potentially unexpected
> side effects:
> 3.1.1. Unhandled exceptions cause the script to abort silently.
> 3.1.2. In Python 2.x, simply trying to use print() can cause that to happen.
> 
> Source 
> 
> 
> On a side note, someone have noted that the python is broken on the
> > latest windows nightlies, would you try to confirm that? As in, can it
> > open the python console in pcbnew?
> >
> 
> On windows I'm use stable version 4.0.1 where it works. But on linux it is
> realy does not work (rev 6557). When I press pyconsole button in pcbnew I
> get message "Error: unable to create the Python Console" and output:
> 
> Traceback (most recent call last):
>   File "", line 3, in 
> ImportError: No module named pcbnew
> Traceback (most recent call last):
>   File "", line 1, in 
> ImportError: No module named kicad_pyshell
> 
> Since I built kicad from sources, it is installed in /usr/local and python
> modules installed in /usr/local/lib/python2.7/site-packages/. When I
> created symlinks to /usr/lib/python2.7/site-packages pyconsole started
> working.
> 
> Regards, Konstantin.
> 


--  
 
__
Vystup z řady a zřiď si taky originální email! @bigboss.cz, @dablik.cz, 
@potvurka.cz, @tajny.cz... zdarma na http://email.sms.cz
COMDOM Antispam - www.comdomsoft.com




___
Mailing list: https://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 01/19] Replace DrawPinShape enum with PinShape

[jp charras]

Le 17/02/2016 21:27, Simon Richter a écrit :
> 
> The bitmask requires a mapping to a different type used for the combobox,
> and only few of the enumeration values actually make sense.
> 
> This removes the mapping, and uses a the same numbering throughout the
> entire code.
> ---
>  eeschema/dialogs/dialog_lib_edit_pin.cpp |   2 +-
>  eeschema/dialogs/dialog_lib_edit_pin.h   |   4 +-
>  eeschema/lib_pin.cpp | 219 
> ++-
>  eeschema/lib_pin.h   |  54 +++-
>  eeschema/pinedit.cpp |  20 +--
>  5 files changed, 164 insertions(+), 135 deletions(-)

Simon,

Thanks for your work.

Could you modify your changes to be compliant with our coding style
policy, when changing enum names?

DrawPinShape enum is an old name.

but PinShape is not compliant. it should be at least PINSHAPE.

However, to tell the true, I prefer more significant names, in this case
something like
GRAPHIC_PINSHAPE.

(PINSHAPE, PINTYPE are the kind of names which can be applied to a lot
of parameters, this the reason I prefer a better name)

Also can you group yours patches relative to the same thing (5 patches
to move an enum in a header and change its name is too much for me).

Thanks.

-- 
Jean-Pierre CHARRAS

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

[Kicad-developers] [PATCH] Fix lp:1529159

[Bernhard Stegmaier]

Hi,

attached a patch to fix lp:1529159, it is still reproducible with a current 
wxWidgets master.
Credits go to the author of the bug report, I just did change the condition to 
immediately return if one of the sizes is zero (and create the patch).

Of course, it could be argued if the real fix for this should go into OS X 
wxWidgets (I guess it should), but not trying to draw something zero sized at 
all doesn’t seem like a bad thing in general.


Regards,
Bernhard



lp-1529159.patch
Description: Binary 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] Stable release 4.0.2

[Nick Østergaard]

2016-02-19 8:49 GMT+01:00 Nick Østergaard :
>
> Den 19/02/2016 07.57 skrev "Cirilo Bernardo" :
>>
>> I think if there were significant changes to what's on github then we
>> should just put the new tag on the same revisions as the old tag. We
>> wouldn't want people to update expecting bug fixes and suddenly they have
>> issues because they updated the libs.  The lib maintainers need to establish
>> some protocol for releases etc.
>
> I don't think it is enough to just have the lib maintainera have a defined
> process. We have three project parts where the user expect them to work
> together, even of we are different people with little overlap, we should
> align across and only call it released when all tags are aligned across
> projects.

I forgot to mention the kicad-i18n repo, but that is also important.
We might want to have a short string freeze of a week or two probably.

>>
>> - Cirilo
>>
>>
>> On Fri, Feb 19, 2016 at 5:39 PM, Nick Østergaard 
>> wrote:
>>>
>>> I need a clear answer. If we don't want to update, then we shall move
>>> the tag on the libs to the 4.0.1 tag on the libs.
>>>
>>> 2016-02-15 19:36 GMT+01:00 Wayne Stambaugh :
>>> > I'm not sure how much of a difference it makes with the github
>>> > libraries
>>> > since the contents of the libraries can change even if you don't update
>>> > your fp-lib-table.  Shipping the updated fp-lib-table wont make any
>>> > difference unless the user chooses to copy the new one.  The schematic
>>> > libraries however are a different matter.  We should probably keep
>>> > those
>>> > the same through out the entire stable 4 release series rather than
>>> > breaking users schematics.  I know Chris's rescue code goes a long way
>>> > in mitigating this issue but I would still like to avoid users having
>>> > to
>>> > rescue a schematic during a stable release series.
>>> >
>>> > On 2/15/2016 1:29 PM, Carl Poirier wrote:
>>> >> The pretty repository with the old name still exists for as long as
>>> >> needed. My question is about having lib differences between bugfix
>>> >> releases. In this case, the fp-lib-table will be updated so that 4.0.3
>>> >> will use the renamed lib whereas 4.0.2 uses the old lib.
>>> >>
>>> >> Regards,
>>> >>
>>> >> Carl
>>> >>
>>> >> On Mon, Feb 15, 2016 at 2:40 AM, Nick Østergaard >> >> > wrote:
>>> >>
>>> >> 2016-02-14 17:07 GMT+01:00 Carl Poirier >> >> >:
>>> >> > We have some new libraries to add to the fp-lib-table and one to
>>> >> rename. If
>>> >> > we do so now, when we'll be tagging 4.0.3, it will include the
>>> >> changes.
>>> >> >
>>> >> > Would this be permitted in such a release? If not, what about
>>> >> version 4.1?
>>> >>
>>> >> I am not exactly sure, but what about we just do not perform the
>>> >> rename (for the release), but just add the new ones, then there is
>>> >> little change for the user to experience errors, or am I mistaken?
>>> >>
>>> >> > On Sun, Feb 14, 2016 at 7:10 AM, Nick Østergaard
>>> >> > wrote:
>>> >> >>
>>> >> >> 2016-02-14 12:18 GMT+01:00 Nick Østergaard >> >> >:
>>> >> >> > Ok, so we tag the latest snapshot of the libraries as
>>> >> suggested
>>> >> by the
>>> >> >> > librarians, and will do the same with the docs to get the
>>> >> latest fixes
>>> >> >> > and translations there too.
>>> >> >> >
>>> >> >> > Wayne, I wonder why you tagged the release kicad-4.0.2
>>> >> instead
>>> >> of just
>>> >> >> > 4.0.2 as you did for 4.0.0 and 4.0.1.
>>> >> >>
>>> >> >> Hmm, I think that is just a name set in the lp web ui, which
>>> >> can be
>>> >> >> edited.
>>> >> >>
>>> >> >> > 2016-02-13 22:59 GMT+01:00 Wayne Stambaugh
>>> >> >:
>>> >> >> >> Did we tag 4.0.1?  I thought we just tagged 4.0 and used it
>>> >> for 4.0.1
>>> >> >> >> but I'm not sure.  I don't think the docs have any of the
>>> >> new
>>> >> stuff
>>> >> >> >> like
>>> >> >> >> the one button board update yet so it may be OK to tag the
>>> >> docs 4.0.2.
>>> >> >> >>
>>> >> >> >> On 2/13/2016 4:56 PM, Nick Østergaard wrote:
>>> >> >> >>> I expect we tag a new snapshot of the libraries and docs
>>> >> again.
>>> >> >> >>>
>>> >> >> >>> 2016-02-13 22:51 GMT+01:00 Wayne Stambaugh
>>> >> >:
>>> >> >>  Just a heads up, stable version 4.0.2 has been released.
>>> >> This is a
>>> >> >>  bug
>>> >> >>  fix release so when the build devs get a chance, please
>>> >> create builds
>>> >> >>  for the new stable release packages.  Thank you everyone
>>> 

[Kicad-developers] Patch for #1511552 - Modifications of the spice netlist generator

[xarx]

Hello.

In the Launchpad bug tracker, I've posted a new patch for export of Spice
netlists, the bug #1511552.

https://bugs.launchpad.net/kicad/+bug/1511552/comments/20

I made the support of the Spice simulation engines as lightweight as possible,
so that the actual simulation support can be programmed independently (outside
KiCad) in an external script/program.
In other words, all "spice" attributes are now exported into the spice
netlists as comments, so that an external script can do the netlist
post-processing by itself.

Best regards
  Martin.
__
Vystup z řady a zřiď si taky originální email! @bigboss.cz, @dablik.cz, 
@potvurka.cz, @tajny.cz... zdarma na http://email.sms.cz
COMDOM Antispam - www.comdomsoft.com




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

Re: [Kicad-developers] [PATCH 0/4] Regenerate and update eeschema dialogs

[Wayne Stambaugh]

Patch committed in product branch r6572.  Thanks.

On 2/17/2016 3:07 PM, Simon Richter wrote:
> Hi,
> 
> this regenerates all eeschema dialogs with a slightly newer wxFormBuilder,
> partially to see whether we can still reproduce the same files (we
> couldn't), and partially to avoid creating an inconsistent state with other
> dialog updates.
> 
> No visible changes, but the newer wxFormBuilder fixes the dialog's
> hierarchy.
> 
>Simon
> 
> Simon Richter (4):
>   eeschema dialogs: parent of elements in wx Sizer
>   eeschema dialogs: update old dialog
>   eeschema dialogs: Add wxALIGN_CENTER_VERTICAL flag
>   eeschema dialogs: Update wxFormBuilder timestamp in generated sources
> 
>  eeschema/dialogs/dialog_annotate_base.cpp|  2 +-
>  eeschema/dialogs/dialog_annotate_base.h  |  2 +-
>  eeschema/dialogs/dialog_bom_base.cpp |  2 +-
>  eeschema/dialogs/dialog_bom_base.h   |  2 +-
>  eeschema/dialogs/dialog_choose_component_base.cpp|  2 +-
>  eeschema/dialogs/dialog_choose_component_base.h  |  2 +-
>  eeschema/dialogs/dialog_edit_component_in_lib_base.cpp   | 10 +-
>  eeschema/dialogs/dialog_edit_component_in_lib_base.h |  2 +-
>  eeschema/dialogs/dialog_edit_component_in_schematic_fbp.cpp  |  2 +-
>  eeschema/dialogs/dialog_edit_component_in_schematic_fbp.h|  2 +-
>  eeschema/dialogs/dialog_edit_label_base.cpp  |  2 +-
>  eeschema/dialogs/dialog_edit_label_base.h|  2 +-
>  eeschema/dialogs/dialog_edit_libentry_fields_in_lib_base.cpp |  6 +++---
>  eeschema/dialogs/dialog_edit_libentry_fields_in_lib_base.h   |  2 +-
>  eeschema/dialogs/dialog_eeschema_config_fbp.cpp  |  2 +-
>  eeschema/dialogs/dialog_eeschema_config_fbp.h|  2 +-
>  eeschema/dialogs/dialog_eeschema_options_base.cpp|  2 +-
>  eeschema/dialogs/dialog_eeschema_options_base.h  |  2 +-
>  eeschema/dialogs/dialog_erc_base.cpp |  2 +-
>  eeschema/dialogs/dialog_erc_base.h   |  2 +-
>  eeschema/dialogs/dialog_lib_edit_draw_item.fbp   |  4 +++-
>  eeschema/dialogs/dialog_lib_edit_draw_item_base.cpp  |  2 +-
>  eeschema/dialogs/dialog_lib_edit_draw_item_base.h|  2 +-
>  eeschema/dialogs/dialog_lib_edit_pin_base.cpp| 12 
> ++--
>  eeschema/dialogs/dialog_lib_edit_pin_base.fbp|  4 ++--
>  eeschema/dialogs/dialog_lib_edit_pin_base.h  |  2 +-
>  eeschema/dialogs/dialog_lib_edit_pin_table_base.cpp  |  2 +-
>  eeschema/dialogs/dialog_lib_edit_pin_table_base.h|  2 +-
>  eeschema/dialogs/dialog_lib_edit_text_base.cpp   | 12 
> ++--
>  eeschema/dialogs/dialog_lib_edit_text_base.h |  2 +-
>  eeschema/dialogs/dialog_lib_new_component_base.cpp   |  2 +-
>  eeschema/dialogs/dialog_lib_new_component_base.h |  2 +-
>  eeschema/dialogs/dialog_libedit_options_base.cpp |  2 +-
>  eeschema/dialogs/dialog_libedit_options_base.h   |  2 +-
>  eeschema/dialogs/dialog_netlist_base.cpp |  2 +-
>  eeschema/dialogs/dialog_netlist_base.h   |  2 +-
>  eeschema/dialogs/dialog_plot_schematic_base.cpp  |  2 +-
>  eeschema/dialogs/dialog_plot_schematic_base.h|  2 +-
>  eeschema/dialogs/dialog_print_using_printer_base.cpp |  2 +-
>  eeschema/dialogs/dialog_print_using_printer_base.h   |  2 +-
>  eeschema/dialogs/dialog_rescue_each_base.cpp |  2 +-
>  eeschema/dialogs/dialog_rescue_each_base.h   |  2 +-
>  eeschema/dialogs/dialog_sch_edit_sheet_pin_base.cpp  |  2 +-
>  eeschema/dialogs/dialog_sch_edit_sheet_pin_base.fbp  |  6 +++---
>  eeschema/dialogs/dialog_sch_edit_sheet_pin_base.h|  2 +-
>  eeschema/dialogs/dialog_sch_sheet_props_base.cpp |  2 +-
>  eeschema/dialogs/dialog_sch_sheet_props_base.h   |  2 +-
>  eeschema/dialogs/dialog_schematic_find_base.cpp  |  2 +-
>  eeschema/dialogs/dialog_schematic_find_base.h|  2 +-
>  49 files changed, 70 insertions(+), 68 deletions(-)
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


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

[Kicad-developers] Does auto placement feature still exist?

[Dan Walmsley]

Iv seen some tutorials online suggesting kicad *had* an autoplacement feature, 
but iv not been able to get this to work in current version.
Does this feature still exist?
Thanks
Dan   ___
Mailing list: https://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] Update comments (ElectricPinType -> ELECTRICAL_PINTYPE)

[Simon Richter]

---
 eeschema/lib_pin.cpp | 4 ++--
 eeschema/lib_pin.h   | 6 +++---
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/eeschema/lib_pin.cpp b/eeschema/lib_pin.cpp
index 85ae347..bbf7819 100644
--- a/eeschema/lib_pin.cpp
+++ b/eeschema/lib_pin.cpp
@@ -103,7 +103,7 @@ static const int pin_style_codes[] =
 #define PIN_STYLE_CNT DIM( pin_style_codes )
 
 // bitmaps to show pins electrical type in dialog editor
-// must have same order than enum ElectricPinType (see lib_pin.h)
+// must have same order than enum ELECTRICAL_PINTYPE (see lib_pin.h)
 static const BITMAP_DEF iconsPinsElectricalType[] =
 {
 pintype_input_xpm,
@@ -127,7 +127,7 @@ const wxString LIB_PIN::GetCanonicalElectricalTypeName( unsigned aType )
 // These strings are the canonical name of the electrictal type
 // Not translated, no space in name, only ASCII chars.
 // to use when the string name must be known and well defined
-// must have same order than enum ElectricPinType (see lib_pin.h)
+// must have same order than enum ELECTRICAL_PINTYPE (see lib_pin.h)
 static const wxChar* msgPinElectricType[] =
 {
 wxT( "input" ),
diff --git a/eeschema/lib_pin.h b/eeschema/lib_pin.h
index 44efea0..15d5412 100644
--- a/eeschema/lib_pin.h
+++ b/eeschema/lib_pin.h
@@ -277,14 +277,14 @@ public:
 /**
  * Get the electrical type of the pin.
  *
- * @return The electrical type of the pin (see enun ElectricPinType for values).
+ * @return The electrical type of the pin (see enum ELECTRICAL_PINTYPE for values).
  */
 ELECTRICAL_PINTYPE GetType() const { return m_type; }
 
 /**
  * return a string giving the electrical type of a pin.
  * Can be used when a known, not translated name is needed (for instance in net lists)
- * @param aType is the electrical type (see enum ElectricPinType )
+ * @param aType is the electrical type (see enum ELECTRICAL_PINTYPE )
  * @return The electrical name for a pin type (see enun MsgPinElectricType for names).
  */
 static const wxString GetCanonicalElectricalTypeName( unsigned aType );
@@ -301,7 +301,7 @@ public:
 
 /**
  * return a translated string for messages giving the electrical type of a pin.
- * @param aType is the electrical type (see enum ElectricPinType )
+ * @param aType is the electrical type (see enum ELECTRICAL_PINTYPE )
  * @return The electrical name of the pin (see enun MsgPinElectricType for names).
  */
 static const wxString GetElectricalTypeName( unsigned aType );
___
Mailing list: https://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] Stable release 4.0.2

[Wayne Stambaugh]

I just checked and the library has been tagged with 4.0.2 but there were
changes to device.lib since 4.0.1.  It looks like the POT component was
resized which most likely will fire a component recovery for users who
have POTs in their schematics.  I think we should ship component
libraries that do not trigger a recovery during the 4 series stable
releases so it looks like you should pull the 4.0.1 library for
packaging for the remainder of version 4 stable releases.  I'll see if I
can come up with a reasonable policy to eliminate confusion in the
future.  We probably should just tag the library at X.0.0 when the
stable version is released and use that for the entire stable release
series to prevent any surprises for the user.  The other option is to
create separate library packages and let the user assume the risk when
updating the libraries.

On 2/19/2016 1:39 AM, Nick Østergaard wrote:
> I need a clear answer. If we don't want to update, then we shall move
> the tag on the libs to the 4.0.1 tag on the libs.
> 
> 2016-02-15 19:36 GMT+01:00 Wayne Stambaugh :
>> I'm not sure how much of a difference it makes with the github libraries
>> since the contents of the libraries can change even if you don't update
>> your fp-lib-table.  Shipping the updated fp-lib-table wont make any
>> difference unless the user chooses to copy the new one.  The schematic
>> libraries however are a different matter.  We should probably keep those
>> the same through out the entire stable 4 release series rather than
>> breaking users schematics.  I know Chris's rescue code goes a long way
>> in mitigating this issue but I would still like to avoid users having to
>> rescue a schematic during a stable release series.
>>
>> On 2/15/2016 1:29 PM, Carl Poirier wrote:
>>> The pretty repository with the old name still exists for as long as
>>> needed. My question is about having lib differences between bugfix
>>> releases. In this case, the fp-lib-table will be updated so that 4.0.3
>>> will use the renamed lib whereas 4.0.2 uses the old lib.
>>>
>>> Regards,
>>>
>>> Carl
>>>
>>> On Mon, Feb 15, 2016 at 2:40 AM, Nick Østergaard >> > wrote:
>>>
>>> 2016-02-14 17:07 GMT+01:00 Carl Poirier >> >:
>>> > We have some new libraries to add to the fp-lib-table and one to 
>>> rename. If
>>> > we do so now, when we'll be tagging 4.0.3, it will include the 
>>> changes.
>>> >
>>> > Would this be permitted in such a release? If not, what about version 
>>> 4.1?
>>>
>>> I am not exactly sure, but what about we just do not perform the
>>> rename (for the release), but just add the new ones, then there is
>>> little change for the user to experience errors, or am I mistaken?
>>>
>>> > On Sun, Feb 14, 2016 at 7:10 AM, Nick Østergaard
>>> > wrote:
>>> >>
>>> >> 2016-02-14 12:18 GMT+01:00 Nick Østergaard >> >:
>>> >> > Ok, so we tag the latest snapshot of the libraries as suggested
>>> by the
>>> >> > librarians, and will do the same with the docs to get the
>>> latest fixes
>>> >> > and translations there too.
>>> >> >
>>> >> > Wayne, I wonder why you tagged the release kicad-4.0.2 instead
>>> of just
>>> >> > 4.0.2 as you did for 4.0.0 and 4.0.1.
>>> >>
>>> >> Hmm, I think that is just a name set in the lp web ui, which can be
>>> >> edited.
>>> >>
>>> >> > 2016-02-13 22:59 GMT+01:00 Wayne Stambaugh
>>> >:
>>> >> >> Did we tag 4.0.1?  I thought we just tagged 4.0 and used it
>>> for 4.0.1
>>> >> >> but I'm not sure.  I don't think the docs have any of the new
>>> stuff
>>> >> >> like
>>> >> >> the one button board update yet so it may be OK to tag the
>>> docs 4.0.2.
>>> >> >>
>>> >> >> On 2/13/2016 4:56 PM, Nick Østergaard wrote:
>>> >> >>> I expect we tag a new snapshot of the libraries and docs again.
>>> >> >>>
>>> >> >>> 2016-02-13 22:51 GMT+01:00 Wayne Stambaugh
>>> >:
>>> >>  Just a heads up, stable version 4.0.2 has been released.
>>> This is a
>>> >>  bug
>>> >>  fix release so when the build devs get a chance, please
>>> create builds
>>> >>  for the new stable release packages.  Thank you everyone for
>>> your
>>> >>  efforts to make this possible.
>>> >> 
>>> >>  Cheers,
>>> >> 
>>> >>  Wayne
>>> >> 
>>> >>  ___
>>> >>  Mailing list: https://launchpad.net/~kicad-developers
>>> >>  Post to : kicad-developers@lists.launchpad.net
>>> 
>>> >>  

[Kicad-developers] 3D refactor

[Cirilo Bernardo]

Hi Folks,

 Any thoughts on merging the 3d_initial_merge branch? Between
mainly Mario and myself and a few reports by others (nickoe,
reportingsjr) we have sorted out quite a few bugs and other
deficiencies but I think the only way to get more testing from users
is to merge the code. I believe that the new parsers all offer much
better specifications compliance compared to the old parsers and
the code is more robust. As an example, there is this post by a
user:

https://forum.kicad.info/t/trouble-with-3d-models-vrml/2320/7

 The user's models, D_Pak.wrl (VRML1) and D_Pakx.wrl (VRML2)
load and display correctly in the file preview which uses the new
parsers. In the legacy parsers, D_Pak.wrl causes a segfault and
D_Pakx.wrl does not display correctly. Note: the 3d_initial_merge
branch still uses the legacy 3DViewer so the 3DViewer will segfault
on the D_Pak.wrl model, but for me this only serves as a reminder
of some of the improvements gained with the new 3D plugin system.

- 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

Re: [Kicad-developers] [PATCH] Update comments (ElectricPinType -> ELECTRICAL_PINTYPE)

[jp charras]

Le 20 Feb 2016, Simon Richter a écrit
>  eeschema/lib_pin.cpp | 4 ++--
>  eeschema/lib_pin.h   | 6 +++---
>  2 files changed, 5 insertions(+), 5 deletions(-)

Change committed. Thanks.


-- 
Jean-Pierre CHARRAS

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

Re: [Kicad-developers] [PATCH] OS X: Add Retina support to 3d-viewer

[Bernhard Stegmaier]

Any objections on this one?

> On 13.02.2016, at 20:38, Bernhard Stegmaier  wrote:
> 
> Hi,
> 
> attached a patch to add Retina support to 3d-viewer on OS X.
> It is done similar to OpenGL canvas (and, of course, also requires a patched 
> wxWidgets).
> 
> 
> Regards,
> Bernhard
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


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

Re: [Kicad-developers] [PATCH] New Feature: Touchpad Panning

[Bernhard Stegmaier]

Any plans/comments whether this one will get merged?

> On 12.02.2016, at 20:38, Bernhard Stegmaier  wrote:
> 
> Hi all,
> 
> attached a patch to add a new feature “touchpad panning”.
> When enabled, you can pan in x/y-direction by just using usual 2-finger 
> touchpad gestures without shift/ctrl modifiers instead of scroll wheel zoom.
> 
> It is particularly useful on OS X, because any Apple touchpad/mouse supports 
> these 2-finger gestures (1-finger with MagicMouse). 
> It makes KiCad behave more like any other regular OS X application and has 
> been requested for some time by some/many OS X users.
> 
> It is built on top of platform independent wxWidgets functions, so it should 
> work also on any other platform and device supporting x/y mousewheel events 
> and is not restricted to OS X.
> 
> I added preference options to each application like the other pan/zoom 
> options (and a menu entry for 3d-Viewer).
> If disabled, panning/scrolling should work the same as without the patch.
> 
> I tested it on
> * OS X with touchpad, MagicMouse, MightMouse
> * OS X with normal PC mouse
> * Linux running inside a VirtualBox on OS X (debian testing with xfce desktop)
> 
> I would be great if someone could test it on native Windows/Linux with a 
> touchpad.
> It should be OK, the only problem that I could imagine is that panning speed 
> might have to be adapted (frequency/granularity of mousewheel events could be 
> different between OS X and other platforms, there are already some platform 
> specific adaptions in the code before the patch).
> 
> Of course, any other feedback is also welcome!
> 
> Note:
> This patch contains the patch discussed in the other mail thread, which 
> disables framerate throttling in GAL on OS X.
> 
> 
> Regards,
> Bernhard
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


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

[Kicad-developers] S-Expression schematic format specification

[Russell Oliver]

Hi All,

I was looking through the roadmap for Kicad 5 and saw that work is being
done on the new schematic format. I was wondering if the draft
specification is available anywhere and whether I could assist in
developing it.


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