Re: [Kicad-developers] Git transition

[Mark Roszko]

gitconfig is not loaded by git for security unless you explicitly tell it to.

i.e. a user still has to run

git config --local include.path ../.gitconfig

___
Mailing list: https://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] Git transition

[Simon Wells]

After having messed up my first emailed patch due to missing this
email, would it not be better to add a .gitconfig to the project tree
which includes this helper script by default?

On Fri, Aug 12, 2016 at 9:36 PM, Maciej Sumiński
 wrote:
> On 08/11/2016 08:28 PM, Wayne Stambaugh wrote:
> [snip]
>> I'll see if I can figure out how to do this and if it works we can use
>> it instead of adding the bug report url to the commit message.  I wonder
>> if we can link a commit to a bug report?  That could be an issue if we
>> cannot.  I don't want to have to always create a separate branch, push
>> it to my personal repo, and then merge it into the product branch for
>> simple bug fixes.
>
> I already link commits to corresponding bug reports, see an example [1].
>
> To make life even easier, I have just pushed an additional git config
> file (rev 7022). To enable it:
>
>   git config --add include.path "$(pwd)/helpers/git/fixes_alias"
>
> And afterwards:
>
>   
>   git commit -a -m "Fixed a memleak"
>   git fixes 123456
>   git push
>
> In the current form it is a mix of what Wayne and Chris have suggested,
> so in the end you will get:
>
> orson@pcbe15262 ~/workspace/kicad % git log -n1
> commit 4ea4dcd67d89ce612aa1826dc845cc1137040fbf
> Author: Maciej Suminski 
> Date:   Fri Aug 12 11:34:06 2016 +0200
>
> Fixed a memleak
>
> Fixes: lp:123456
> * https://bugs.launchpad.net/kicad/+bug/123456
>
> Regards,
> Orson
>
> 1. https://bugs.launchpad.net/kicad-git-test/+bug/1612107
>
>
> ___
> Mailing list: https://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

[Cirilo Bernardo]

In addition to that, the error in the approximation can be made as small as
we wish and it's not difficult to achieve <1 micron error if you really want
Gerber outputs to be that precise. This is "approximation" in the
mathematical
sense and not in the general use of the language, so we control the error.

- Cirilo

On Fri, Sep 16, 2016 at 11:37 PM, Nick Østergaard  wrote:

> What was mentiomed was to approximate for example beziers with arcs. That
> would still be accurate when exported to gerbers, because one could use
> arcs which are supported in gerbers IIRC.
>
> Den 16/09/2016 15.34 skrev "Wayne Stambaugh" :
>
>> I would like to see arc support in copper layers as well but we need to
>> approach this carefully.  One thing KiCad has been pretty good at is not
>> producing broken gerber files.  A lot of code would have to be written
>> to support this fully.  When I here words like "approximate", it makes
>> me nervous.  Gerber output, particularly copper layers should not be
>> approximations, they need to be accurate down the accuracy of the gerber
>> plot formatting.
>>
>> On 9/14/2016 8: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
>>
>
> ___
> Mailing list: https://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] VRML Export

[Cirilo Bernardo]

OK, with the feedback from Maurice and Mario I have retained the Inline{}
option but
changed the behavior:

+ If "Copy 3D model files" is activated then Inline{} is used, otherwise a
monolithic
file is written. This removes the previous behavior that absolute paths can
be used in
Inline{}; the absolute paths are bad anyway since they differ depending on
the OS
and VRML files cannot be shared easily. With this new behavior it will be
easier to
share VRML files which use Inline{}.

+ In the case of a monolithic file, DEF/USE will be employed. This
typically makes
the file smaller, especially if complex components have many instances. If
people
want an option to not use DEF/USE let me know and I can add Yet Another Flag
to the export UI.

The rework is *mostly* done; I only need to add a few routines to create
the board
model in the monolithic file (basically pass existing tesselation data and
color data
to the KiCad scenegraph library).

Any more comments/suggestions?

- Cirilo


On Fri, Sep 16, 2016 at 9:20 AM, easyw  wrote:

> Hi Cirilo,
> I found inline{} VRML export option very useful and powerful...
>
> it allows an easy post elaboration to i.e. change color to pcb board,
> traces and solder mask with some macro or tweak the VRML models to add
> texture to the VRML result for an improved visualization or even add a vrml
> model inline{} to a 3D part to include some external extra objects not
> present in the pcbnew...
>
> I use Blender to import kicad VRML exported boards and I use also material
> properties without any issues with the actual develop build branch...
>
> So in case of a rewriting of the VRML exporter, I would consider very
> useful to leave at least an option to conserve the actual inline{}
> structure.
>
> Thank you
> Maurice
>
>
> On 16/09/2016 00:25, Cirilo Bernardo wrote:
>
>> Hi folks,
>>
>>  Since the merge of the new 3DViewer the VRML Export routine has not
>> been able to include x3d data and the few x3d users out there have not
>> been very happy about this. However, the scenegraph library developed
>> for the 3D plugin system can easily write monolithic files which include
>> visualization data for all file formats supported by plugins. This means
>> that VRML Export can now be modified to either (a) continue to use
>> inline{} when a file is created and when copying files the scenegraph
>> library is used to write VRML model equivalents of other file formats
>> (x3d, STEP, IGES, IDF) or (b) create a monolithic file with all models
>> defined internally and reused wherever possible. Personally I would
>> prefer (b) since that would eliminate some options in the Export routine
>> such as "Copy Model Files" and would also eliminate the problem of
>> inline{} compatibility with some viewers. There may be problems with
>> DEF/USE within some programs like Blender but I can always add an
>> option to not reuse definitions (Blender's VRML code has so many
>> problems though that I doubt this would help).
>>
>> Any thoughts before I go ahead and rework the VRML exporter?
>>
>> - 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] Add wxwidgets patch for unicode pasteboard. based on upstream https://github.com/wxWidgets/wxWidgets/commit/73fca4c37d1ee2e9e495aaa68442cdfcb4243b52

