Re: [Kicad-developers] [PATCH][RFC] Footprint wizards

[jp charras]

Le 15/09/2016 à 00:16, Oliver Walters a écrit :
> JP,
> 
> Ok, that should be a pretty easy fix. For testing on my side, how do I get 
> KiCad to use a comma for
> floating point separator? Is this a language setting?

This is a language setting.
It could be no so easy to test, if the system language uses the same separator 
as the "C" language.

The easy fix is do not use the wxWidgets floating point validator (no 
validator).
The user must enter fp numbers using the "C" locale separator (the point).

The best fix is more complicated, and imply :
- Use the selected language (usually the system language, but not always) fp 
separator to display fp
number in dialog (this is not currently the case: currently this is the "C" 
locale separator, used
by the Python script)
- In countries which use an other separator (a comma), allow both the current 
locale separator *and*
the "C" locale separator.

This issue is well known in Kicad.

> 
> On Thu, Sep 15, 2016 at 1:56 AM, jp charras  >
> wrote:
> 
> Le 14/09/2016 à 14:09, Oliver Walters a écrit :
> > Hi all,
> >
> > First time submitting a patch, so here goes
> >
> > The attached patch deals with a number of issues with regards to the 
> footprint wizards manager. It
> > started off as what I imagined was a fairly simple task to improve the 
> UX of the FP wizards
> > interface, but it evolved into something a bit more complex as I delved 
> deeper into the source!
> >
> > Improvements are as follows:
> >
> > 1. I have done away with the use of a leading asterisk to designate the 
> "units" of a wizard
> > parameter. Multiple parameter types can now be defined (integer, float, 
> mm, mils, bool, etc..)
> >
> > 2. Input validation. Each type of parameter is now validated properly 
> within the wizards screen.
> > Integer parameters can only be set to integers, dimensions can only be 
> floating point, etc.
> 
> Unfortunately, it does not work in countries which use a comma as 
> floating point separator:
> I cannot enter floating point values:
> 
> The validator expects a comma as floating point separator, and the python 
> script expects a point as
> separator.
> 
> >


-- 
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] Update version string formatting after git migration

[Nick Østergaard]

I hereby attach a patch for the mising changes.

2016-09-15 3:25 GMT+02:00 Simon Wells :
> Hey Wayne,
>
> just in regards to e7e165d WriteVersionHeader.cmake still references
> the removed bzr files if you want to remove that stuff as well
>
> Simon
>
> On Tue, Sep 13, 2016 at 12:52 AM, Wayne Stambaugh  
> wrote:
>> Probably not.  We can always resurrect it from the dead should the need
>> be.  I noticed the subversion stuff is still in there as well and we
>> haven't used svn since 2009.  I'll remove it when I get a chance.
>>
>> On 9/10/2016 4:47 PM, Simon Wells wrote:
>>> Is there any point in keeping around CreateBZRVersionHeader.cmake and
>>> FindBzr.cmake as i am not sure there is any bzr distribution methods
>>> left
>>>
>>> On Sun, Sep 11, 2016 at 12:21 AM, Nick Østergaard  wrote:
 Den 09/09/2016 20.09 skrev "Wayne Stambaugh" :
>
> Have we come to any consensus on this yet?  I'm not sure the fake bzr
> revision numbers have any meaning.  Git doesn't have any concept of
> linear commits so having a linear number will only make sense when
> building from the master repo.  These numbers will not track upstream
> for anything built from a local repo that has deviated from the main
> repo.

 This was also the case for BZR  :)

> I'm leaning towards not using them.  The hash is always accurate.
>  If the is a commit hash that's not in the main repo, then it's obvious
> that the build is someone's custom commits.  I'm OK with this patch as
> is.  If there are no majo objects, @Chris go ahead and commit it.
>
> On 8/27/2016 2:49 PM, Mark Roszko wrote:
>> rev 1234 the same meaning as rev 67230ac, you have to look it up
>> regardless on git.
>>
>> On Sat, Aug 27, 2016 at 11:48 AM, jp charras 
>> wrote:
>>> Le 27/08/2016 à 17:14, Chris Pavlina a écrit :
 Now that we've migrated from bzr, there isn't much reason to keep
 attaching a (now fake) bzr revision number to the version string.
 Additionally, we can choose a sensible default branch name if one
 isn't
 specified on the cmake line, rather than "product". This patch
 reformats
 the version strings to:

 (2016-08-26 revision 67230ac)-master
  |   ||
  |   |custom branch name if set. Otherwise,
  |   |branch name, "HEAD" if not on a branch,
  |   |  or "unknown" if no .git present
  |   |
  |   abbreviated commit hash, or no-git if no .git
  | present
  |
  date of commit, or date of build if no .git present
>>>
>>> I find the bzr revision number useful to easily know the order of
>>> revisions.
>>> the name bzr is now a bit strange, so the version string could be:
>>>
>>> (2016-08-26 rev 1234 git 67230ac)-master
>>>
>>> (users, many times, just give a rev number, no the full version string,
>>> so in a bug or mail, rev
>>> 1234 has meaning, but revision 67230ac has no meaning, at least for
>>> me).
>>>
>>> --
>>> Jean-Pierre CHARRAS
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>>
>
>
> ___
> Mailing list: https://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

From a238dd21705225f72e8a400a86eaa0a1f60c0ece Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Nick=20=C3=98stergaard?= 
Date: Thu, 15 Sep 2016 07:43:12 +0200
Subject: [PATCH] Remove now obsolete bzr check

---
 CMakeModules/WriteVersionHeader.cmake | 18 +++---
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/CMakeModules/WriteVersionHeader.cmake b/CMakeModules/WriteVersionHeader.cmake
index da1b9a4..fa10f23 100644
--- a/CMakeModules/WriteVersionHeader.cmake
+++ b/CMakeModules/WriteVersionHeader.cmake
@@ -22,20 +22,16 @@
 #  51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA
 #
 