[Adam Wolf]

Awesome!  This has been driving some people crazy on the bug tracker.

On Fri, Sep 16, 2016 at 6:25 PM, Simon Wells  wrote:

>
> Fixes: lp:1559103
> ---
>  patches/wxwidgets-3.0.2_macosx_unicode_pasteboard.patch | 16
> 
>  1 file changed, 16 insertions(+)
>  create mode 100644 patches/wxwidgets-3.0.2_macosx_unicode_pasteboard.
> patch
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] [PATCH] Add wxwidgets patch for unicode pasteboard. based on upstream https://github.com/wxWidgets/wxWidgets/commit/73fca4c37d1ee2e9e495aaa68442cdfcb4243b52

[Simon Wells]

Fixes: lp:1559103
---
 patches/wxwidgets-3.0.2_macosx_unicode_pasteboard.patch | 16 
 1 file changed, 16 insertions(+)
 create mode 100644 patches/wxwidgets-3.0.2_macosx_unicode_pasteboard.patch

diff --git a/patches/wxwidgets-3.0.2_macosx_unicode_pasteboard.patch b/patches/wxwidgets-3.0.2_macosx_unicode_pasteboard.patch
new file mode 100644
index 000..b65f388
--- /dev/null
+++ b/patches/wxwidgets-3.0.2_macosx_unicode_pasteboard.patch
@@ -0,0 +1,16 @@
+--- src/osx/carbon/dataobj.cpp	2016-09-17 10:26:10.0 +1200
 src/osx/carbon/dataobj.cpp	2016-09-17 10:26:23.0 +1200
+@@ -458,13 +458,11 @@ bool wxDataObject::GetFromPasteboard( vo
+ pastelocationset = true;
+}
+ }
+-#if 0 // See https://groups.google.com/forum/#!topic/wx-dev/wFxevpvbhvQ/discussion
+ else if ( flavorFormat.GetType() != wxDF_PRIVATE )
+ {
+ // indicate the expected format for the type, benefiting from native conversions eg utf8 -> utf16
+ flavorType = (CFStringRef) wxDataFormat( flavorFormat.GetType()).GetFormatId();
+ }
+-#endif
+ 
+ err = PasteboardCopyItemFlavorData( pasteboard, itemID, flavorType ,  );
+ if ( err == noErr )
___
Mailing list: https://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] Updating the README

[Wayne Stambaugh]

Patch committed.  Thanks Nick.

On 9/16/2016 4:12 PM, Nick Østergaard wrote:
> 2016-09-15 20:33 GMT+02:00 Wayne Stambaugh :
>> On 9/15/2016 1:39 PM, Nick Østergaard wrote:
>>> Hi
>>>
>>> I was going to submit a patch to update the short description for the
>>> various folders in the the root of the kicad source repo, but I am a
>>> bit confused to what to write for the "new" folder.
>>>
>>> My best suggestion for it was something like "Old crap (not built)" or
>>> Draft for undocumented SWEET concept. Those descriptions are not
>>> really helpfull at all.
>>
>> Sweet is the eeschema analog to pcbnew's pretty.  It's just the name
>> given to the new component library file format.  Once sweet is
>> implemented KiCad will be pretty sweet.  Yes, it's silly.  But what's
>> life without a little whimsy.
>>
> 
> I see. Attached is my proposal for a more up to date overview.
> 
> Please note the TODO.txt description. Maybe it should just be removed,
> and possibly be moved to the doxygen devdocs if it is supposed to
> exist.
> 
> Also, it seems that the helpers and tools dir have sort of similar purpose.
> 
>>>
>>> What is the use of this folder? As far as I can see nothing in there
>>> is built. it seems to be a stashing place for something called SWEET.
>>>
>>> Is this a eeschema pendant to pcbnew's pretties?
>>> Is the new folder to be deleted or kept for future reference?
>>> Is this related to Wayne's eeschema refactoring?
>>
>> Possibly, that's why it's been kept around.  Once the new schematic and
>> file formats are completed, I will remove the new/ folder.
>>
> 
> Ok.
> 
>>>
>>> Nick
>>>
>>> ___
>>> Mailing list: https://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] [BZR] Further cleanup post switch to git.

[Wayne Stambaugh]

Patch committed.  Thank you for your contribution to KiCad.

On 9/15/2016 6:54 PM, Niki Guldbrand wrote:
> 
> * Remove the obsolete bzr rules file.
> 
> Signed-off-by: Niki Guldbrand 
> ---
>  rules | 27 ---
>  1 file changed, 27 deletions(-)
>  delete mode 100644 rules
> 
> 
> 
> ___
> Mailing list: https://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] Patch consistency & OS X documentation error

[Wayne Stambaugh]

On 9/16/2016 1:07 PM, Bernhard Stegmaier wrote:
> Question for me is if we shouldn’t just fork wxWidgets on github and
> maintain a separate kicad branch there (I started this already for myself).
> Would get rid of all the nasty patching and everybody willing to build
> on his own could use this as a single source…

This might make sense for the package devs but how would devs building
from source know where to look for the "official" wxWidgets source.
This may be confusing.  I really don't know if there is a good way to
handle this.  It would be nice if wxWidgets would accept the patches and
roll out a 3.0.3 release so we don't have to maintain them ourselves but
I guess that is asking too much.