-# Automagically create version header file if the version string was not defined during
-# the build configuration.  If CreateBzrVersionHeader or CreateGitVersionHeader cannot
-# determi

Re: [Kicad-developers] announcing eeshow (schematics renderer and viewer)

[Werner Almesberger]

Roman Pavelka wrote:
> Tested on Fedora 24 on two bigger projects, no problems at all.

Great ! Added the Fedora prerequisites to the build instructions.
Thanks a lot !

- Werner

___
Mailing list: https://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] announcing eeshow (schematics renderer and viewer)

[Werner Almesberger]

Roman Pavelka wrote:
> >> Possible enhancements
> >> * eeshow -h, eeshow --help prints usage
[...]
> You are right, but I consider these to be standard without complains.

Well, it can't hurt to support them explicitly. That way, the
option names are also clearly "reserved". Added.

> But I see there another use case, possibly with much bigger outreach:
> To be able to simply browse through your projects,

Hmm, I'm not quite sure how you'd navigate this. Would you envision
this to be just a bunch of sheets, with a really crowded index page ?

> My choice is usually to not follow, ignore and be safe by default,
> with options both to follow only file links and then to follow directories
> also.

Ah, but the symlinks are a functional part of my setup. Following
them is not optional. It just gets tricky when they make you end
up with a time paradox. Luckily, the film industry has produced
many documentaries with useful information on this topic :)

- Werner

___
Mailing list: https://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][RFC] Footprint wizards

[José Ignacio]

On Wed, Sep 14, 2016 at 5:20 PM, Oliver Walters
 wrote:
>
> Any suggestions on how I could fix this? Should I be submitting one patch
> per commit, or a single patch as I have done here? Also, can I submit a
> pull-request straight from git or is the patch-email method preferred?
>

The best way is for you to make a commit series on top of master, then
do a `git format-patch --attach origin/master` and then `git
send-email` or if you don't want to bother setting up git send-email
just grab the .patch files generated from format-patch and attach them
to this thread.

http://kicad-pcb.org/contribute/developers/#_submitting_patches

Cheers

___
Mailing list: https://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][RFC] Footprint wizards

[Niki Guldbrand]

On tor, 2016-09-15 at 08:20 +1000, Oliver Walters wrote:
> > Patches that can be applied with git am is good. In this case it
> > seems
> > like all newlines in commit comments are stripped which is not so
> > good.
> 
> Any suggestions on how I could fix this? Should I be submitting one
> patch per commit, or a single patch as I have done here? Also, can I
> submit a pull-request straight from git or is the patch-email method
> preferred? 

Normally how I format commit messages is like this:

Short description

 * More detailed description
   May span multiple lines
 * Some times there is a need for multiple detailes descriptions


See the short description as the subject line in an email.


-- 
Niki Guldbrand 

___
Mailing list: https://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 version string formatting after git migration

[Simon Wells]

Hey Wayne,

just in regards to e7e165d WriteVersionHeader.cmake still references
the removed bzr files if you want to remove that stuff as well

Simon

On Tue, Sep 13, 2016 at 12:52 AM, Wayne Stambaugh  wrote:
> Probably not.  We can always resurrect it from the dead should the need
> be.  I noticed the subversion stuff is still in there as well and we
> haven't used svn since 2009.  I'll remove it when I get a chance.
>
> On 9/10/2016 4:47 PM, Simon Wells wrote:
>> Is there any point in keeping around CreateBZRVersionHeader.cmake and
>> FindBzr.cmake as i am not sure there is any bzr distribution methods
>> left
>>
>> On Sun, Sep 11, 2016 at 12:21 AM, Nick Østergaard  wrote:
>>> Den 09/09/2016 20.09 skrev "Wayne Stambaugh" :

 Have we come to any consensus on this yet?  I'm not sure the fake bzr
 revision numbers have any meaning.  Git doesn't have any concept of
 linear commits so having a linear number will only make sense when
 building from the master repo.  These numbers will not track upstream
 for anything built from a local repo that has deviated from the main
 repo.
>>>
>>> This was also the case for BZR  :)
>>>
 I'm leaning towards not using them.  The hash is always accurate.
  If the is a commit hash that's not in the main repo, then it's obvious
 that the build is someone's custom commits.  I'm OK with this patch as
 is.  If there are no majo objects, @Chris go ahead and commit it.

 On 8/27/2016 2:49 PM, Mark Roszko wrote:
> rev 1234 the same meaning as rev 67230ac, you have to look it up
> regardless on git.
>
> On Sat, Aug 27, 2016 at 11:48 AM, jp charras 
> wrote:
>> Le 27/08/2016 à 17:14, Chris Pavlina a écrit :
>>> Now that we've migrated from bzr, there isn't much reason to keep
>>> attaching a (now fake) bzr revision number to the version string.
>>> Additionally, we can choose a sensible default branch name if one
>>> isn't
>>> specified on the cmake line, rather than "product". This patch
>>> reformats
>>> the version strings to:
>>>
>>> (2016-08-26 revision 67230ac)-master
>>>  |   ||
>>>  |   |custom branch name if set. Otherwise,
>>>  |   |branch name, "HEAD" if not on a branch,
>>>  |   |  or "unknown" if no .git present
>>>  |   |
>>>  |   abbreviated commit hash, or no-git if no .git
>>>  | present
>>>  |
>>>  date of commit, or date of build if no .git present
>>
>> I find the bzr revision number useful to easily know the order of
>> revisions.
>> the name bzr is now a bit strange, so the version string could be:
>>
>> (2016-08-26 rev 1234 git 67230ac)-master
>>
>> (users, many times, just give a rev number, no the full version string,
>> so in a bug or mail, rev
>> 1234 has meaning, but revision 67230ac has no meaning, at least for
>> me).
>>
>> --
>> Jean-Pierre CHARRAS
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>
>
>


 ___
 Mailing list: https://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 v2] Add KICAD_INSTALL_DEMOS CMake option