> 
> 
> Regards,
> Bernhard
> 
>> On 16 Sep 2016, at 17:14, Adam Wolf > > wrote:
>>
>> Sorry, I used the wrong email address before and my email didn't go
>> through.
>>
>> I think this is correct, and I would like all the patches to be in the
>> same format.  Nick and Simon and I are working on revamping the OS X
>> packaging scripts so that we get signing and a bunch of improvements
>> from the last year, and we can handle any changes made here, during
>> this revamp, so there's no extra burden on the packaging side for this.
>>
>> Please note we have moved to 10.9 as a min OS X version, so anything
>> only needed for 10.7 and 10.8 should be removed.
>>
>> Adam Wolf
>>
>>
>> On Fri, Sep 16, 2016 at 10:01 AM, Wayne Stambaugh
>> > wrote:
>>
>> Would one of our osx devs please comment on this?  I don't know if
>> this
>> patch makes sense.  I'll fix the path issue in compiling.md
>> .
>>
>> @Collin, please format your patches using git format-patch.  It makes
>> life easier for devs to commit your patches.
>>
>> On 9/15/2016 6:21 AM, Collin Anderson wrote:
>> > Hi, this is more of a tiny proposal in patch form, and a trivial
>> one so if there is reason to reject it that I haven't thought of
>> (or its just not wanted) please do so!
>> >
>> >
>> > The current wxwidgets patches in the /patches
>> directory use inconsistent formatting.  The majority use "===
>> modified fie '...' " headers for each file, but some of the more
>> recent ones use the command run as the header, but this causes
>> problems if you try to combine the patches.  Anyone making build
>> scripts or just wants to save time by using cat to merge the
>> patches into one file, or simply pipe the output directly to patch
>> will be unable to do so, and they'll have to manually run patch
>> for each patchfile with the 'diff' headers.  It just seems
>> needlessly inconsistent.  Altering the headers to all use "===
>> modified file" headers will not break anyone's scripts etc., as
>> far as I know.
>> >
>> > Also, one of the patches,
>> wxwidgets-3.0.2_macosx_data_view_ctrl.patch, won't even patch
>> correctly using -p0, it is set up so it requires -p1.
>> >
>> > All this patch does is make the patch headers consistent and
>> patch paths all have consistent --strip (-p) levels, that of 0.
>> >
>> > That is all included in patch_patch.patch
>> >
>> > Oh, and on a related note, I noticed the path has gotten mangled
>> in the compling.md  documentation:
>> >
>> >> Download the wxPython source and build using the following
>> commands:
>> >>
>> >> cd path-to-wxwidgets-src
>> >> patch -p0 <
>> path-to-kicad-src/patches/wxwidgets-3.0.0_macosx.patch
>> >> patch -p0 <
>> path-to-kicad-src/wxwidgets-3.0.0_macosx_bug_15908.patch 
>>  <--- /path/ missing from path here
>> >> patch -p0 <
>> path-to-kicad-src/patches/wxwidgets-3.0.0_macosx_soname.patch
>> >> patch -p0 <
>> path-to-kicad-src/patches/wxwidgets-3.0.2_macosx_yosemite.patch
>> >> patch -p0 <
>> path-to-kicad-src/patches/wxwidgets-3.0.0_macosx_scrolledwindow.patch
>> >> mkdir build
>> >>
>> >
>> >
>> > Also, I wanted to confirm, are these the only patches that
>> should be applied? For 10.7, I think it is correct.
>> >
>> > Maybe we could add something explicitly saying what the other
>> wxwidgets patches are for (or rather, when they are to be used). 
>> The yosemite one is obvious, magnify event is for El Capitan, not
>> sure about the retina patch or dataview patch.  I think we should
>> mention them in the documentation though, rather than expecting
>> someone trying to build kicad to discover them on their own.
>> >
>> > Anyway, I know this is about as trivial a matter as can be, so
>> sorry if anyone feels this is a waste of time.  Figured I might as
>> well though.
>> > Thanks!
>> >
>> >
>> >
>> >
>> >
>> 

Re: [Kicad-developers] [PATCH] Patch consistency & OS X documentation error

[Wayne Stambaugh]

If no one else objects, I'll commit the patch.

On 9/16/2016 11:14 AM, Adam Wolf wrote:
> Sorry, I used the wrong email address before and my email didn't go through.
> 
> I think this is correct, and I would like all the patches to be in the
> same format.  Nick and Simon and I are working on revamping the OS X
> packaging scripts so that we get signing and a bunch of improvements
> from the last year, and we can handle any changes made here, during this
> revamp, so there's no extra burden on the packaging side for this.
> 
> Please note we have moved to 10.9 as a min OS X version, so anything
> only needed for 10.7 and 10.8 should be removed.
> 
> Adam Wolf
> 
> 
> On Fri, Sep 16, 2016 at 10:01 AM, Wayne Stambaugh  > wrote:
> 
> Would one of our osx devs please comment on this?  I don't know if this
> patch makes sense.  I'll fix the path issue in compiling.md
> .
> 
> @Collin, please format your patches using git format-patch.  It makes
> life easier for devs to commit your patches.
> 
> On 9/15/2016 6:21 AM, Collin Anderson wrote:
> > Hi, this is more of a tiny proposal in patch form, and a trivial
> one so if there is reason to reject it that I haven't thought of (or
> its just not wanted) please do so!
> >
> >
> > The current wxwidgets patches in the /patches
> directory use inconsistent formatting.  The majority use "===
> modified fie '...' " headers for each file, but some of the more
> recent ones use the command run as the header, but this causes
> problems if you try to combine the patches.  Anyone making build
> scripts or just wants to save time by using cat to merge the patches
> into one file, or simply pipe the output directly to patch will be
> unable to do so, and they'll have to manually run patch for each
> patchfile with the 'diff' headers.  It just seems needlessly
> inconsistent.  Altering the headers to all use "=== modified file"
> headers will not break anyone's scripts etc., as far as I know.
> >
> > Also, one of the patches,
> wxwidgets-3.0.2_macosx_data_view_ctrl.patch, won't even patch
> correctly using -p0, it is set up so it requires -p1.
> >
> > All this patch does is make the patch headers consistent and patch
> paths all have consistent --strip (-p) levels, that of 0.
> >
> > That is all included in patch_patch.patch
> >
> > Oh, and on a related note, I noticed the path has gotten mangled
> in the compling.md  documentation:
> >
> >> Download the wxPython source and build using the following commands:
> >>
> >> cd path-to-wxwidgets-src
> >> patch -p0 <
> path-to-kicad-src/patches/wxwidgets-3.0.0_macosx.patch
> >> patch -p0 <
> path-to-kicad-src/wxwidgets-3.0.0_macosx_bug_15908.patch 
>  <--- /path/ missing from path here
> >> patch -p0 <
> path-to-kicad-src/patches/wxwidgets-3.0.0_macosx_soname.patch
> >> patch -p0 <
> path-to-kicad-src/patches/wxwidgets-3.0.2_macosx_yosemite.patch
> >> patch -p0 <
> path-to-kicad-src/patches/wxwidgets-3.0.0_macosx_scrolledwindow.patch
> >> mkdir build
> >>
> >
> >
> > Also, I wanted to confirm, are these the only patches that should
> be applied? For 10.7, I think it is correct.
> >
> > Maybe we could add something explicitly saying what the other
> wxwidgets patches are for (or rather, when they are to be used). 
> The yosemite one is obvious, magnify event is for El Capitan, not
> sure about the retina patch or dataview patch.  I think we should
> mention them in the documentation though, rather than expecting
> someone trying to build kicad to discover them on their own.
> >
> > Anyway, I know this is about as trivial a matter as can be, so
> sorry if anyone feels this is a waste of time.  Figured I might as
> well though.
> > Thanks!
> >
> >
> >
> >
> >
> >
> > ___
> > Mailing list: https://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
> 