[Wayne Stambaugh]

Your patch has been pushed into the master repo.  Thank you for your
contribution to KiCad.

Cheers,

Wayne

On 9/8/2016 2:59 PM, José Ignacio Romero wrote:
> 
> It is ON by default, determines wether to install the bundled demos
> and examples.
> ---
> 
> This version has the required documentation changes.
> 
> ---
>  CMakeLists.txt | 6 ++
>  Documentation/development/compiling.md | 7 +++
>  2 files changed, 13 insertions(+)
> 
> 
> 
> ___
> Mailing list: https://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][RFC] Footprint wizards

[Oliver Walters]

On Thu, Sep 15, 2016 at 6:19 AM, Nick Østergaard  wrote:

> 2016-09-14 14:09 GMT+02:00 Oliver Walters  >:
> > Hi all,
> >
> > First time submitting a patch, so here goes
> >
>
> Welcome. Please be aware that your patches contain tabs, as per the
> coding style policy; the indentation level for the KiCad source code
> is defined as four spaces. Please do not use tabs.


Ok, will fix.


>
> > The attached patch deals with a number of issues with regards to the
> > footprint wizards manager. It started off as what I imagined was a fairly
> > simple task to improve the UX of the FP wizards interface, but it evolved
> > into something a bit more complex as I delved deeper into the source!
> >
>
> Lovely to see some improments. I think there are great improvements in
> here and I have tried to add some more comments inline.
>
> > Improvements are as follows:
> >
> > 1. I have done away with the use of a leading asterisk to designate the
> > "units" of a wizard parameter. Multiple parameter types can now be
> defined
> > (integer, float, mm, mils, bool, etc..)
> >
> > 2. Input validation. Each type of parameter is now validated properly
> within
> > the wizards screen. Integer parameters can only be set to integers,
> > dimensions can only be floating point, etc.
> >
> > 3. Boolean values are now treated properly. Simply click the cell to
> toggle,
> > rather than awkwardly typing "True" or "False"
> >
>
> I this this works a bit strange right now because it switches between
> showing the True/False text, but when clicking it will show the
> checkbox. Why this switching between content?
>
> To make it easer than manually typing true or false as before I would
> have expected either a combobox or a checkbox that is constantly
> there.


It looks like using a wxGridCellBoolRenderer will fix this. I'll look into
this.


> > 4. Multiple choice options available - If the python script specifies a
> list
> > of options, then a drop-down box will be displayed for that parameter
> >
>
> Is there an example script that uses lists? I could not find any of
> the default wizards proviing this option.


I'll add an example script.


>
> > 5. Param designators. Instead of the row numbers being shown, each param
> can
> > optionally be assigned a designator (such as 'e' for pitch) which will be
> > show to the left of that row.
> >
>
> I think this makes sense.
>
> It would be cool if we in the future could render dimension arrows on
> the plot for some things using those references.
>

That is a very cool idea. I had been planning on implementing the
GetImage() method which would require a dimensional drawing for each
wizard. However, with the ability to draw on the screen, you could easily
show the dimensions only for the current page of parameters, which would
de-clutter it a lot. I'm not sure how much work this would be, though.


>
> > 6. "Reset to default" - A new button in the top toolbar which resets all
> > wizard parameters to their default values
> >
> >
> > 7. More logical parameter checking within the python wizard helpers.
> > Currently each parameter needs to be explicitly checked e.g. "CheckInt"
> to
> > make sure the value is a valid integer. This patch defines a Parameter
> > holder class that automatically checks values based on their specified
> type.
> > Additionally, parameters can have other checks specified when they are
> > added, e.g:
> >
> > AddParam("Pads","width",uMM, 2.5, min_value=0.1, max_value=5.5)
> >
> > 8. Fixed script import errors in the case of "bad" scripts. Currently if
> a
> > wizard contains any errors, the LoadPlugins functions fail and no
> subsequent
> > wizards are loaded. A simple try-except block has been added around the
> > specific file loading so that one bad plugin file does not break the
> others
> >
> > 9. Auto-sizing of the parameter grid. Not a huge deal but the grid width
> now
> > expands to fill the available space.
> >
> > General Notes:
> >
> > a) To provide the functionality for multiple unit types I have had to
> > slightly break compatibility with the way that parameter types were
> defined
> > in the current wizards. However, I have designed the new Parameter class
> (in
> > kicadplugins.i) to be as close-to-compatible as it can be.
> >
>
> Maybe some notes are required on how to update the older scripts to
> ease a transition.
>
> > I have updated each of the default plugins to be compatible with the new
> > system. Only minor changes were required.
> >
> > b) I have also consolidated the helper classes
> > (HelpfulFootprintWizardPlugin) into the simpler FootprintWizard base
> class.
> >
> > c) There is now a GitHub repository for FootprintWizards -
> > https://github.com/KiCad/Footprint_Wizards - should this patch be
> accepted I
> > propose that the default wizards be further improved, and removed from
> the
> > source files. Instead, provide a link to the GitHub page or a
> > download-helper for the scripts. This way the community can contribute
> > qual

Re: [Kicad-developers] [PATCH][RFC] Footprint wizards

[Oliver Walters]

JP,

Ok, that should be a pretty easy fix. For testing on my side, how do I get
KiCad to use a comma for floating point separator? Is this a language
setting?

On Thu, Sep 15, 2016 at 1:56 AM, jp charras  wrote:

> Le 14/09/2016 à 14:09, Oliver Walters a écrit :
> > Hi all,
> >
> > First time submitting a patch, so here goes
> >
> > The attached patch deals with a number of issues with regards to the
> footprint wizards manager. It
> > started off as what I imagined was a fairly simple task to improve the
> UX of the FP wizards
> > interface, but it evolved into something a bit more complex as I delved
> deeper into the source!
> >
> > Improvements are as follows:
> >
> > 1. I have done away with the use of a leading asterisk to designate the
> "units" of a wizard
> > parameter. Multiple parameter types can now be defined (integer, float,
> mm, mils, bool, etc..)
> >
> > 2. Input validation. Each type of parameter is now validated properly
> within the wizards screen.
> > Integer parameters can only be set to integers, dimensions can only be
> floating point, etc.
>
> Unfortunately, it does not work in countries which use a comma as floating
> point separator:
> I cannot enter floating point values:
>
> The validator expects a comma as floating point separator, and the python
> script expects a point as
> separator.
>
> >
> > 3. Boolean values are now treated properly. Simply click the cell to
> toggle, rather than awkwardly
> > typing "True" or "False"
> >
> > 4. Multiple choice options available - If the python script specifies a
> list of options, then a
> > drop-down box will be displayed for that parameter
> >
> > 5. Param designators. Instead of the row numbers being shown, each param
> can optionally be assigned
> > a designator (such as 'e' for pitch) which will be show to the left of
> that row.
> >
> > 6. "Reset to default" - A new button in the top toolbar which resets all
> wizard parameters to their
> > default values
> >
> > 7. More logical parameter checking within the python wizard helpers.
> Currently each parameter needs
> > to be explicitly checked e.g. "CheckInt" to make sure the value is a
> valid integer. This patch
> > defines a Parameter holder class that automatically checks values based
> on their specified type.
> > Additionally, parameters can have other checks specified when they are
> added, e.g:
> >
> > AddParam("Pads","width",uMM, 2.5, min_value=0.1, max_value=5.5)
> >
> > 8. Fixed script import errors in the case of "bad" scripts. Currently if
> a wizard contains any
> > errors, the LoadPlugins functions fail and no subsequent wizards are
> loaded. A simple try-except
> > block has been added around the specific file loading so that one bad
> plugin file does not break the
> > others
> >
> > 9. Auto-sizing of the parameter grid. Not a huge deal but the grid width
> now expands to fill the
> > available space.
> >
> > General Notes:
> >
> > a) To provide the functionality for multiple unit types I have had to
> slightly break compatibility
> > with the way that parameter types were defined in the current wizards.
> However, I have designed the
> > new Parameter class (in kicadplugins.i) to be as close-to-compatible as
> it can be.
> >
> > I have updated each of the default plugins to be compatible with the new
> system. Only minor changes
> > were required.
> >
> > b) I have also consolidated the helper classes
> (HelpfulFootprintWizardPlugin) into the simpler
> > FootprintWizard base class.
> >
> > c) There is now a GitHub repository for FootprintWizards
> > - https://github.com/KiCad/Footprint_Wizards - should this patch be
> accepted I propose that the
> > default wizards be further improved, and removed from the source files.
> Instead, provide a link to
> > the GitHub page or a download-helper for the scripts. This way the
> community can contribute quality
> > wizards, and I shall endeavour to add some good documentation to the
> wiki page for wizard creation.
> >
> > .diff is attached - hopefully this is the right way of doing this?
> >
> > Please let me know what I can do to help this process along.
> >
> > Regards,
> >
> > Oliver
>
> Thanks for your contribution.
>
> --
> Jean-Pierre CHARRAS
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bezier curves in DRAWSEGMENT class

[Piotr Esden-Tempski]

I personally would love to see bezier/spline support in KiCad. When seeing PCB 
designs by people like Boldport one wishes the “normal” engineering tools would 
support “organic" traces too. Obviously due to the limitations of the Gerber 
file format circle approximation would be necessary. If that also makes DRC 
easier to implement it would be a plus too. I bet many others that see EE board 
design as more than just a boring engineering task and more as a creative art 
would appreciate this feature. That would propel KiCad beyond Eagle that 
supports arc traces (not supported by KiCad drawing tools at the moment, and 
has to be hand drawn using single segments). So please consider adding bezier 
or splines instead of removing them.

Cheers,
Piotr

> On Sep 14, 2016, at 5:37 AM, Nick Østergaard  wrote:
> 
> Yes, of course arcs are more important. But Cirilo mentioned that one
> could use arcs to appromimate the beiziers for DRC and gerber
> generation purposes
> 
> 2016-09-14 13:44 GMT+02:00 José Ignacio :
>> I don't see length matching splines to be any easier than length
>> matching polylines. If anything having arcs is a lot more important
>> than beziers as arcs can form circles while beziers can't exactly (you
>> need NURBS for that). Also iirc Gerbers support arcs natively so it
>> would end up generating better output.
>> 
>> On Wed, Sep 14, 2016 at 6:16 AM, Simon Wells  wrote:
>>> i have no idea whether it is actually valid but could/would bezier
>>> curves be used in differential pairs that are also length matched? so
>>> that it would keep the seperation for the differential but would also
>>> allow the lengths to be equal?
>>> 
>>> On Wed, Sep 14, 2016 at 10:51 PM, jp charras  wrote:
> On Wed, Sep 14, 2016 at 7:44 PM, Nick Østergaard  > wrote:
> 
>For some RF applications people would like to use curves for traces. 
> So DRC support for
>beizier/arcs would be nice here.
 
 I perfectly understand the interest of arcs in traces.
 
 But what the interest of Bezier curves in traces or shapes on copper 
 layers ?
 
 I am not a microwave specialist, however I never saw cases where Bezier 
 curves are needed.
 
 The more complex case I know is a filter, which works fine with polygons 
 (seen demos/microwave).
 
 AFAIK, complex shapes are generated by specialized tools (you cannot 
 easily draw them by hand).
 Are they generating shapes with Bezier curves.
 
 Moreover, remember Gerber format does not support Bezier curves, so they 
 will be converted to
 polygons if they are supported by Pcbnew.
 
 --
 Jean-Pierre CHARRAS
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp
>>> 
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> ___
> Mailing list: https://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][RFC] Footprint wizards