[Kicad-developers] [PATCH] [BUILD] Remove unused stanalone build in bitmaps_png

[Niki Guldbrand]

* Remove support for building the Bitmap lib standalone,
  which has been broken since the switch from svn.

Signed-off-by: Niki Guldbrand 
---
 bitmaps_png/CMakeLists.txt | 17 -
 1 file changed, 17 deletions(-)

diff --git a/bitmaps_png/CMakeLists.txt b/bitmaps_png/CMakeLists.txt
index 3e699e4..8d3ae82 100644
--- a/bitmaps_png/CMakeLists.txt
+++ b/bitmaps_png/CMakeLists.txt
@@ -47,23 +47,6 @@
 
 # lower case is used for local variables, uppercase for global variables
 
-
-# If this file is used as part of the Kicad build, disable the stand alone build mode.
-if( NOT DEFINED CMAKE_PROJECT_NAME )
-
-# stand alone debugging
-project( kicad_for_bitmaps )
-
-cmake_minimum_required( VERSION 2.8.0 FATAL_ERROR )
-
-include_directories( /svn/kicad/work/include )
-
-set( CMAKE_MODULE_PATH /svn/kicad/work/CMakeModules )
-
-add_definitions( -I/usr/lib/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread )
-
-endif( NOT DEFINED CMAKE_PROJECT_NAME )
-
 option( MAINTAIN_PNGS
 "Set to true if you are a PNG maintainer and have the required tools given in the bitmaps_png/CMakeLists.txt file (default OFF)."
 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

Re: [Kicad-developers] Updating the README

[Nick Østergaard]

2016-09-15 20:33 GMT+02:00 Wayne Stambaugh :
> On 9/15/2016 1:39 PM, Nick Østergaard wrote:
>> Hi
>>
>> I was going to submit a patch to update the short description for the
>> various folders in the the root of the kicad source repo, but I am a
>> bit confused to what to write for the "new" folder.
>>
>> My best suggestion for it was something like "Old crap (not built)" or
>> Draft for undocumented SWEET concept. Those descriptions are not
>> really helpfull at all.
>
> Sweet is the eeschema analog to pcbnew's pretty.  It's just the name
> given to the new component library file format.  Once sweet is
> implemented KiCad will be pretty sweet.  Yes, it's silly.  But what's
> life without a little whimsy.
>

I see. Attached is my proposal for a more up to date overview.

Please note the TODO.txt description. Maybe it should just be removed,
and possibly be moved to the doxygen devdocs if it is supposed to
exist.

Also, it seems that the helpers and tools dir have sort of similar purpose.

>>
>> What is the use of this folder? As far as I can see nothing in there
>> is built. it seems to be a stashing place for something called SWEET.
>>
>> Is this a eeschema pendant to pcbnew's pretties?
>> Is the new folder to be deleted or kept for future reference?
>> Is this related to Wayne's eeschema refactoring?
>
> Possibly, that's why it's been kept around.  Once the new schematic and
> file formats are completed, I will remove the new/ folder.
>

Ok.

>>
>> Nick
>>
>> ___
>> Mailing list: https://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 d2f2a9ae8a7290573fd5c08d17c0f250ca7cba80 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Nick=20=C3=98stergaard?= 
Date: Sat, 3 Sep 2016 14:19:50 +0200
Subject: [PATCH] Update the REAMDE.txt to reflect the current structure

The old changelog was archived together with the others in
Documentation/changelogs.
---
 .../changelogs/CHANGELOG-2012.txt  |  0
 README.txt | 70 --
 2 files changed, 38 insertions(+), 32 deletions(-)
 rename CHANGELOG.txt => Documentation/changelogs/CHANGELOG-2012.txt (100%)

diff --git a/CHANGELOG.txt b/Documentation/changelogs/CHANGELOG-2012.txt
similarity index 100%
rename from CHANGELOG.txt
rename to Documentation/changelogs/CHANGELOG-2012.txt
diff --git a/README.txt b/README.txt
index ab05f75..f88872e 100644
--- a/README.txt
+++ b/README.txt
@@ -1,41 +1,47 @@
 KiCad README
 
-For specific documentation like Compiling, GUI translation, Old changelogs see the
-Documentation subfolder.
+For specific documentation like Compiling, GUI translation, old
+changelogs see the Documentation subfolder.
 
 Files
 -
-AUTHORS.txt - The authors, contributors, document writers and translators list
-CHANGELOG.txt   - This years changelog (see for previous years Documentation/changelogs)
-CMakeList.txt   - CMAKE build tool script
-COPYRIGHT.txt   - A copy of the GNU General Public License Version 2
-CTestConfig.cmake   - Support for CTest and CDash testing tools
-Doxyfile- Doxygen config file for Kicad
-INSTALL.txt - The release (binary) installation instructions
-TODO.txt- Todo list
-uncrustify.cfg  - Uncrustify config file for uncrustify sources formatting tool
+AUTHORS.txt   - The authors, contributors, document writers and translators list
+CMakeList.txt - Main CMAKE build tool script
+COPYRIGHT.txt - A copy of the GNU General Public License Version 2
+CTestConfig.cmake - Support for CTest and CDash testing tools
+Doxyfile  - Doxygen config file for KiCad
+INSTALL.txt   - The release (binary) installation instructions
+TODO.txt  - Todo list (looks outdated)
+uncrustify.cfg- Uncrustify config file for uncrustify sources formatting tool
 
 Subdirectories
 --
-3d-viewer  - Sourcecode of 3D viewer
-bitmaps- Menu and program icons
-bitmap2component - Sourcecode of a small application to create a footprint or a component from a B bitmap
-this component or footprint has just graphic items that show the bitmap
-CMakeModules   - Modules for the CMAKE build tool
-common - Sourcecode of the common library (common functions shared across whole suite)
-cvpcb  - Sourcecode of CvPCB, tool to link components with footprints sourcecode
-demos  - Some demo examples
-Documentation  - Compiling documentation. Translating the GUI, old 

Re: [Kicad-developers] SWIG binding

[Wayne Stambaugh]

On 9/16/2016 2:13 PM, Michael Steinberg wrote:
> Hello Wayne,
> 
>> Yet.  I'm sure they are going to have to implement it at some point.
>> You can always write your own swig wrapper something like this:
>> http://stackoverflow.com/questions/27693812/how-to-handle-unique-ptrs-with-swig
>>
> They had 5+ years to add support, they didn't. So I wouldn't count on it.
>> As some of you may or may not know, the new wxpython project phoenix is
>> using sip instead of swig so that in and of itself may put us in a
>> position where we have to change to sip.  I would rather wait and see
>> what shakes out with the new wxpython implementation rather than head
>> down a path that only has to be changed yet again.
> And another break, will we support SWIG, SIP and an interop layer?
>>> With this message I want to ask what is the common view whether it is
>>> okay to have SWIG thumbscrew the project's source code, considering
>>> there are alternative generators, and generatorless libraries like
>>> pybind11. Of those alternatives I would *personally* prefer the latter,
>>> as it is no black box and the binding generation is part of the normal
>>> c++ source code.
>> Honestly, changing scripting language generators does not thrill me at
>> this point in the project.  It would most likely break all of the python
>> scripting work done thus far which would create a lot backlash.
> It will only get worse as time is passing by building upon the current
> state.
> 
> I think we need
> 1) a specified python API
> 2) adapters that match the specified API to the source code
> 3) Helpers to generate the necessary binding from the API adapters. This
> can be done with the aid of libraries or manually.
> 
> It seems none of that is currently available, the current unspecified
> API holds the source code tight, with a generator that hinders
> refactoring to modern c++ style. So we only lose on both sides.
> 
> Michael
> 