[Ed Johns]

Oliver,  I can't wait to try the patch.  I've been hoping someone would
take another look at the wizard GUI for a while (I use it all the time).
Thanks!

Nick,

>
> It would be cool if we in the future could render dimension arrows on
> the plot for some things using those references.
>

The footprint wizard has an image property that was never implemented in
the GUI.  I always assumed it was for a dimension drawing, but I could be
completely wrong.

Have a good one.

-Ed
___
Mailing list: https://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][RFC] Footprint wizards

[Nick Østergaard]

2016-09-14 14:09 GMT+02:00 Oliver Walters :
> Hi all,
>
> First time submitting a patch, so here goes
>

Welcome. Please be aware that your patches contain tabs, as per the
coding style policy; the indentation level for the KiCad source code
is defined as four spaces. Please do not use tabs.

> The attached patch deals with a number of issues with regards to the
> footprint wizards manager. It started off as what I imagined was a fairly
> simple task to improve the UX of the FP wizards interface, but it evolved
> into something a bit more complex as I delved deeper into the source!
>

Lovely to see some improments. I think there are great improvements in
here and I have tried to add some more comments inline.

> Improvements are as follows:
>
> 1. I have done away with the use of a leading asterisk to designate the
> "units" of a wizard parameter. Multiple parameter types can now be defined
> (integer, float, mm, mils, bool, etc..)
>
> 2. Input validation. Each type of parameter is now validated properly within
> the wizards screen. Integer parameters can only be set to integers,
> dimensions can only be floating point, etc.
>
> 3. Boolean values are now treated properly. Simply click the cell to toggle,
> rather than awkwardly typing "True" or "False"
>

I this this works a bit strange right now because it switches between
showing the True/False text, but when clicking it will show the
checkbox. Why this switching between content?

To make it easer than manually typing true or false as before I would
have expected either a combobox or a checkbox that is constantly
there.

> 4. Multiple choice options available - If the python script specifies a list
> of options, then a drop-down box will be displayed for that parameter
>

Is there an example script that uses lists? I could not find any of
the default wizards proviing this option.

> 5. Param designators. Instead of the row numbers being shown, each param can
> optionally be assigned a designator (such as 'e' for pitch) which will be
> show to the left of that row.
>

I think this makes sense.

It would be cool if we in the future could render dimension arrows on
the plot for some things using those references.

> 6. "Reset to default" - A new button in the top toolbar which resets all
> wizard parameters to their default values
>
>
> 7. More logical parameter checking within the python wizard helpers.
> Currently each parameter needs to be explicitly checked e.g. "CheckInt" to
> make sure the value is a valid integer. This patch defines a Parameter
> holder class that automatically checks values based on their specified type.
> Additionally, parameters can have other checks specified when they are
> added, e.g:
>
> AddParam("Pads","width",uMM, 2.5, min_value=0.1, max_value=5.5)
>
> 8. Fixed script import errors in the case of "bad" scripts. Currently if a
> wizard contains any errors, the LoadPlugins functions fail and no subsequent
> wizards are loaded. A simple try-except block has been added around the
> specific file loading so that one bad plugin file does not break the others
>
> 9. Auto-sizing of the parameter grid. Not a huge deal but the grid width now
> expands to fill the available space.
>
> General Notes:
>
> a) To provide the functionality for multiple unit types I have had to
> slightly break compatibility with the way that parameter types were defined
> in the current wizards. However, I have designed the new Parameter class (in
> kicadplugins.i) to be as close-to-compatible as it can be.
>

Maybe some notes are required on how to update the older scripts to
ease a transition.

> I have updated each of the default plugins to be compatible with the new
> system. Only minor changes were required.
>
> b) I have also consolidated the helper classes
> (HelpfulFootprintWizardPlugin) into the simpler FootprintWizard base class.
>
> c) There is now a GitHub repository for FootprintWizards -
> https://github.com/KiCad/Footprint_Wizards - should this patch be accepted I
> propose that the default wizards be further improved, and removed from the
> source files. Instead, provide a link to the GitHub page or a
> download-helper for the scripts. This way the community can contribute
> quality wizards, and I shall endeavour to add some good documentation to the
> wiki page for wizard creation.
>
> .diff is attached - hopefully this is the right way of doing this?
>

Patches that can be applied with git am is good. In this case it seems
like all newlines in commit comments are stripped which is not so
good.

I wonder why you make a construct like this in 0001.
#if defined( __MINGW32__ )
path = A
#elif defined( __WXMAC__ )
path = B
#else
path = A
#endif

Why not like this?
#if defined( __WXMAC__ )
path = B
#else
path = A
#endif

> Please let me know what I can do to help this process along.
>
> Regards,
>
> Oliver
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post t

Re: [Kicad-developers] osx packages

[Andy Peters]

> On Sep 9, 2016, at 4:38 PM, Adam Wolf  wrote:
> 
> Good, I ordered a new SSD this week, so it should be here soon.  I'll install 
> MacOS Sierra on there, and rebuild my environment there.  I think it is 
> realistic to have signed packages out by October.
> 
> As soon as the SSD is here and I have the OS up and running, I'll jump on IRC 
> and see if we can split some of the work up.

The hard drive in my 17” MacBook Pro died, so I replaced it with an SSD. What a 
difference! It’s like a new machine.

I noticed that Xcode 8 was just pushed out. I can do build tests with it, if 
you guys need an extra tester. I will put Sierra on the MBP. My other Mac is a 
2008 iMac which won’t go past El Capitan.

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

Re: [Kicad-developers] [PATCH][RFC] Footprint wizards

[jp charras]