The only way I could get behind this if it's implemented separately from
and in addition to the current swig wrappers.  This would preserve the
investment folks have in their existing python scripts and they could
decide which bindings they prefer.  Forcing this kind of change on users
generally doesn't end well.

___
Mailing list: https://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] SWIG binding

[Chris Pavlina]

On Fri, Sep 16, 2016 at 08:13:13PM +0200, Michael Steinberg wrote:
> Hello Wayne,
> 
> >Yet.  I'm sure they are going to have to implement it at some point.
> >You can always write your own swig wrapper something like this:
> >http://stackoverflow.com/questions/27693812/how-to-handle-unique-ptrs-with-swig
> They had 5+ years to add support, they didn't. So I wouldn't count on it.
> >As some of you may or may not know, the new wxpython project phoenix is
> >using sip instead of swig so that in and of itself may put us in a
> >position where we have to change to sip.  I would rather wait and see
> >what shakes out with the new wxpython implementation rather than head
> >down a path that only has to be changed yet again.
> And another break, will we support SWIG, SIP and an interop layer?
> >>With this message I want to ask what is the common view whether it is
> >>okay to have SWIG thumbscrew the project's source code, considering
> >>there are alternative generators, and generatorless libraries like
> >>pybind11. Of those alternatives I would *personally* prefer the latter,
> >>as it is no black box and the binding generation is part of the normal
> >>c++ source code.
> >Honestly, changing scripting language generators does not thrill me at
> >this point in the project.  It would most likely break all of the python
> >scripting work done thus far which would create a lot backlash.
> It will only get worse as time is passing by building upon the current
> state.
> 
> I think we need
> 1) a specified python API
> 2) adapters that match the specified API to the source code
> 3) Helpers to generate the necessary binding from the API adapters. This can
> be done with the aid of libraries or manually.
> 
> It seems none of that is currently available, the current unspecified API
> holds the source code tight, with a generator that hinders refactoring to
> modern c++ style. So we only lose on both sides.

Agreed. We _already_ risk breaking a lot of scripts and generating
backlash any time we change something, because our script "API" is just
bindings on the internals.

Bear in mind, if we replace it with something else, we can add the new
API without removing the old one immediately, and migrate gradually.

> 
> Michael
> 
> 
> 
> ___
> Mailing list: https://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] SWIG binding