Le 14/09/2016 à 14:09, Oliver Walters a écrit :
> Hi all,
> 
> First time submitting a patch, so here goes
> 
> The attached patch deals with a number of issues with regards to the 
> footprint wizards manager. It
> started off as what I imagined was a fairly simple task to improve the UX of 
> the FP wizards
> interface, but it evolved into something a bit more complex as I delved 
> deeper into the source!
> 
> Improvements are as follows:
> 
> 1. I have done away with the use of a leading asterisk to designate the 
> "units" of a wizard
> parameter. Multiple parameter types can now be defined (integer, float, mm, 
> mils, bool, etc..)
> 
> 2. Input validation. Each type of parameter is now validated properly within 
> the wizards screen.
> Integer parameters can only be set to integers, dimensions can only be 
> floating point, etc.

Unfortunately, it does not work in countries which use a comma as floating 
point separator:
I cannot enter floating point values:

The validator expects a comma as floating point separator, and the python 
script expects a point as
separator.

> 
> 3. Boolean values are now treated properly. Simply click the cell to toggle, 
> rather than awkwardly
> typing "True" or "False"
> 
> 4. Multiple choice options available - If the python script specifies a list 
> of options, then a
> drop-down box will be displayed for that parameter
> 
> 5. Param designators. Instead of the row numbers being shown, each param can 
> optionally be assigned
> a designator (such as 'e' for pitch) which will be show to the left of that 
> row.
> 
> 6. "Reset to default" - A new button in the top toolbar which resets all 
> wizard parameters to their
> default values
> 
> 7. More logical parameter checking within the python wizard helpers. 
> Currently each parameter needs
> to be explicitly checked e.g. "CheckInt" to make sure the value is a valid 
> integer. This patch
> defines a Parameter holder class that automatically checks values based on 
> their specified type.
> Additionally, parameters can have other checks specified when they are added, 
> e.g:
> 
> AddParam("Pads","width",uMM, 2.5, min_value=0.1, max_value=5.5)
> 
> 8. Fixed script import errors in the case of "bad" scripts. Currently if a 
> wizard contains any
> errors, the LoadPlugins functions fail and no subsequent wizards are loaded. 
> A simple try-except
> block has been added around the specific file loading so that one bad plugin 
> file does not break the
> others
> 
> 9. Auto-sizing of the parameter grid. Not a huge deal but the grid width now 
> expands to fill the
> available space.
> 
> General Notes:
> 
> a) To provide the functionality for multiple unit types I have had to 
> slightly break compatibility
> with the way that parameter types were defined in the current wizards. 
> However, I have designed the
> new Parameter class (in kicadplugins.i) to be as close-to-compatible as it 
> can be. 
> 
> I have updated each of the default plugins to be compatible with the new 
> system. Only minor changes
> were required.
> 
> b) I have also consolidated the helper classes (HelpfulFootprintWizardPlugin) 
> into the simpler
> FootprintWizard base class. 
> 
> c) There is now a GitHub repository for FootprintWizards
> - https://github.com/KiCad/Footprint_Wizards - should this patch be accepted 
> I propose that the
> default wizards be further improved, and removed from the source files. 
> Instead, provide a link to
> the GitHub page or a download-helper for the scripts. This way the community 
> can contribute quality
> wizards, and I shall endeavour to add some good documentation to the wiki 
> page for wizard creation.
> 
> .diff is attached - hopefully this is the right way of doing this?
> 
> Please let me know what I can do to help this process along.
> 
> Regards,
> 
> Oliver

Thanks for your contribution.

-- 
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] Bezier curves in DRAWSEGMENT class

[Nick Østergaard]

Yes, of course arcs are more important. But Cirilo mentioned that one
could use arcs to appromimate the beiziers for DRC and gerber
generation purposes

2016-09-14 13:44 GMT+02:00 José Ignacio :
> I don't see length matching splines to be any easier than length
> matching polylines. If anything having arcs is a lot more important
> than beziers as arcs can form circles while beziers can't exactly (you
> need NURBS for that). Also iirc Gerbers support arcs natively so it
> would end up generating better output.
>
> On Wed, Sep 14, 2016 at 6:16 AM, Simon Wells  wrote:
>> i have no idea whether it is actually valid but could/would bezier
>> curves be used in differential pairs that are also length matched? so
>> that it would keep the seperation for the differential but would also
>> allow the lengths to be equal?
>>
>> On Wed, Sep 14, 2016 at 10:51 PM, jp charras  wrote:
 On Wed, Sep 14, 2016 at 7:44 PM, Nick Østergaard >>> > wrote:

 For some RF applications people would like to use curves for traces. 
 So DRC support for
 beizier/arcs would be nice here.
>>>
>>> I perfectly understand the interest of arcs in traces.
>>>
>>> But what the interest of Bezier curves in traces or shapes on copper layers 
>>> ?
>>>
>>> I am not a microwave specialist, however I never saw cases where Bezier 
>>> curves are needed.
>>>
>>> The more complex case I know is a filter, which works fine with polygons 
>>> (seen demos/microwave).
>>>
>>> AFAIK, complex shapes are generated by specialized tools (you cannot easily 
>>> draw them by hand).
>>> Are they generating shapes with Bezier curves.
>>>
>>> Moreover, remember Gerber format does not support Bezier curves, so they 
>>> will be converted to
>>> polygons if they are supported by Pcbnew.
>>>
>>> --
>>> Jean-Pierre CHARRAS
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://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 v2] Add KICAD_INSTALL_DEMOS CMake option

[Wayne Stambaugh]

Thanks for the info.  I had just attempted to merger Werner's patch and
got the same error message and I did notice the difference.  I'll try
merging using the full email when I get a chance.

On 9/13/2016 8:37 PM, Chris Pavlina wrote:
> He used 'git send-email', which also gives 'git am'-compatible patches.
> You can merge this the same as usual, but you have to save the entire
> email and then pass that to 'git am'. I just tested it, works fine.
> 
> On Tue, Sep 13, 2016 at 07:45:35PM -0400, Wayne Stambaugh wrote:
>> Jose,
>>
>> Please use `git format-patch` for submitting patches.  It makes it
>> easier for me to merger your patches.
>>
>> Thanks,
>>
>> Wayne
>>
>> On 9/8/2016 2:59 PM, José Ignacio Romero wrote:
>>>
>>> It is ON by default, determines wether to install the bundled demos
>>> and examples.
>>> ---
>>>
>>> This version has the required documentation changes.
>>>
>>> ---
>>>  CMakeLists.txt | 6 ++
>>>  Documentation/development/compiling.md | 7 +++
>>>  2 files changed, 13 insertions(+)
>>>
>>>
>>>
>>> ___
>>> Mailing list: https://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] pcbnew zoom bug in OpenGL at min zoom, Any one else seeing this ?

[Maciej Sumiński]

Hi Lachlan,

I cannot reproduce the problem on any of the machines I have at hand.
Would you give more details? Does it happen with every board? How about
Cairo? What video card do you have?

I would be grateful if this message was transformed into a proper bug
report, otherwise it is likely to drown in the tons of incoming mails.

Regards,
Orson

On 09/09/2016 06:29 PM, Lachlan Audas wrote:
> When you zoom back in pcbnew to a  0.37 with the mouse wheel in Legacy
> canvas, it  stops zooming  at 0.37 (zoom level)
> but when you go to OpenGL and the do the same thing, PCB disappears!  Is
> any one else seeing this ?
> 
> And one more note the Copy Version info in the help->about KiCad,  has no
> info as to where it copy's
> info to.   I know it copy's to the clip board, but should it not tell you,
> the version info has been copied to the clip board?
> 
> Lachlan
> 
> System info follows
> 
> Application: kicad
> Version: (2016-09-09 BZR 7139, Git e25630b)-product, release build
> Libraries: wxWidgets 3.0.2
>libcurl/7.38.0 OpenSSL/1.0.1t zlib/1.2.8 libidn/1.29
> libssh2/1.4.3 librtmp/2.3
> Platform: Linux 3.16.0-4-amd64 x86_64, 64 bit, Little endian, wxGTK
> - Build Info -
> wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8)
> Boost: 1.55.0
> Curl: 7.38.0
> KiCad - Compiler: GCC 4.8.4 with C++ ABI 1002
> Settings: USE_WX_GRAPHICS_CONTEXT=OFF
>   USE_WX_OVERLAY=OFF
>   KICAD_SCRIPTING=OFF
>   KICAD_SCRIPTING_MODULES=OFF
>   KICAD_SCRIPTING_WXPYTHON=OFF
>   BUILD_GITHUB_PLUGIN=ON
>   KICAD_USE_SCH_IO_MANAGER=OFF
>   KICAD_USE_OCE=OFF
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 




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] Bezier curves in DRAWSEGMENT class

[José Ignacio]

I don't see length matching splines to be any easier than length
matching polylines. If anything having arcs is a lot more important
than beziers as arcs can form circles while beziers can't exactly (you
need NURBS for that). Also iirc Gerbers support arcs natively so it
would end up generating better output.

On Wed, Sep 14, 2016 at 6:16 AM, Simon Wells  wrote:
> i have no idea whether it is actually valid but could/would bezier
> curves be used in differential pairs that are also length matched? so
> that it would keep the seperation for the differential but would also
> allow the lengths to be equal?
>
> On Wed, Sep 14, 2016 at 10:51 PM, jp charras  wrote:
>>> On Wed, Sep 14, 2016 at 7:44 PM, Nick Østergaard >> > wrote:
>>>
>>> For some RF applications people would like to use curves for traces. So 
>>> DRC support for
>>> beizier/arcs would be nice here.
>>
>> I perfectly understand the interest of arcs in traces.
>>
>> But what the interest of Bezier curves in traces or shapes on copper layers ?
>>
>> I am not a microwave specialist, however I never saw cases where Bezier 
>> curves are needed.
>>
>> The more complex case I know is a filter, which works fine with polygons 
>> (seen demos/microwave).
>>
>> AFAIK, complex shapes are generated by specialized tools (you cannot easily 
>> draw them by hand).
>> Are they generating shapes with Bezier curves.
>>
>> Moreover, remember Gerber format does not support Bezier curves, so they 
>> will be converted to
>> polygons if they are supported by Pcbnew.
>>
>> --
>> Jean-Pierre CHARRAS
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] Bezier curves in DRAWSEGMENT class

[Simon Wells]

i have no idea whether it is actually valid but could/would bezier
curves be used in differential pairs that are also length matched? so
that it would keep the seperation for the differential but would also
allow the lengths to be equal?

On Wed, Sep 14, 2016 at 10:51 PM, jp charras  wrote:
>> On Wed, Sep 14, 2016 at 7:44 PM, Nick Østergaard > > wrote:
>>
>> For some RF applications people would like to use curves for traces. So 
>> DRC support for
>> beizier/arcs would be nice here.
>
> I perfectly understand the interest of arcs in traces.
>
> But what the interest of Bezier curves in traces or shapes on copper layers ?
>
> I am not a microwave specialist, however I never saw cases where Bezier 
> curves are needed.
>
> The more complex case I know is a filter, which works fine with polygons 
> (seen demos/microwave).
>
> AFAIK, complex shapes are generated by specialized tools (you cannot easily 
> draw them by hand).
> Are they generating shapes with Bezier curves.
>
> Moreover, remember Gerber format does not support Bezier curves, so they will 
> be converted to
> polygons if they are supported by Pcbnew.
>
> --
> Jean-Pierre CHARRAS
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] Bezier curves in DRAWSEGMENT class