[Michael Steinberg]

Hello Wayne,


Yet.  I'm sure they are going to have to implement it at some point.
You can always write your own swig wrapper something like this:
http://stackoverflow.com/questions/27693812/how-to-handle-unique-ptrs-with-swig

They had 5+ years to add support, they didn't. So I wouldn't count on it.

As some of you may or may not know, the new wxpython project phoenix is
using sip instead of swig so that in and of itself may put us in a
position where we have to change to sip.  I would rather wait and see
what shakes out with the new wxpython implementation rather than head
down a path that only has to be changed yet again.

And another break, will we support SWIG, SIP and an interop layer?

With this message I want to ask what is the common view whether it is
okay to have SWIG thumbscrew the project's source code, considering
there are alternative generators, and generatorless libraries like
pybind11. Of those alternatives I would *personally* prefer the latter,
as it is no black box and the binding generation is part of the normal
c++ source code.

Honestly, changing scripting language generators does not thrill me at
this point in the project.  It would most likely break all of the python
scripting work done thus far which would create a lot backlash.
It will only get worse as time is passing by building upon the current 
state.


I think we need
1) a specified python API
2) adapters that match the specified API to the source code
3) Helpers to generate the necessary binding from the API adapters. This 
can be done with the aid of libraries or manually.


It seems none of that is currently available, the current unspecified 
API holds the source code tight, with a generator that hinders 
refactoring to modern c++ style. So we only lose on both sides.


Michael



___
Mailing list: https://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] SWIG binding

[Wayne Stambaugh]

On 9/16/2016 12:01 PM, Michael Steinberg wrote:
> Hello all,
> 
> when activating python bindings on my msvc build with a few refactor
> commits applied, it came to my attention that SWIG simply does not
> support std::unique_ptr.

Yet.  I'm sure they are going to have to implement it at some point.
You can always write your own swig wrapper something like this:
http://stackoverflow.com/questions/27693812/how-to-handle-unique-ptrs-with-swig

As some of you may or may not know, the new wxpython project phoenix is
using sip instead of swig so that in and of itself may put us in a
position where we have to change to sip.  I would rather wait and see
what shakes out with the new wxpython implementation rather than head
down a path that only has to be changed yet again.

> 
> With this message I want to ask what is the common view whether it is
> okay to have SWIG thumbscrew the project's source code, considering
> there are alternative generators, and generatorless libraries like
> pybind11. Of those alternatives I would *personally* prefer the latter,
> as it is no black box and the binding generation is part of the normal
> c++ source code.

Honestly, changing scripting language generators does not thrill me at
this point in the project.  It would most likely break all of the python
scripting work done thus far which would create a lot backlash.

> There's been a discussion on the irc channel regardings this and also
> the dependency on having wx exported as well. So I thought the logical
> consequence would be to broaden the audience and move the discussion here.
> 
> Cheers!
> Michael
> 
> 
> ___
> Mailing list: https://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] SWIG binding

[Nick Østergaard]

2016-09-16 18:08 GMT+02:00 Tomasz Wlostowski :
> On 16.09.2016 18:01, Michael Steinberg wrote:
>> Hello all,
>>
>> when activating python bindings on my msvc build with a few refactor
>> commits applied, it came to my attention that SWIG simply does not
>> support std::unique_ptr.
>>
>> With this message I want to ask what is the common view whether it is
>> okay to have SWIG thumbscrew the project's source code, considering
>> there are alternative generators, and generatorless libraries like
>> pybind11. Of those alternatives I would *personally* prefer the latter,
>> as it is no black box and the binding generation is part of the normal
>> c++ source code.
>> There's been a discussion on the irc channel regardings this and also
>> the dependency on having wx exported as well. So I thought the logical
>> consequence would be to broaden the audience and move the discussion here.
>
> Hi Michael,
>
> It may sound controversial, but I'd say using SWIG is a bad idea: we
> expose for the people the internal APIs of pcbnew that we intend to
> refactor in the near future. Any change to the BOARD storage model means
> a change to the scripting API. IMHO we should have a more pythonish API
> that hides all C++ stuff from the python side completely and is
> independent from the changes in pcbnew's core.
>

There have been some work towards an other API like,
https://github.com/KiCad/kicad-python

But it seems that it needs participants to define the API. Above seems
to be a wrapper on the kicad API to write python scripts against. The
idea seems that it should be easier to update the wrapper to match
kicad, rather than rewriting every script that depends on kicad.

I don't say that either tool is the correct solution or not, I just
suggest that someone is needed to actually define the API also.

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

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

[Kicad-developers] SWIG binding

[Michael Steinberg]

Hello all,

when activating python bindings on my msvc build with a few refactor 
commits applied, it came to my attention that SWIG simply does not 
support std::unique_ptr.


With this message I want to ask what is the common view whether it is 
okay to have SWIG thumbscrew the project's source code, considering 
there are alternative generators, and generatorless libraries like 
pybind11. Of those alternatives I would *personally* prefer the latter, 
as it is no black box and the binding generation is part of the normal 
c++ source code.
There's been a discussion on the irc channel regardings this and also 
the dependency on having wx exported as well. So I thought the logical 
consequence would be to broaden the audience and move the discussion here.


Cheers!
Michael


___
Mailing list: https://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] Patch consistency & OS X documentation error

[Adam Wolf]

Sorry, I used the wrong email address before and my email didn't go through.

I think this is correct, and I would like all the patches to be in the same
format.  Nick and Simon and I are working on revamping the OS X packaging
scripts so that we get signing and a bunch of improvements from the last
year, and we can handle any changes made here, during this revamp, so
there's no extra burden on the packaging side for this.

Please note we have moved to 10.9 as a min OS X version, so anything only
needed for 10.7 and 10.8 should be removed.

Adam Wolf

On Fri, Sep 16, 2016 at 10:01 AM, Wayne Stambaugh 
wrote:

> Would one of our osx devs please comment on this?  I don't know if this
> patch makes sense.  I'll fix the path issue in compiling.md.
>
> @Collin, please format your patches using git format-patch.  It makes
> life easier for devs to commit your patches.
>
> On 9/15/2016 6:21 AM, Collin Anderson wrote:
> > Hi, this is more of a tiny proposal in patch form, and a trivial one so
> if there is reason to reject it that I haven't thought of (or its just not
> wanted) please do so!
> >
> >
> > The current wxwidgets patches in the /patches
> directory use inconsistent formatting.  The majority use "=== modified fie
> '...' " headers for each file, but some of the more recent ones use the
> command run as the header, but this causes problems if you try to combine
> the patches.  Anyone making build scripts or just wants to save time by
> using cat to merge the patches into one file, or simply pipe the output
> directly to patch will be unable to do so, and they'll have to manually run
> patch for each patchfile with the 'diff' headers.  It just seems needlessly
> inconsistent.  Altering the headers to all use "=== modified file" headers
> will not break anyone's scripts etc., as far as I know.
> >
> > Also, one of the patches, wxwidgets-3.0.2_macosx_data_view_ctrl.patch,
> won't even patch correctly using -p0, it is set up so it requires -p1.
> >
> > All this patch does is make the patch headers consistent and patch paths
> all have consistent --strip (-p) levels, that of 0.
> >
> > That is all included in patch_patch.patch
> >
> > Oh, and on a related note, I noticed the path has gotten mangled in the
> compling.md documentation:
> >
> >> Download the wxPython source and build using the following commands:
> >>
> >> cd path-to-wxwidgets-src
> >> patch -p0 < path-to-kicad-src/patches/wxwidgets-3.0.0_macosx.patch
> >> patch -p0 < path-to-kicad-src/wxwidgets-3.0.0_macosx_bug_15908.patch
>  <--- /path/ missing from path here
> >> patch -p0 < path-to-kicad-src/patches/
> wxwidgets-3.0.0_macosx_soname.patch
> >> patch -p0 < path-to-kicad-src/patches/wxwidgets-3.0.2_macosx_
> yosemite.patch
> >> patch -p0 < path-to-kicad-src/patches/wxwidgets-3.0.0_macosx_
> scrolledwindow.patch
> >> mkdir build
> >>
> >
> >
> > Also, I wanted to confirm, are these the only patches that should be
> applied? For 10.7, I think it is correct.
> >
> > Maybe we could add something explicitly saying what the other wxwidgets
> patches are for (or rather, when they are to be used).  The yosemite one is
> obvious, magnify event is for El Capitan, not sure about the retina patch
> or dataview patch.  I think we should mention them in the documentation
> though, rather than expecting someone trying to build kicad to discover
> them on their own.
> >
> > Anyway, I know this is about as trivial a matter as can be, so sorry if
> anyone feels this is a waste of time.  Figured I might as well though.
> > Thanks!
> >
> >
> >
> >
> >
> >
> > ___
> > Mailing list: https://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] Patch consistency & OS X documentation error

[Wayne Stambaugh]

Would one of our osx devs please comment on this?  I don't know if this
patch makes sense.  I'll fix the path issue in compiling.md.

@Collin, please format your patches using git format-patch.  It makes
life easier for devs to commit your patches.

On 9/15/2016 6:21 AM, Collin Anderson wrote:
> Hi, this is more of a tiny proposal in patch form, and a trivial one so if 
> there is reason to reject it that I haven't thought of (or its just not 
> wanted) please do so! 
> 
> 
> The current wxwidgets patches in the /patches directory 
> use inconsistent formatting.  The majority use "=== modified fie '...' " 
> headers for each file, but some of the more recent ones use the command run 
> as the header, but this causes problems if you try to combine the patches.  
> Anyone making build scripts or just wants to save time by using cat to merge 
> the patches into one file, or simply pipe the output directly to patch will 
> be unable to do so, and they'll have to manually run patch for each patchfile 
> with the 'diff' headers.  It just seems needlessly inconsistent.  Altering 
> the headers to all use "=== modified file" headers will not break anyone's 
> scripts etc., as far as I know. 
> 
> Also, one of the patches, wxwidgets-3.0.2_macosx_data_view_ctrl.patch, won't 
> even patch correctly using -p0, it is set up so it requires -p1. 
> 
> All this patch does is make the patch headers consistent and patch paths all 
> have consistent --strip (-p) levels, that of 0.  
> 
> That is all included in patch_patch.patch 
> 
> Oh, and on a related note, I noticed the path has gotten mangled in the 
> compling.md documentation:
> 
>> Download the wxPython source and build using the following commands:
>>
>> cd path-to-wxwidgets-src
>> patch -p0 < path-to-kicad-src/patches/wxwidgets-3.0.0_macosx.patch
>> patch -p0 < path-to-kicad-src/wxwidgets-3.0.0_macosx_bug_15908.patch   
>> <--- /path/ missing from path here
>> patch -p0 < path-to-kicad-src/patches/wxwidgets-3.0.0_macosx_soname.patch
>> patch -p0 < 
>> path-to-kicad-src/patches/wxwidgets-3.0.2_macosx_yosemite.patch
>> patch -p0 < 
>> path-to-kicad-src/patches/wxwidgets-3.0.0_macosx_scrolledwindow.patch
>> mkdir build
>>
> 
> 
> Also, I wanted to confirm, are these the only patches that should be applied? 
> For 10.7, I think it is correct.
> 
> Maybe we could add something explicitly saying what the other wxwidgets 
> patches are for (or rather, when they are to be used).  The yosemite one is 
> obvious, magnify event is for El Capitan, not sure about the retina patch or 
> dataview patch.  I think we should mention them in the documentation though, 
> rather than expecting someone trying to build kicad to discover them on their 
> own. 
> 
> Anyway, I know this is about as trivial a matter as can be, so sorry if 
> anyone feels this is a waste of time.  Figured I might as well though.  
> Thanks!
> 
> 
> 
> 
> 
> 
> ___
> Mailing list: https://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]