[jp charras]

> On Wed, Sep 14, 2016 at 7:44 PM, Nick Østergaard  > wrote:
> 
> For some RF applications people would like to use curves for traces. So 
> DRC support for
> beizier/arcs would be nice here.

I perfectly understand the interest of arcs in traces.

But what the interest of Bezier curves in traces or shapes on copper layers ?

I am not a microwave specialist, however I never saw cases where Bezier curves 
are needed.

The more complex case I know is a filter, which works fine with polygons (seen 
demos/microwave).

AFAIK, complex shapes are generated by specialized tools (you cannot easily 
draw them by hand).
Are they generating shapes with Bezier curves.

Moreover, remember Gerber format does not support Bezier curves, so they will 
be converted to
polygons if they are supported by Pcbnew.

-- 
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] Bezier curves in DRAWSEGMENT class

[Cirilo Bernardo]

On Wed, Sep 14, 2016 at 7:44 PM, Nick Østergaard  wrote:

> For some RF applications people would like to use curves for traces. So
> DRC support for beizier/arcs would be nice here.
>
>
That would be possible with polyline and would avoid the high computational
cost of finding an intersection with a Bezier (or any spline equation).

- Cirilo



> Den 14/09/2016 08.14 skrev "jp charras" :
>
>> Le 14/09/2016 à 01:19, Tomasz Wlostowski a écrit :
>> > On 14.09.2016 00:00, Cirilo Bernardo wrote:
>> >> I think it would be nice to support Bezier curves but aside from adding
>> >> support for editing those curves, I think we need a good enough 2D
>> >> geometry kernel so that we can improve zone outlines and perhaps
>> >> even allow tracks to be straight, arc, or Bezier curve. In general
>> though
>> >> I think good support for "PolyLine" would be of more general use; after
>> >> all any 2D Bezier curve can be easily approximated with a series of
>> >> circular arcs (which a Polyline can do).
>> >
>> > Cirilo, JP,
>> >
>> > I agree we need copper layer arc support. I'm reluctant to add Bezier
>> > curves unless they are approximated as polylines because of the
>> > complexity of necessary DRC functions. Writing an accurate arc-to-arc or
>> > arc-to-segment collision/distance check is already quite difficult.
>> >
>> > Besides, what would be the use of such curves for PCB design other than
>> > fancy graphics (silkscreen, etc)?
>> >
>> > Tom
>>
>> AFAIK, it was never intended to be used on copper layers, only for fancy
>> graphics.
>> It is not yet in use because the cost to use Bezier curves is high
>> (editor, locate functions ...)
>> and the benefit is low.
>>
>>
>> --
>> Jean-Pierre CHARRAS
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Bezier curves in DRAWSEGMENT class

[Nick Østergaard]

For some RF applications people would like to use curves for traces. So DRC
support for beizier/arcs would be nice here.

Den 14/09/2016 08.14 skrev "jp charras" :

> Le 14/09/2016 à 01:19, Tomasz Wlostowski a écrit :
> > On 14.09.2016 00:00, Cirilo Bernardo wrote:
> >> I think it would be nice to support Bezier curves but aside from adding
> >> support for editing those curves, I think we need a good enough 2D
> >> geometry kernel so that we can improve zone outlines and perhaps
> >> even allow tracks to be straight, arc, or Bezier curve. In general
> though
> >> I think good support for "PolyLine" would be of more general use; after
> >> all any 2D Bezier curve can be easily approximated with a series of
> >> circular arcs (which a Polyline can do).
> >
> > Cirilo, JP,
> >
> > I agree we need copper layer arc support. I'm reluctant to add Bezier
> > curves unless they are approximated as polylines because of the
> > complexity of necessary DRC functions. Writing an accurate arc-to-arc or
> > arc-to-segment collision/distance check is already quite difficult.
> >
> > Besides, what would be the use of such curves for PCB design other than
> > fancy graphics (silkscreen, etc)?
> >
> > Tom
>
> AFAIK, it was never intended to be used on copper layers, only for fancy
> graphics.
> It is not yet in use because the cost to use Bezier curves is high
> (editor, locate functions ...)
> and the benefit is low.
>
>
> --
> Jean-Pierre CHARRAS
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Spice simulator: need info about net names versus net number option

[jp charras]

Hi Orson, Tomasz:

Recently, I tried to remove a fully outdated spice option netlist: use net 
numbers or net names.
I am thinking it is not needed by spice simulators since 20 years.

But I saw it is still used in our spice simulator.
This is very easy to change, but my question is:
Is it a reason (calculation time or something else) to use net numbers instead 
of net names in
Kicad/ngspice simulator and which prevent me to use only net names (and remove 
useless old code)?

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] "Multichannel signed distance field" font rendering

[Maciej Sumiński]

Michael,

Thank you very much for your work on the MSDF text rendering, it is an
significant improvement to the previous algorithm. I have just pushed
your changes to the master branch.

Regards,
Orson

On 09/13/2016 01:38 PM, Michael Steinberg wrote:
> Hello all!
> 
> Thank you very much for the feedback. As I understand the technique
> works well enough on many different hardware levels (I'm using it myself
> in an i5 iGPU), so that's good to know. I tweaked the character
> placement to get in accordance with what the truetype font specifies.
> Beside other issues, this fixes the reported GND baseline problem, still
> their bounding boxes are not bottom-aligned, but their baselines are.
> These changes were pushed to the sdf branch.
> There are some issues left that I would call minor (some special chars
> show slight glitches), but I would think that should not be a
> showstopper for now, I will still eventually try to address them. So
> unless there are important issues left I would polish the codestyle and
> get in touch with Orson for inclusion?
> 
> The atlas tool is now available on Github with CMake support (thank you
> very much José!), so there should be no "blackbox"-problem remaining.
> 
> Cheers!
> Michael




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