What was mentiomed was to approximate for example beziers with arcs. That
would still be accurate when exported to gerbers, because one could use
arcs which are supported in gerbers IIRC.

Den 16/09/2016 15.34 skrev "Wayne Stambaugh" :

> I would like to see arc support in copper layers as well but we need to
> approach this carefully.  One thing KiCad has been pretty good at is not
> producing broken gerber files.  A lot of code would have to be written
> to support this fully.  When I here words like "approximate", it makes
> me nervous.  Gerber output, particularly copper layers should not be
> approximations, they need to be accurate down the accuracy of the gerber
> plot formatting.
>
> On 9/14/2016 8: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
>
___
Mailing list: https://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

[Wayne Stambaugh]

I would like to see arc support in copper layers as well but we need to
approach this carefully.  One thing KiCad has been pretty good at is not
producing broken gerber files.  A lot of code would have to be written
to support this fully.  When I here words like "approximate", it makes
me nervous.  Gerber output, particularly copper layers should not be
approximations, they need to be accurate down the accuracy of the gerber
plot formatting.

On 9/14/2016 8: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] [Build] Remove redundant data in defines.

[Wayne Stambaugh]

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

Cheers,

Wayne

On 9/13/2016 4:29 PM, Niki Guldbrand wrote:
> 
> * Using CMAKE_INSTALL_PREFIX in KICAD_* install paths is redundant,
>   because they are allready relative to CMAKE_INSTALL_PREFIX when no
>   absolute path is given.
>   Using an absolute path makes it harder to change the install
>   path on the fly, without either rebuilding, or manually editing
>   CMakeCache.txt
> 
> Signed-off-by: Niki Guldbrand 
> ---
>  CMakeLists.txt | 6 +++---
>  1 file changed, 3 insertions(+), 3 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][RFC] Footprint wizards

[jp charras]

Le 15/09/2016 à 14:55, Oliver Walters a écrit :
> Ok, round two!
> 
> 1. I have fixed the issue relating to comma-separated decimals.
> 
> 2. Boolean values now use the wxGridCellBoolRenderer which means they always 
> display as checkboxes
> 
> Here is an example of the boolean values rendering -> 
> http://oi65.tinypic.com/24pmp9d.jpg
> 
> And an example of the multiple-choice parameter -> 
> http://oi67.tinypic.com/xkrvw5.jpg
> 
> Finally, a screenshot of available parameter types -> 
> http://oi63.tinypic.com/2lne6gh.jpg
> 
> I have attached the updated patch. 
> 
> LMK if there's anything else I need to do :)
> 

Works fine for me now. 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] Bezier curves in DRAWSEGMENT class

[Mário Luzeiro]

Hi all,

If ever anyone implement a new form, please have an eye on, and mind on, that 
the new form also will need a 3DViewer implementation.
It may be just a need to convert it with segm approximation (if its not already 
come as segments from pcbnew board).

Cheers,
Mario Luzeiro


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

Re: [Kicad-developers] VRML Export

[Mário Luzeiro]

Hi Cirilo,

IMO the b) is most important for the users that want to use the features 
without having knowledge of how the things really work and want something that 
"it just works". (special good for sharing without copy many files)
but as Maurice point, the a) inline feature is a more wised way of using VRML, 
good for advance users.

Mario

From: Kicad-developers 
[kicad-developers-bounces+mrluzeiro=ua...@lists.launchpad.net] on behalf of 
easyw [ea...@katamail.com]
Sent: 16 September 2016 00:20
To: Cirilo Bernardo; KiCad Developers
Subject: Re: [Kicad-developers] VRML Export

Hi Cirilo,
I found inline{} VRML export option very useful and powerful...

it allows an easy post elaboration to i.e. change color to pcb board,
traces and solder mask with some macro or tweak the VRML models to add
texture to the VRML result for an improved visualization or even add a
vrml model inline{} to a 3D part to include some external extra objects
not present in the pcbnew...

I use Blender to import kicad VRML exported boards and I use also
material properties without any issues with the actual develop build
branch...

So in case of a rewriting of the VRML exporter, I would consider very
useful to leave at least an option to conserve the actual inline{}
structure.

Thank you
Maurice

On 16/09/2016 00:25, Cirilo Bernardo wrote:
> Hi folks,
>
>  Since the merge of the new 3DViewer the VRML Export routine has not
> been able to include x3d data and the few x3d users out there have not
> been very happy about this. However, the scenegraph library developed
> for the 3D plugin system can easily write monolithic files which include
> visualization data for all file formats supported by plugins. This means
> that VRML Export can now be modified to either (a) continue to use
> inline{} when a file is created and when copying files the scenegraph
> library is used to write VRML model equivalents of other file formats
> (x3d, STEP, IGES, IDF) or (b) create a monolithic file with all models
> defined internally and reused wherever possible. Personally I would
> prefer (b) since that would eliminate some options in the Export routine
> such as "Copy Model Files" and would also eliminate the problem of
> inline{} compatibility with some viewers. There may be problems with
> DEF/USE within some programs like Blender but I can always add an
> option to not reuse definitions (Blender's VRML code has so many
> problems though that I doubt this would help).
>
> Any thoughts before I go ahead and rework the VRML exporter?
>
> - 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] [PATCH] Include header instead of full source

[Maciej Sumiński]

Hi Simon,

Shame on me, thank you for catching this. I have just applied your patch
to the master branch.

Regards,
Orson

On 09/16/2016 07:54 AM, Simon Richter wrote:
> ---
>  pcbnew/class_board_connected_item.cpp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> 
> 
> ___
> Mailing list: https://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