Re: [Kicad-developers] wxformbuilder version

[Chris Pavlina]

If it counts for anything, I personally would like to see this done now
on dialogs like José describes: ones where the wxfb-generated code isn't
sufficient and so they get monkeypatched in the subclass constructor.
That's really, really ugly, and I'm not sure I see much of a
disadvantage to getting rid of it now - as long as anyone doing this is
aware that their efforts might be lost or heavily modified in the
future.

On Fri, Sep 02, 2016 at 08:48:33PM -0500, José Ignacio wrote:
> I'm talking about some simple particular cases where the dialogs are
> both simple (just a few boxes), and the code already muddles with it
> anyway. One such case is the pcbnew/dialog_graphic_item_properties
> which I submitted a patch for recently. When that dialog is called,
> the code changes the visibility and labels of some of the boxes
> depending on the type of graphic item that summoned the dialog. In
> that case a GUI-only change in wxFB could potentially break the dialog
> because the derived class touches the layout. I think in that case it
> might be best to just go all the way and make the dialog declarative.
> The impact would be minimal as the translation strings would remain
> the same, and the layout would be practically the same too, the code
> would just be cleaner in intent and easier to modify.
> 
> For more complicated dialogs I agree they should remain in wxFB for
> the time being, until someone figures out a clean way to implement
> them declaratively.
> 
> On Fri, Sep 2, 2016 at 8:22 PM, Wayne Stambaugh  wrote:
> > For 5 stable release, I would rather stick with wxFormbuilder than open
> > up a Pandora's box of other issues.  For the stable 6 release, we need
> > to have a discussion about if and how we want to implement
> > programmatically created dialogs.  I want our dialogs to be more
> > consistent in terms of spacing and layout and use the proper wxWidgets
> > method for transfer data to and from controls.  That will be an involved
> > discussion.
> >
> > On 9/2/2016 8:23 PM, José Ignacio wrote:
> >> Would patches to make some of the simpler dialogs programmatic be accepted?
> >>
> >> On Fri, Sep 2, 2016 at 7:17 PM, Wayne Stambaugh  
> >> wrote:
> >>> We've been dancing around this issue for a while without any real
> >>> resolution.  I'm fine with using Mark's version of wxFB but a lot folks
> >>> are going to want to use whatever is packaged for their distro rather
> >>> than build wxFB from source which presents a serious issue.  I'm not
> >>> sure there is a good answer for this problem.  If no one else has any
> >>> objections, I'm willing to make Mark's wxFB fork the official version
> >>> for KiCad dialog submission for the time being.  In the long run, if
> >>> wxFB is not actively being developed, I would rather come up with an
> >>> alternative.
> >>>
> >>> FWIW, I think most of you know how I feel about dialog creation tools
> >>> vs. creating them programmatically.  Kicad's dialogs used to be created
> >>> this way but I got out voted at the time the decision was made to switch
> >>> to wxFB.  I'm feeling better about my choice all the time. ;)
> >>>
> >>> On 9/2/2016 7:11 PM, Chris Pavlina wrote:
>  I would vote in favor of using Mark's fork officially for everyone, if
>  it builds okay on all the platforms. wxfb is kinda nasty, if we're going
>  to use it it's nice to have our own fork that solves at least a few of
>  these issues.
> 
>  On Sat, Sep 03, 2016 at 08:45:12AM +1000, Cirilo Bernardo wrote:
> > I just use MRoszko's fork; it's cleaner than the original and much
> > easier to configure and build since the bizarre wxFB build system
> > had been eradicated and replaced by CMake.
> >
> > git clone https://github.com/marekr/wxFormBuilder.git wxfb
> > cd wxfb && git checkout wxFB3.5-1
> >
> > A half year or so ago I tried the later wxFB in development but it
> > broke so many things that I just reverted the files and went back to
> > wxFB3,5-1.
> >
> > - Cirilo
> >
> >
> > On Sat, Sep 3, 2016 at 7:28 AM, Chris Pavlina 
> > wrote:
> >
> >> Along these lines: this isn't the first time wxfb version issues have
> >> come up. Perhaps we should pick an "official" wxfb version for the
> >> project to use, and then actually provide builds of it for developer 
> >> use
> >> (as it can be a bit annoying to track down a specific version)? Then we
> >> can upgrade together as new versions come out.
> >>
> >>
> >> On Sat, Sep 03, 2016 at 09:16:41AM +1200, Simon Wells wrote:
> >>> dialog_pad_properties_base.fbp h cpp was last modified in commit
> >>>
> >>> 63decd70e6ab1bf2fe95db3f426f6cdfc79be213
> >>> https://git.launchpad.net/kicad/commit/?id=
> >> 63decd70e6ab1bf2fe95db3f426f6cdfc79be213
> >>>
> >>> the problem is this version of wxformbuilder is newer than the one
> 

Re: [Kicad-developers] wxformbuilder version

[José Ignacio]

I'm talking about some simple particular cases where the dialogs are
both simple (just a few boxes), and the code already muddles with it
anyway. One such case is the pcbnew/dialog_graphic_item_properties
which I submitted a patch for recently. When that dialog is called,
the code changes the visibility and labels of some of the boxes
depending on the type of graphic item that summoned the dialog. In
that case a GUI-only change in wxFB could potentially break the dialog
because the derived class touches the layout. I think in that case it
might be best to just go all the way and make the dialog declarative.
The impact would be minimal as the translation strings would remain
the same, and the layout would be practically the same too, the code
would just be cleaner in intent and easier to modify.

For more complicated dialogs I agree they should remain in wxFB for
the time being, until someone figures out a clean way to implement
them declaratively.

On Fri, Sep 2, 2016 at 8:22 PM, Wayne Stambaugh  wrote:
> For 5 stable release, I would rather stick with wxFormbuilder than open
> up a Pandora's box of other issues.  For the stable 6 release, we need
> to have a discussion about if and how we want to implement
> programmatically created dialogs.  I want our dialogs to be more
> consistent in terms of spacing and layout and use the proper wxWidgets
> method for transfer data to and from controls.  That will be an involved
> discussion.
>
> On 9/2/2016 8:23 PM, José Ignacio wrote:
>> Would patches to make some of the simpler dialogs programmatic be accepted?
>>
>> On Fri, Sep 2, 2016 at 7:17 PM, Wayne Stambaugh  wrote:
>>> We've been dancing around this issue for a while without any real
>>> resolution.  I'm fine with using Mark's version of wxFB but a lot folks
>>> are going to want to use whatever is packaged for their distro rather
>>> than build wxFB from source which presents a serious issue.  I'm not
>>> sure there is a good answer for this problem.  If no one else has any
>>> objections, I'm willing to make Mark's wxFB fork the official version
>>> for KiCad dialog submission for the time being.  In the long run, if
>>> wxFB is not actively being developed, I would rather come up with an
>>> alternative.
>>>
>>> FWIW, I think most of you know how I feel about dialog creation tools
>>> vs. creating them programmatically.  Kicad's dialogs used to be created
>>> this way but I got out voted at the time the decision was made to switch
>>> to wxFB.  I'm feeling better about my choice all the time. ;)
>>>
>>> On 9/2/2016 7:11 PM, Chris Pavlina wrote:
 I would vote in favor of using Mark's fork officially for everyone, if
 it builds okay on all the platforms. wxfb is kinda nasty, if we're going
 to use it it's nice to have our own fork that solves at least a few of
 these issues.

 On Sat, Sep 03, 2016 at 08:45:12AM +1000, Cirilo Bernardo wrote:
> I just use MRoszko's fork; it's cleaner than the original and much
> easier to configure and build since the bizarre wxFB build system
> had been eradicated and replaced by CMake.
>
> git clone https://github.com/marekr/wxFormBuilder.git wxfb
> cd wxfb && git checkout wxFB3.5-1
>
> A half year or so ago I tried the later wxFB in development but it
> broke so many things that I just reverted the files and went back to
> wxFB3,5-1.
>
> - Cirilo
>
>
> On Sat, Sep 3, 2016 at 7:28 AM, Chris Pavlina 
> wrote:
>
>> Along these lines: this isn't the first time wxfb version issues have
>> come up. Perhaps we should pick an "official" wxfb version for the
>> project to use, and then actually provide builds of it for developer use
>> (as it can be a bit annoying to track down a specific version)? Then we
>> can upgrade together as new versions come out.
>>
>>
>> On Sat, Sep 03, 2016 at 09:16:41AM +1200, Simon Wells wrote:
>>> dialog_pad_properties_base.fbp h cpp was last modified in commit
>>>
>>> 63decd70e6ab1bf2fe95db3f426f6cdfc79be213
>>> https://git.launchpad.net/kicad/commit/?id=
>> 63decd70e6ab1bf2fe95db3f426f6cdfc79be213
>>>
>>> the problem is this version of wxformbuilder is newer than the one
>>> available on sourceforge and it is very difficult to build on other
>>> platforms ( i tried a while ago and gave up as it had issues)
>>>
>>> the version that was used to save these files has broken it on older
>>> versions of wxformbuilder
>>>
>>> Is there a version of wxformbuilder that we should be using to avoid
>>> it breaking on other versions?
>>>
>>> the last available from sf.net is 3.5rc1 iirc
>>>
>>> thanks
>>>
>>> Simon
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : 

Re: [Kicad-developers] wxformbuilder version

[Wayne Stambaugh]

For 5 stable release, I would rather stick with wxFormbuilder than open
up a Pandora's box of other issues.  For the stable 6 release, we need
to have a discussion about if and how we want to implement
programmatically created dialogs.  I want our dialogs to be more
consistent in terms of spacing and layout and use the proper wxWidgets
method for transfer data to and from controls.  That will be an involved
discussion.

On 9/2/2016 8:23 PM, José Ignacio wrote:
> Would patches to make some of the simpler dialogs programmatic be accepted?
> 
> On Fri, Sep 2, 2016 at 7:17 PM, Wayne Stambaugh  wrote:
>> We've been dancing around this issue for a while without any real
>> resolution.  I'm fine with using Mark's version of wxFB but a lot folks
>> are going to want to use whatever is packaged for their distro rather
>> than build wxFB from source which presents a serious issue.  I'm not
>> sure there is a good answer for this problem.  If no one else has any
>> objections, I'm willing to make Mark's wxFB fork the official version
>> for KiCad dialog submission for the time being.  In the long run, if
>> wxFB is not actively being developed, I would rather come up with an
>> alternative.
>>
>> FWIW, I think most of you know how I feel about dialog creation tools
>> vs. creating them programmatically.  Kicad's dialogs used to be created
>> this way but I got out voted at the time the decision was made to switch
>> to wxFB.  I'm feeling better about my choice all the time. ;)
>>
>> On 9/2/2016 7:11 PM, Chris Pavlina wrote:
>>> I would vote in favor of using Mark's fork officially for everyone, if
>>> it builds okay on all the platforms. wxfb is kinda nasty, if we're going
>>> to use it it's nice to have our own fork that solves at least a few of
>>> these issues.
>>>
>>> On Sat, Sep 03, 2016 at 08:45:12AM +1000, Cirilo Bernardo wrote:
 I just use MRoszko's fork; it's cleaner than the original and much
 easier to configure and build since the bizarre wxFB build system
 had been eradicated and replaced by CMake.

 git clone https://github.com/marekr/wxFormBuilder.git wxfb
 cd wxfb && git checkout wxFB3.5-1

 A half year or so ago I tried the later wxFB in development but it
 broke so many things that I just reverted the files and went back to
 wxFB3,5-1.

 - Cirilo


 On Sat, Sep 3, 2016 at 7:28 AM, Chris Pavlina 
 wrote:

> Along these lines: this isn't the first time wxfb version issues have
> come up. Perhaps we should pick an "official" wxfb version for the
> project to use, and then actually provide builds of it for developer use
> (as it can be a bit annoying to track down a specific version)? Then we
> can upgrade together as new versions come out.
>
>
> On Sat, Sep 03, 2016 at 09:16:41AM +1200, Simon Wells wrote:
>> dialog_pad_properties_base.fbp h cpp was last modified in commit
>>
>> 63decd70e6ab1bf2fe95db3f426f6cdfc79be213
>> https://git.launchpad.net/kicad/commit/?id=
> 63decd70e6ab1bf2fe95db3f426f6cdfc79be213
>>
>> the problem is this version of wxformbuilder is newer than the one
>> available on sourceforge and it is very difficult to build on other
>> platforms ( i tried a while ago and gave up as it had issues)
>>
>> the version that was used to save these files has broken it on older
>> versions of wxformbuilder
>>
>> Is there a version of wxformbuilder that we should be using to avoid
>> it breaking on other versions?
>>
>> the last available from sf.net is 3.5rc1 iirc
>>
>> thanks
>>
>> Simon
>>
>> ___
>> Mailing list: https://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 : 

Re: [Kicad-developers] wxformbuilder version

[Blair Bonnett]

There's been some activity on the wxFB mailing list over the last couple of
days; somebody proposed switching to GitHub and integrating the CMake
patches that originated here. One of the developers responded and it looks
like they're interested in going in that direction. The SourceForge mailing
list interface is a bit of a pain to navigate but see [1] for the
developers response. The GitHub repository is at [2]; I'm not sure how
'official' this is yet but I dare say we'll find out shortly.

[1]: https://sourceforge.net/p/wxformbuilder/mailman/message/35326676/
[2]: https://github.com/wxFormBuilder/wxFormBuilder
___
Mailing list: https://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] wxformbuilder version

[Cirilo Bernardo]

On Sat, Sep 3, 2016 at 10:17 AM, Wayne Stambaugh 
wrote:

> We've been dancing around this issue for a while without any real
> resolution.  I'm fine with using Mark's version of wxFB but a lot folks
> are going to want to use whatever is packaged for their distro rather
> than build wxFB from source which presents a serious issue.  I'm not
> sure there is a good answer for this problem.  If no one else has any
> objections, I'm willing to make Mark's wxFB fork the official version
> for KiCad dialog submission for the time being.  In the long run, if
> wxFB is not actively being developed, I would rather come up with an
> alternative.
>
>
Normally I'd go along with the "users can use whatever version of X is
in their distribution" but wxFB is an extreme case where every stable
version pushed out breaks all previous versions, so going for what's
prepackaged for a distribution in reality will tie the rest of us to
whatever oldest version is available on a contributor's platform and this
is definitely a bad thing. At least using Mark's fork we can make sure
it all builds and runs on all supported platforms and developers will
simply have to build wxFB and maybe even live with 2 versions of wxFB
on their system if they use it for other things as well. On Debian for
example, wxFB is not packaged and building it was an extreme
nuisance until Mark cleaned up the build system and eliminated
numerous counterproductive dependencies which were peculiar to
wxFB's official build system.

- Cirilo



> FWIW, I think most of you know how I feel about dialog creation tools
> vs. creating them programmatically.  Kicad's dialogs used to be created
> this way but I got out voted at the time the decision was made to switch
> to wxFB.  I'm feeling better about my choice all the time. ;)
>
> On 9/2/2016 7:11 PM, Chris Pavlina wrote:
> > I would vote in favor of using Mark's fork officially for everyone, if
> > it builds okay on all the platforms. wxfb is kinda nasty, if we're going
> > to use it it's nice to have our own fork that solves at least a few of
> > these issues.
> >
> > On Sat, Sep 03, 2016 at 08:45:12AM +1000, Cirilo Bernardo wrote:
> >> I just use MRoszko's fork; it's cleaner than the original and much
> >> easier to configure and build since the bizarre wxFB build system
> >> had been eradicated and replaced by CMake.
> >>
> >> git clone https://github.com/marekr/wxFormBuilder.git wxfb
> >> cd wxfb && git checkout wxFB3.5-1
> >>
> >> A half year or so ago I tried the later wxFB in development but it
> >> broke so many things that I just reverted the files and went back to
> >> wxFB3,5-1.
> >>
> >> - Cirilo
> >>
> >>
> >> On Sat, Sep 3, 2016 at 7:28 AM, Chris Pavlina 
> >> wrote:
> >>
> >>> Along these lines: this isn't the first time wxfb version issues have
> >>> come up. Perhaps we should pick an "official" wxfb version for the
> >>> project to use, and then actually provide builds of it for developer
> use
> >>> (as it can be a bit annoying to track down a specific version)? Then we
> >>> can upgrade together as new versions come out.
> >>>
> >>>
> >>> On Sat, Sep 03, 2016 at 09:16:41AM +1200, Simon Wells wrote:
>  dialog_pad_properties_base.fbp h cpp was last modified in commit
> 
>  63decd70e6ab1bf2fe95db3f426f6cdfc79be213
>  https://git.launchpad.net/kicad/commit/?id=
> >>> 63decd70e6ab1bf2fe95db3f426f6cdfc79be213
> 
>  the problem is this version of wxformbuilder is newer than the one
>  available on sourceforge and it is very difficult to build on other
>  platforms ( i tried a while ago and gave up as it had issues)
> 
>  the version that was used to save these files has broken it on older
>  versions of wxformbuilder
> 
>  Is there a version of wxformbuilder that we should be using to avoid
>  it breaking on other versions?
> 
>  the last available from sf.net is 3.5rc1 iirc
> 
>  thanks
> 
>  Simon
> 
>  ___
>  Mailing list: https://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
> 

Re: [Kicad-developers] wxformbuilder version

[José Ignacio]

Would patches to make some of the simpler dialogs programmatic be accepted?

On Fri, Sep 2, 2016 at 7:17 PM, Wayne Stambaugh  wrote:
> We've been dancing around this issue for a while without any real
> resolution.  I'm fine with using Mark's version of wxFB but a lot folks
> are going to want to use whatever is packaged for their distro rather
> than build wxFB from source which presents a serious issue.  I'm not
> sure there is a good answer for this problem.  If no one else has any
> objections, I'm willing to make Mark's wxFB fork the official version
> for KiCad dialog submission for the time being.  In the long run, if
> wxFB is not actively being developed, I would rather come up with an
> alternative.
>
> FWIW, I think most of you know how I feel about dialog creation tools
> vs. creating them programmatically.  Kicad's dialogs used to be created
> this way but I got out voted at the time the decision was made to switch
> to wxFB.  I'm feeling better about my choice all the time. ;)
>
> On 9/2/2016 7:11 PM, Chris Pavlina wrote:
>> I would vote in favor of using Mark's fork officially for everyone, if
>> it builds okay on all the platforms. wxfb is kinda nasty, if we're going
>> to use it it's nice to have our own fork that solves at least a few of
>> these issues.
>>
>> On Sat, Sep 03, 2016 at 08:45:12AM +1000, Cirilo Bernardo wrote:
>>> I just use MRoszko's fork; it's cleaner than the original and much
>>> easier to configure and build since the bizarre wxFB build system
>>> had been eradicated and replaced by CMake.
>>>
>>> git clone https://github.com/marekr/wxFormBuilder.git wxfb
>>> cd wxfb && git checkout wxFB3.5-1
>>>
>>> A half year or so ago I tried the later wxFB in development but it
>>> broke so many things that I just reverted the files and went back to
>>> wxFB3,5-1.
>>>
>>> - Cirilo
>>>
>>>
>>> On Sat, Sep 3, 2016 at 7:28 AM, Chris Pavlina 
>>> wrote:
>>>
 Along these lines: this isn't the first time wxfb version issues have
 come up. Perhaps we should pick an "official" wxfb version for the
 project to use, and then actually provide builds of it for developer use
 (as it can be a bit annoying to track down a specific version)? Then we
 can upgrade together as new versions come out.


 On Sat, Sep 03, 2016 at 09:16:41AM +1200, Simon Wells wrote:
> dialog_pad_properties_base.fbp h cpp was last modified in commit
>
> 63decd70e6ab1bf2fe95db3f426f6cdfc79be213
> https://git.launchpad.net/kicad/commit/?id=
 63decd70e6ab1bf2fe95db3f426f6cdfc79be213
>
> the problem is this version of wxformbuilder is newer than the one
> available on sourceforge and it is very difficult to build on other
> platforms ( i tried a while ago and gave up as it had issues)
>
> the version that was used to save these files has broken it on older
> versions of wxformbuilder
>
> Is there a version of wxformbuilder that we should be using to avoid
> it breaking on other versions?
>
> the last available from sf.net is 3.5rc1 iirc
>
> thanks
>
> Simon
>
> ___
> Mailing list: https://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] OCE plugin for 3D viewer

[Cirilo Bernardo]

On Sat, Sep 3, 2016 at 5:25 AM, Wayne Stambaugh 
wrote:

> Cirilo,
>
> Someone still needs to address building oce on msys2.  I just spent way
> too much time building oce from source on msys2.  The oce folks decided
> to ignore CMAKE_INSTALL_PREFIX and use there own install path stuff
> which is is not compatible with the msys2 file system hierarchy.  The
> bad thing is you cannot manually copy the dlls and link stub files to
> the appropriate paths because the generated cmake oce find stuff will
> point to the incorrect paths.  To create PKGBUILD for msys2 will require
> JP's patch to fix long command lengths along with a patch to fix oce's
> install path issues.  If someone else has time to work on this please do.
>
> Thanks,
>
> Wayne
>
>
Nick's been doing all the hard work on OCE + MSYS2 issues; I'm pretty
awful at working within MSYS2 and it doesn't help that the MSYS2
ecosystem is frequently broken. I was finally able to build OCE and
the plugins on MSYS2 about a week ago only to discover catastrophic ABI
incompatibilities between wxWidgets and the newly compiled software.
I have no doubt these issues will be resolved before the next release
thank's to Nick's persistence, and I keep in touch on IRC and try to
help out however I can. Having the code in the main branch is a huge
help though; some OSX devs in particular had been cursing me due to
numerous problems with building the plugin out of the tree but building
the same code from within the kicad tree was painless.

- Cirilo


> On 9/2/2016 6:22 AM, Cirilo Bernardo wrote:
> > Thanks for the merge and to everyone who's helped out with the
> > cross-platform issues.
> > I've got a new feature branch "kicad-step" with the kicad2step
> > standalone tool if anyone
> > feels like playing with it and providing some feedback.  This is the
> > tool which I plan to
> > make available as an item in the "Export" menu to give KiCad it's own
> > built-in MCAD
> > export.
> >
> > https://code.launchpad.net/~cirilo-bernardo/kicad/+git/kicad-oce
> >
> > The long-term plan is to make this tool a genuine plugin, but the API
> > required for that
> > is turning out to be quite a big job and is currently on hold due to my
> > limited free time.
> >
> > This stand-alone tool makes use of mRoszko's SEXPR parser which is a
> > great tool
> > for making third-party tools that can read KiCad PCB files.
> >
> > - Cirilo
> >
> >
> > On Fri, Sep 2, 2016 at 4:20 PM, Simon Wells  > > wrote:
> >
> > just fyi a couple of tips on OSX
> >
> > Make sure that brew is installing oce-0.17.2 this was only commited
> to
> > brew mid august so if its only installing 0.17 (which is broke) then
> > brew update
> >
> > add
> >
> >  -DUSE_OCE=ON
> > -DOCE_DIR=/usr/local/opt/oce/OCE.framework/Versions/0.17/Resources/
> >
> > to your cmake line and it will be bundled automatically. Tested on
> rev
> > 38e7deb with no issues.
> >
> > On Fri, Sep 2, 2016 at 12:13 PM, Chris Pavlina
> > > wrote:
> > > Okay, this is friggin awesome. I can finally have models of
> > > *everything*, it's so nice! :)
> > >
> > > Sexy PCB shot: https://misc.c4757p.com/12091-motherboard.png
> > 
> > >
> > > Thanks Cirilo!
> > >
> > > On Thu, Sep 01, 2016 at 04:45:33PM -0400, Wayne Stambaugh wrote:
> > >>
> > >>
> > >> On 9/1/2016 4:18 PM, Chris Pavlina wrote:
> > >> > On Thu, Sep 01, 2016 at 04:10:13PM -0400, Wayne Stambaugh wrote:
> > >> >> On 9/1/2016 2:29 PM, José Ignacio wrote:
> > >> >>> On Thu, Sep 1, 2016 at 12:02 PM, Wayne Stambaugh
> > > wrote:
> > >>  Sorry it took so long.  I took a look at Cirilo's changes an
> > it looks
> > >>  good.  We still need a PKGBUILD file for msys2 with JPs
> > patch so we
> > >>  don't have to build oce from source.
> > >> 
> > >>  When I merge Cirilo's 3d-plugin branch and I had to create a
> > commit
> > >>  message which made me the commit author.  This seems brain
> > dead to me.
> > >>  Here is the new commit log entry:
> > >> 
> > >>  commit 12c26047bffd54ccbb88348acfe7f653556450da
> > >>  Merge: fcedef8 b656a81
> > >>  Author: Wayne Stambaugh  > >
> > >>  Date:   Thu Sep 1 11:59:44 2016 -0400
> > >> 
> > >>  Merge remote-tracking branch 'cirilo/3d-plugin'
> > >> 
> > >>  I really only want to show Cirilo's commit log entries as a
> > new commit.
> > >>  WTF! I'm liking git less every time I use it.  What do I
> > need to do to
> > >>  get the correct commit history from Cirlo's 3d-plugin branch?
> > >> 
> > >> 

Re: [Kicad-developers] wxformbuilder version

[Wayne Stambaugh]

We've been dancing around this issue for a while without any real
resolution.  I'm fine with using Mark's version of wxFB but a lot folks
are going to want to use whatever is packaged for their distro rather
than build wxFB from source which presents a serious issue.  I'm not
sure there is a good answer for this problem.  If no one else has any
objections, I'm willing to make Mark's wxFB fork the official version
for KiCad dialog submission for the time being.  In the long run, if
wxFB is not actively being developed, I would rather come up with an
alternative.

FWIW, I think most of you know how I feel about dialog creation tools
vs. creating them programmatically.  Kicad's dialogs used to be created
this way but I got out voted at the time the decision was made to switch
to wxFB.  I'm feeling better about my choice all the time. ;)

On 9/2/2016 7:11 PM, Chris Pavlina wrote:
> I would vote in favor of using Mark's fork officially for everyone, if
> it builds okay on all the platforms. wxfb is kinda nasty, if we're going
> to use it it's nice to have our own fork that solves at least a few of
> these issues.
> 
> On Sat, Sep 03, 2016 at 08:45:12AM +1000, Cirilo Bernardo wrote:
>> I just use MRoszko's fork; it's cleaner than the original and much
>> easier to configure and build since the bizarre wxFB build system
>> had been eradicated and replaced by CMake.
>>
>> git clone https://github.com/marekr/wxFormBuilder.git wxfb
>> cd wxfb && git checkout wxFB3.5-1
>>
>> A half year or so ago I tried the later wxFB in development but it
>> broke so many things that I just reverted the files and went back to
>> wxFB3,5-1.
>>
>> - Cirilo
>>
>>
>> On Sat, Sep 3, 2016 at 7:28 AM, Chris Pavlina 
>> wrote:
>>
>>> Along these lines: this isn't the first time wxfb version issues have
>>> come up. Perhaps we should pick an "official" wxfb version for the
>>> project to use, and then actually provide builds of it for developer use
>>> (as it can be a bit annoying to track down a specific version)? Then we
>>> can upgrade together as new versions come out.
>>>
>>>
>>> On Sat, Sep 03, 2016 at 09:16:41AM +1200, Simon Wells wrote:
 dialog_pad_properties_base.fbp h cpp was last modified in commit

 63decd70e6ab1bf2fe95db3f426f6cdfc79be213
 https://git.launchpad.net/kicad/commit/?id=
>>> 63decd70e6ab1bf2fe95db3f426f6cdfc79be213

 the problem is this version of wxformbuilder is newer than the one
 available on sourceforge and it is very difficult to build on other
 platforms ( i tried a while ago and gave up as it had issues)

 the version that was used to save these files has broken it on older
 versions of wxformbuilder

 Is there a version of wxformbuilder that we should be using to avoid
 it breaking on other versions?

 the last available from sf.net is 3.5rc1 iirc

 thanks

 Simon

 ___
 Mailing list: https://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] wxformbuilder version

[Chris Pavlina]

I would vote in favor of using Mark's fork officially for everyone, if
it builds okay on all the platforms. wxfb is kinda nasty, if we're going
to use it it's nice to have our own fork that solves at least a few of
these issues.

On Sat, Sep 03, 2016 at 08:45:12AM +1000, Cirilo Bernardo wrote:
> I just use MRoszko's fork; it's cleaner than the original and much
> easier to configure and build since the bizarre wxFB build system
> had been eradicated and replaced by CMake.
> 
> git clone https://github.com/marekr/wxFormBuilder.git wxfb
> cd wxfb && git checkout wxFB3.5-1
> 
> A half year or so ago I tried the later wxFB in development but it
> broke so many things that I just reverted the files and went back to
> wxFB3,5-1.
> 
> - Cirilo
> 
> 
> On Sat, Sep 3, 2016 at 7:28 AM, Chris Pavlina 
> wrote:
> 
> > Along these lines: this isn't the first time wxfb version issues have
> > come up. Perhaps we should pick an "official" wxfb version for the
> > project to use, and then actually provide builds of it for developer use
> > (as it can be a bit annoying to track down a specific version)? Then we
> > can upgrade together as new versions come out.
> >
> >
> > On Sat, Sep 03, 2016 at 09:16:41AM +1200, Simon Wells wrote:
> > > dialog_pad_properties_base.fbp h cpp was last modified in commit
> > >
> > > 63decd70e6ab1bf2fe95db3f426f6cdfc79be213
> > > https://git.launchpad.net/kicad/commit/?id=
> > 63decd70e6ab1bf2fe95db3f426f6cdfc79be213
> > >
> > > the problem is this version of wxformbuilder is newer than the one
> > > available on sourceforge and it is very difficult to build on other
> > > platforms ( i tried a while ago and gave up as it had issues)
> > >
> > > the version that was used to save these files has broken it on older
> > > versions of wxformbuilder
> > >
> > > Is there a version of wxformbuilder that we should be using to avoid
> > > it breaking on other versions?
> > >
> > > the last available from sf.net is 3.5rc1 iirc
> > >
> > > thanks
> > >
> > > Simon
> > >
> > > ___
> > > Mailing list: https://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] wxformbuilder version

[Cirilo Bernardo]

I just use MRoszko's fork; it's cleaner than the original and much
easier to configure and build since the bizarre wxFB build system
had been eradicated and replaced by CMake.

git clone https://github.com/marekr/wxFormBuilder.git wxfb
cd wxfb && git checkout wxFB3.5-1

A half year or so ago I tried the later wxFB in development but it
broke so many things that I just reverted the files and went back to
wxFB3,5-1.

- Cirilo


On Sat, Sep 3, 2016 at 7:28 AM, Chris Pavlina 
wrote:

> Along these lines: this isn't the first time wxfb version issues have
> come up. Perhaps we should pick an "official" wxfb version for the
> project to use, and then actually provide builds of it for developer use
> (as it can be a bit annoying to track down a specific version)? Then we
> can upgrade together as new versions come out.
>
>
> On Sat, Sep 03, 2016 at 09:16:41AM +1200, Simon Wells wrote:
> > dialog_pad_properties_base.fbp h cpp was last modified in commit
> >
> > 63decd70e6ab1bf2fe95db3f426f6cdfc79be213
> > https://git.launchpad.net/kicad/commit/?id=
> 63decd70e6ab1bf2fe95db3f426f6cdfc79be213
> >
> > the problem is this version of wxformbuilder is newer than the one
> > available on sourceforge and it is very difficult to build on other
> > platforms ( i tried a while ago and gave up as it had issues)
> >
> > the version that was used to save these files has broken it on older
> > versions of wxformbuilder
> >
> > Is there a version of wxformbuilder that we should be using to avoid
> > it breaking on other versions?
> >
> > the last available from sf.net is 3.5rc1 iirc
> >
> > thanks
> >
> > Simon
> >
> > ___
> > Mailing list: https://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] wxformbuilder version

[Simon Wells]

as far as i can see 3.5.2 hasn't even been tagged in the wxformbuilder svn repo

On Sat, Sep 3, 2016 at 9:35 AM, José Ignacio  wrote:
> I have version 3.5.2
>
> On Fri, Sep 2, 2016 at 4:28 PM, Chris Pavlina  wrote:
>> Along these lines: this isn't the first time wxfb version issues have
>> come up. Perhaps we should pick an "official" wxfb version for the
>> project to use, and then actually provide builds of it for developer use
>> (as it can be a bit annoying to track down a specific version)? Then we
>> can upgrade together as new versions come out.
>>
>>
>> On Sat, Sep 03, 2016 at 09:16:41AM +1200, Simon Wells wrote:
>>> dialog_pad_properties_base.fbp h cpp was last modified in commit
>>>
>>> 63decd70e6ab1bf2fe95db3f426f6cdfc79be213
>>> https://git.launchpad.net/kicad/commit/?id=63decd70e6ab1bf2fe95db3f426f6cdfc79be213
>>>
>>> the problem is this version of wxformbuilder is newer than the one
>>> available on sourceforge and it is very difficult to build on other
>>> platforms ( i tried a while ago and gave up as it had issues)
>>>
>>> the version that was used to save these files has broken it on older
>>> versions of wxformbuilder
>>>
>>> Is there a version of wxformbuilder that we should be using to avoid
>>> it breaking on other versions?
>>>
>>> the last available from sf.net is 3.5rc1 iirc
>>>
>>> thanks
>>>
>>> Simon
>>>
>>> ___
>>> Mailing list: https://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] wxformbuilder version

[José Ignacio]

I have version 3.5.2

On Fri, Sep 2, 2016 at 4:28 PM, Chris Pavlina  wrote:
> Along these lines: this isn't the first time wxfb version issues have
> come up. Perhaps we should pick an "official" wxfb version for the
> project to use, and then actually provide builds of it for developer use
> (as it can be a bit annoying to track down a specific version)? Then we
> can upgrade together as new versions come out.
>
>
> On Sat, Sep 03, 2016 at 09:16:41AM +1200, Simon Wells wrote:
>> dialog_pad_properties_base.fbp h cpp was last modified in commit
>>
>> 63decd70e6ab1bf2fe95db3f426f6cdfc79be213
>> https://git.launchpad.net/kicad/commit/?id=63decd70e6ab1bf2fe95db3f426f6cdfc79be213
>>
>> the problem is this version of wxformbuilder is newer than the one
>> available on sourceforge and it is very difficult to build on other
>> platforms ( i tried a while ago and gave up as it had issues)
>>
>> the version that was used to save these files has broken it on older
>> versions of wxformbuilder
>>
>> Is there a version of wxformbuilder that we should be using to avoid
>> it breaking on other versions?
>>
>> the last available from sf.net is 3.5rc1 iirc
>>
>> thanks
>>
>> Simon
>>
>> ___
>> Mailing list: https://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] wxformbuilder version

[Chris Pavlina]

Along these lines: this isn't the first time wxfb version issues have
come up. Perhaps we should pick an "official" wxfb version for the
project to use, and then actually provide builds of it for developer use
(as it can be a bit annoying to track down a specific version)? Then we
can upgrade together as new versions come out.


On Sat, Sep 03, 2016 at 09:16:41AM +1200, Simon Wells wrote:
> dialog_pad_properties_base.fbp h cpp was last modified in commit
> 
> 63decd70e6ab1bf2fe95db3f426f6cdfc79be213
> https://git.launchpad.net/kicad/commit/?id=63decd70e6ab1bf2fe95db3f426f6cdfc79be213
> 
> the problem is this version of wxformbuilder is newer than the one
> available on sourceforge and it is very difficult to build on other
> platforms ( i tried a while ago and gave up as it had issues)
> 
> the version that was used to save these files has broken it on older
> versions of wxformbuilder
> 
> Is there a version of wxformbuilder that we should be using to avoid
> it breaking on other versions?
> 
> the last available from sf.net is 3.5rc1 iirc
> 
> thanks
> 
> Simon
> 
> ___
> Mailing list: https://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] wxformbuilder version

[Simon Wells]

dialog_pad_properties_base.fbp h cpp was last modified in commit

63decd70e6ab1bf2fe95db3f426f6cdfc79be213
https://git.launchpad.net/kicad/commit/?id=63decd70e6ab1bf2fe95db3f426f6cdfc79be213

the problem is this version of wxformbuilder is newer than the one
available on sourceforge and it is very difficult to build on other
platforms ( i tried a while ago and gave up as it had issues)

the version that was used to save these files has broken it on older
versions of wxformbuilder

Is there a version of wxformbuilder that we should be using to avoid
it breaking on other versions?

the last available from sf.net is 3.5rc1 iirc

thanks

Simon

___
Mailing list: https://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] OCE plugin for 3D viewer

[Nick Østergaard]

2016-09-02 23:05 GMT+02:00 Nick Østergaard :
> 2016-09-02 23:00 GMT+02:00 Wayne Stambaugh :
>> On 9/2/2016 4:28 PM, Nick Østergaard wrote:
>>> 2016-09-02 21:25 GMT+02:00 Wayne Stambaugh :
 Cirilo,

 Someone still needs to address building oce on msys2.  I just spent way
 too much time building oce from source on msys2.  The oce folks decided
 to ignore CMAKE_INSTALL_PREFIX and use there own install path stuff
 which is is not compatible with the msys2 file system hierarchy.  The
 bad thing is you cannot manually copy the dlls and link stub files to
 the appropriate paths because the generated cmake oce find stuff will
 point to the incorrect paths.  To create PKGBUILD for msys2 will require
 JP's patch to fix long command lengths along with a patch to fix oce's
 install path issues.  If someone else has time to work on this please do.
>>>
>>> As I mentioned earlier, I am trying to address the OCE build for
>>> msys2, but there are some problems, which I don't know if they are
>>> fixed in latest cmake.
>>>
>>> https://github.com/Alexpux/MINGW-packages/pull/1618
>>>
>>> I am just not sure what the best thing to do is for those paths for
>>> _IMPORT_PREFIX in OCE-libraries.cmake and
>>> OCE_INCLUDE_DIRS from OCEConfig.cmake.
>>>
>>> If they are set to windows paths, then it works. But that is not how
>>> they are generated, and it should probably be changed as a post
>>> install step if they need to be hacked like this.
>>
>> Here is the offending code in the main oce CMakeList file:
>>
>
> No. The install is just fine, it is just when you try to build against
> OCE the cmake files have some bad paths. I override the install
> locations in the PKGBUILD. I also don't know why OCE does it like that
> on windows, but as long as I can override it by configuring it via
> cmake arguments I am fine with that so far. No patching needed.
>

Note that the unix paths actually pust in the cmake files
OCE-libraries.cmake and OCEConfig.cmake are actually correct, but I
just think there is a bug in how the msys2 cmake handles them. I mean,
it should work with the unix paths.

>> # Libraries are installed by default in /usr/local/lib on UNIX
>> # based platforms and c:/OCE-VERSION/Win[32|64]/lib on windows based
>> # platforms
>>
>> if(WIN32)
>> set(_PSUFFIX "Win${BIT}/")
>> else(WIN32)
>> set(_PSUFFIX "")
>> endif(WIN32)
>>
>> This installs the dlls in ${OCE_INSTALL_PREFIX}/bin/win##/ and the link
>> stubs in ${OCE_INSTALL_PREFIX}/lib/win##/ where ## is either 32 or 64
>> depending on the build.  This probably should be:
>>
>> if(WIN32 AND NOT MINGW)
>> set(_PSUFFIX "Win${BIT}/")
>> else(WIN32)
>> set(_PSUFFIX "")
>> endif(WIN32)
>>
>> This would make _PSUFFIX="" which would should install everything in the
>> correct path and generate the correct cmake find files for the package.
>> Why the oce folks don't just use the default cmake install paths is
>> beyond me.  Maybe this is still here for issues with older versions of
>> cmake.
>>
>>>

 Thanks,

 Wayne

 On 9/2/2016 6:22 AM, Cirilo Bernardo wrote:
> Thanks for the merge and to everyone who's helped out with the
> cross-platform issues.
> I've got a new feature branch "kicad-step" with the kicad2step
> standalone tool if anyone
> feels like playing with it and providing some feedback.  This is the
> tool which I plan to
> make available as an item in the "Export" menu to give KiCad it's own
> built-in MCAD
> export.
>
> https://code.launchpad.net/~cirilo-bernardo/kicad/+git/kicad-oce
>
> The long-term plan is to make this tool a genuine plugin, but the API
> required for that
> is turning out to be quite a big job and is currently on hold due to my
> limited free time.
>
> This stand-alone tool makes use of mRoszko's SEXPR parser which is a
> great tool
> for making third-party tools that can read KiCad PCB files.
>
> - Cirilo
>
>
> On Fri, Sep 2, 2016 at 4:20 PM, Simon Wells  > wrote:
>
> just fyi a couple of tips on OSX
>
> Make sure that brew is installing oce-0.17.2 this was only commited to
> brew mid august so if its only installing 0.17 (which is broke) then
> brew update
>
> add
>
>  -DUSE_OCE=ON
> -DOCE_DIR=/usr/local/opt/oce/OCE.framework/Versions/0.17/Resources/
>
> to your cmake line and it will be bundled automatically. Tested on rev
> 38e7deb with no issues.
>
> On Fri, Sep 2, 2016 at 12:13 PM, Chris Pavlina
> > wrote:
> > Okay, this is friggin awesome. I can finally have models of
> > *everything*, it's so nice! :)
> >
> > Sexy PCB shot: 

Re: [Kicad-developers] OCE plugin for 3D viewer

[Nick Østergaard]

2016-09-02 23:00 GMT+02:00 Wayne Stambaugh :
> On 9/2/2016 4:28 PM, Nick Østergaard wrote:
>> 2016-09-02 21:25 GMT+02:00 Wayne Stambaugh :
>>> Cirilo,
>>>
>>> Someone still needs to address building oce on msys2.  I just spent way
>>> too much time building oce from source on msys2.  The oce folks decided
>>> to ignore CMAKE_INSTALL_PREFIX and use there own install path stuff
>>> which is is not compatible with the msys2 file system hierarchy.  The
>>> bad thing is you cannot manually copy the dlls and link stub files to
>>> the appropriate paths because the generated cmake oce find stuff will
>>> point to the incorrect paths.  To create PKGBUILD for msys2 will require
>>> JP's patch to fix long command lengths along with a patch to fix oce's
>>> install path issues.  If someone else has time to work on this please do.
>>
>> As I mentioned earlier, I am trying to address the OCE build for
>> msys2, but there are some problems, which I don't know if they are
>> fixed in latest cmake.
>>
>> https://github.com/Alexpux/MINGW-packages/pull/1618
>>
>> I am just not sure what the best thing to do is for those paths for
>> _IMPORT_PREFIX in OCE-libraries.cmake and
>> OCE_INCLUDE_DIRS from OCEConfig.cmake.
>>
>> If they are set to windows paths, then it works. But that is not how
>> they are generated, and it should probably be changed as a post
>> install step if they need to be hacked like this.
>
> Here is the offending code in the main oce CMakeList file:
>

No. The install is just fine, it is just when you try to build against
OCE the cmake files have some bad paths. I override the install
locations in the PKGBUILD. I also don't know why OCE does it like that
on windows, but as long as I can override it by configuring it via
cmake arguments I am fine with that so far. No patching needed.

> # Libraries are installed by default in /usr/local/lib on UNIX
> # based platforms and c:/OCE-VERSION/Win[32|64]/lib on windows based
> # platforms
>
> if(WIN32)
> set(_PSUFFIX "Win${BIT}/")
> else(WIN32)
> set(_PSUFFIX "")
> endif(WIN32)
>
> This installs the dlls in ${OCE_INSTALL_PREFIX}/bin/win##/ and the link
> stubs in ${OCE_INSTALL_PREFIX}/lib/win##/ where ## is either 32 or 64
> depending on the build.  This probably should be:
>
> if(WIN32 AND NOT MINGW)
> set(_PSUFFIX "Win${BIT}/")
> else(WIN32)
> set(_PSUFFIX "")
> endif(WIN32)
>
> This would make _PSUFFIX="" which would should install everything in the
> correct path and generate the correct cmake find files for the package.
> Why the oce folks don't just use the default cmake install paths is
> beyond me.  Maybe this is still here for issues with older versions of
> cmake.
>
>>
>>>
>>> Thanks,
>>>
>>> Wayne
>>>
>>> On 9/2/2016 6:22 AM, Cirilo Bernardo wrote:
 Thanks for the merge and to everyone who's helped out with the
 cross-platform issues.
 I've got a new feature branch "kicad-step" with the kicad2step
 standalone tool if anyone
 feels like playing with it and providing some feedback.  This is the
 tool which I plan to
 make available as an item in the "Export" menu to give KiCad it's own
 built-in MCAD
 export.

 https://code.launchpad.net/~cirilo-bernardo/kicad/+git/kicad-oce

 The long-term plan is to make this tool a genuine plugin, but the API
 required for that
 is turning out to be quite a big job and is currently on hold due to my
 limited free time.

 This stand-alone tool makes use of mRoszko's SEXPR parser which is a
 great tool
 for making third-party tools that can read KiCad PCB files.

 - Cirilo


 On Fri, Sep 2, 2016 at 4:20 PM, Simon Wells > wrote:

 just fyi a couple of tips on OSX

 Make sure that brew is installing oce-0.17.2 this was only commited to
 brew mid august so if its only installing 0.17 (which is broke) then
 brew update

 add

  -DUSE_OCE=ON
 -DOCE_DIR=/usr/local/opt/oce/OCE.framework/Versions/0.17/Resources/

 to your cmake line and it will be bundled automatically. Tested on rev
 38e7deb with no issues.

 On Fri, Sep 2, 2016 at 12:13 PM, Chris Pavlina
 > wrote:
 > Okay, this is friggin awesome. I can finally have models of
 > *everything*, it's so nice! :)
 >
 > Sexy PCB shot: https://misc.c4757p.com/12091-motherboard.png
 
 >
 > Thanks Cirilo!
 >
 > On Thu, Sep 01, 2016 at 04:45:33PM -0400, Wayne Stambaugh wrote:
 >>
 >>
 >> On 9/1/2016 4:18 PM, Chris Pavlina wrote:
 >> > On Thu, Sep 01, 2016 at 04:10:13PM -0400, Wayne Stambaugh wrote:
 >> >> On 9/1/2016 2:29 PM, José Ignacio 

Re: [Kicad-developers] OCE plugin for 3D viewer

[Wayne Stambaugh]

On 9/2/2016 4:28 PM, Nick Østergaard wrote:
> 2016-09-02 21:25 GMT+02:00 Wayne Stambaugh :
>> Cirilo,
>>
>> Someone still needs to address building oce on msys2.  I just spent way
>> too much time building oce from source on msys2.  The oce folks decided
>> to ignore CMAKE_INSTALL_PREFIX and use there own install path stuff
>> which is is not compatible with the msys2 file system hierarchy.  The
>> bad thing is you cannot manually copy the dlls and link stub files to
>> the appropriate paths because the generated cmake oce find stuff will
>> point to the incorrect paths.  To create PKGBUILD for msys2 will require
>> JP's patch to fix long command lengths along with a patch to fix oce's
>> install path issues.  If someone else has time to work on this please do.
> 
> As I mentioned earlier, I am trying to address the OCE build for
> msys2, but there are some problems, which I don't know if they are
> fixed in latest cmake.
> 
> https://github.com/Alexpux/MINGW-packages/pull/1618
> 
> I am just not sure what the best thing to do is for those paths for
> _IMPORT_PREFIX in OCE-libraries.cmake and
> OCE_INCLUDE_DIRS from OCEConfig.cmake.
> 
> If they are set to windows paths, then it works. But that is not how
> they are generated, and it should probably be changed as a post
> install step if they need to be hacked like this.

Here is the offending code in the main oce CMakeList file:

# Libraries are installed by default in /usr/local/lib on UNIX
# based platforms and c:/OCE-VERSION/Win[32|64]/lib on windows based
# platforms

if(WIN32)
set(_PSUFFIX "Win${BIT}/")
else(WIN32)
set(_PSUFFIX "")
endif(WIN32)

This installs the dlls in ${OCE_INSTALL_PREFIX}/bin/win##/ and the link
stubs in ${OCE_INSTALL_PREFIX}/lib/win##/ where ## is either 32 or 64
depending on the build.  This probably should be:

if(WIN32 AND NOT MINGW)
set(_PSUFFIX "Win${BIT}/")
else(WIN32)
set(_PSUFFIX "")
endif(WIN32)

This would make _PSUFFIX="" which would should install everything in the
correct path and generate the correct cmake find files for the package.
Why the oce folks don't just use the default cmake install paths is
beyond me.  Maybe this is still here for issues with older versions of
cmake.

> 
>>
>> Thanks,
>>
>> Wayne
>>
>> On 9/2/2016 6:22 AM, Cirilo Bernardo wrote:
>>> Thanks for the merge and to everyone who's helped out with the
>>> cross-platform issues.
>>> I've got a new feature branch "kicad-step" with the kicad2step
>>> standalone tool if anyone
>>> feels like playing with it and providing some feedback.  This is the
>>> tool which I plan to
>>> make available as an item in the "Export" menu to give KiCad it's own
>>> built-in MCAD
>>> export.
>>>
>>> https://code.launchpad.net/~cirilo-bernardo/kicad/+git/kicad-oce
>>>
>>> The long-term plan is to make this tool a genuine plugin, but the API
>>> required for that
>>> is turning out to be quite a big job and is currently on hold due to my
>>> limited free time.
>>>
>>> This stand-alone tool makes use of mRoszko's SEXPR parser which is a
>>> great tool
>>> for making third-party tools that can read KiCad PCB files.
>>>
>>> - Cirilo
>>>
>>>
>>> On Fri, Sep 2, 2016 at 4:20 PM, Simon Wells >> > wrote:
>>>
>>> just fyi a couple of tips on OSX
>>>
>>> Make sure that brew is installing oce-0.17.2 this was only commited to
>>> brew mid august so if its only installing 0.17 (which is broke) then
>>> brew update
>>>
>>> add
>>>
>>>  -DUSE_OCE=ON
>>> -DOCE_DIR=/usr/local/opt/oce/OCE.framework/Versions/0.17/Resources/
>>>
>>> to your cmake line and it will be bundled automatically. Tested on rev
>>> 38e7deb with no issues.
>>>
>>> On Fri, Sep 2, 2016 at 12:13 PM, Chris Pavlina
>>> > wrote:
>>> > Okay, this is friggin awesome. I can finally have models of
>>> > *everything*, it's so nice! :)
>>> >
>>> > Sexy PCB shot: https://misc.c4757p.com/12091-motherboard.png
>>> 
>>> >
>>> > Thanks Cirilo!
>>> >
>>> > On Thu, Sep 01, 2016 at 04:45:33PM -0400, Wayne Stambaugh wrote:
>>> >>
>>> >>
>>> >> On 9/1/2016 4:18 PM, Chris Pavlina wrote:
>>> >> > On Thu, Sep 01, 2016 at 04:10:13PM -0400, Wayne Stambaugh wrote:
>>> >> >> On 9/1/2016 2:29 PM, José Ignacio wrote:
>>> >> >>> On Thu, Sep 1, 2016 at 12:02 PM, Wayne Stambaugh
>>> > wrote:
>>> >>  Sorry it took so long.  I took a look at Cirilo's changes an
>>> it looks
>>> >>  good.  We still need a PKGBUILD file for msys2 with JPs
>>> patch so we
>>> >>  don't have to build oce from source.
>>> >> 
>>> >>  When I merge Cirilo's 3d-plugin branch and I had to create a
>>> commit
>>> >>  message which made me the commit author.  

Re: [Kicad-developers] OCE plugin for 3D viewer

[Nick Østergaard]

2016-09-02 21:25 GMT+02:00 Wayne Stambaugh :
> Cirilo,
>
> Someone still needs to address building oce on msys2.  I just spent way
> too much time building oce from source on msys2.  The oce folks decided
> to ignore CMAKE_INSTALL_PREFIX and use there own install path stuff
> which is is not compatible with the msys2 file system hierarchy.  The
> bad thing is you cannot manually copy the dlls and link stub files to
> the appropriate paths because the generated cmake oce find stuff will
> point to the incorrect paths.  To create PKGBUILD for msys2 will require
> JP's patch to fix long command lengths along with a patch to fix oce's
> install path issues.  If someone else has time to work on this please do.

As I mentioned earlier, I am trying to address the OCE build for
msys2, but there are some problems, which I don't know if they are
fixed in latest cmake.

https://github.com/Alexpux/MINGW-packages/pull/1618

I am just not sure what the best thing to do is for those paths for
_IMPORT_PREFIX in OCE-libraries.cmake and
OCE_INCLUDE_DIRS from OCEConfig.cmake.

If they are set to windows paths, then it works. But that is not how
they are generated, and it should probably be changed as a post
install step if they need to be hacked like this.

>
> Thanks,
>
> Wayne
>
> On 9/2/2016 6:22 AM, Cirilo Bernardo wrote:
>> Thanks for the merge and to everyone who's helped out with the
>> cross-platform issues.
>> I've got a new feature branch "kicad-step" with the kicad2step
>> standalone tool if anyone
>> feels like playing with it and providing some feedback.  This is the
>> tool which I plan to
>> make available as an item in the "Export" menu to give KiCad it's own
>> built-in MCAD
>> export.
>>
>> https://code.launchpad.net/~cirilo-bernardo/kicad/+git/kicad-oce
>>
>> The long-term plan is to make this tool a genuine plugin, but the API
>> required for that
>> is turning out to be quite a big job and is currently on hold due to my
>> limited free time.
>>
>> This stand-alone tool makes use of mRoszko's SEXPR parser which is a
>> great tool
>> for making third-party tools that can read KiCad PCB files.
>>
>> - Cirilo
>>
>>
>> On Fri, Sep 2, 2016 at 4:20 PM, Simon Wells > > wrote:
>>
>> just fyi a couple of tips on OSX
>>
>> Make sure that brew is installing oce-0.17.2 this was only commited to
>> brew mid august so if its only installing 0.17 (which is broke) then
>> brew update
>>
>> add
>>
>>  -DUSE_OCE=ON
>> -DOCE_DIR=/usr/local/opt/oce/OCE.framework/Versions/0.17/Resources/
>>
>> to your cmake line and it will be bundled automatically. Tested on rev
>> 38e7deb with no issues.
>>
>> On Fri, Sep 2, 2016 at 12:13 PM, Chris Pavlina
>> > wrote:
>> > Okay, this is friggin awesome. I can finally have models of
>> > *everything*, it's so nice! :)
>> >
>> > Sexy PCB shot: https://misc.c4757p.com/12091-motherboard.png
>> 
>> >
>> > Thanks Cirilo!
>> >
>> > On Thu, Sep 01, 2016 at 04:45:33PM -0400, Wayne Stambaugh wrote:
>> >>
>> >>
>> >> On 9/1/2016 4:18 PM, Chris Pavlina wrote:
>> >> > On Thu, Sep 01, 2016 at 04:10:13PM -0400, Wayne Stambaugh wrote:
>> >> >> On 9/1/2016 2:29 PM, José Ignacio wrote:
>> >> >>> On Thu, Sep 1, 2016 at 12:02 PM, Wayne Stambaugh
>> > wrote:
>> >>  Sorry it took so long.  I took a look at Cirilo's changes an
>> it looks
>> >>  good.  We still need a PKGBUILD file for msys2 with JPs
>> patch so we
>> >>  don't have to build oce from source.
>> >> 
>> >>  When I merge Cirilo's 3d-plugin branch and I had to create a
>> commit
>> >>  message which made me the commit author.  This seems brain
>> dead to me.
>> >>  Here is the new commit log entry:
>> >> 
>> >>  commit 12c26047bffd54ccbb88348acfe7f653556450da
>> >>  Merge: fcedef8 b656a81
>> >>  Author: Wayne Stambaugh > >
>> >>  Date:   Thu Sep 1 11:59:44 2016 -0400
>> >> 
>> >>  Merge remote-tracking branch 'cirilo/3d-plugin'
>> >> 
>> >>  I really only want to show Cirilo's commit log entries as a
>> new commit.
>> >>  WTF! I'm liking git less every time I use it.  What do I
>> need to do to
>> >>  get the correct commit history from Cirlo's 3d-plugin branch?
>> >> 
>> >> >>>
>> >> >>> Cirilo's commit history remains intact in the merged branch,
>> you just
>> >> >>> need to walk through that branch instead of master when
>> reading the
>> >> >>> commit logs. If cirilo's branch was rebased to the current
>> master you
>> >> >>> could do a fast-forward merge, 

[Kicad-developers] msys2 wxPython broken.

[Wayne Stambaugh]

A warning to the window package devs and anyone building kicad from
source using msys2.  You will either have to rebuild the wxPython
package with gcc 6.1 or wait for the msys2 devs to rebuild it.
Otherwise you will create a broken kicad builds.  The latest wxWidgets
package was build with gcc 6.1 which is abi incompatible with packaged
version of wxPython so running pcbnew or the footprint editor will crash
kicad.  I sent an email to the msys2 users mailing list to make them
aware of the situation.  Hopefully this will be resolved soon.  Just
wanted to save everyone some grief which I just had to endure.

Cheers,

Wayne

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

Re: [Kicad-developers] OCE plugin for 3D viewer

[Wayne Stambaugh]

Cirilo,

Someone still needs to address building oce on msys2.  I just spent way
too much time building oce from source on msys2.  The oce folks decided
to ignore CMAKE_INSTALL_PREFIX and use there own install path stuff
which is is not compatible with the msys2 file system hierarchy.  The
bad thing is you cannot manually copy the dlls and link stub files to
the appropriate paths because the generated cmake oce find stuff will
point to the incorrect paths.  To create PKGBUILD for msys2 will require
JP's patch to fix long command lengths along with a patch to fix oce's
install path issues.  If someone else has time to work on this please do.

Thanks,

Wayne

On 9/2/2016 6:22 AM, Cirilo Bernardo wrote:
> Thanks for the merge and to everyone who's helped out with the
> cross-platform issues.
> I've got a new feature branch "kicad-step" with the kicad2step
> standalone tool if anyone
> feels like playing with it and providing some feedback.  This is the
> tool which I plan to
> make available as an item in the "Export" menu to give KiCad it's own
> built-in MCAD
> export.
> 
> https://code.launchpad.net/~cirilo-bernardo/kicad/+git/kicad-oce
> 
> The long-term plan is to make this tool a genuine plugin, but the API
> required for that
> is turning out to be quite a big job and is currently on hold due to my
> limited free time.
> 
> This stand-alone tool makes use of mRoszko's SEXPR parser which is a
> great tool
> for making third-party tools that can read KiCad PCB files.
> 
> - Cirilo
> 
> 
> On Fri, Sep 2, 2016 at 4:20 PM, Simon Wells  > wrote:
> 
> just fyi a couple of tips on OSX
> 
> Make sure that brew is installing oce-0.17.2 this was only commited to
> brew mid august so if its only installing 0.17 (which is broke) then
> brew update
> 
> add
> 
>  -DUSE_OCE=ON
> -DOCE_DIR=/usr/local/opt/oce/OCE.framework/Versions/0.17/Resources/
> 
> to your cmake line and it will be bundled automatically. Tested on rev
> 38e7deb with no issues.
> 
> On Fri, Sep 2, 2016 at 12:13 PM, Chris Pavlina
> > wrote:
> > Okay, this is friggin awesome. I can finally have models of
> > *everything*, it's so nice! :)
> >
> > Sexy PCB shot: https://misc.c4757p.com/12091-motherboard.png
> 
> >
> > Thanks Cirilo!
> >
> > On Thu, Sep 01, 2016 at 04:45:33PM -0400, Wayne Stambaugh wrote:
> >>
> >>
> >> On 9/1/2016 4:18 PM, Chris Pavlina wrote:
> >> > On Thu, Sep 01, 2016 at 04:10:13PM -0400, Wayne Stambaugh wrote:
> >> >> On 9/1/2016 2:29 PM, José Ignacio wrote:
> >> >>> On Thu, Sep 1, 2016 at 12:02 PM, Wayne Stambaugh
> > wrote:
> >>  Sorry it took so long.  I took a look at Cirilo's changes an
> it looks
> >>  good.  We still need a PKGBUILD file for msys2 with JPs
> patch so we
> >>  don't have to build oce from source.
> >> 
> >>  When I merge Cirilo's 3d-plugin branch and I had to create a
> commit
> >>  message which made me the commit author.  This seems brain
> dead to me.
> >>  Here is the new commit log entry:
> >> 
> >>  commit 12c26047bffd54ccbb88348acfe7f653556450da
> >>  Merge: fcedef8 b656a81
> >>  Author: Wayne Stambaugh  >
> >>  Date:   Thu Sep 1 11:59:44 2016 -0400
> >> 
> >>  Merge remote-tracking branch 'cirilo/3d-plugin'
> >> 
> >>  I really only want to show Cirilo's commit log entries as a
> new commit.
> >>  WTF! I'm liking git less every time I use it.  What do I
> need to do to
> >>  get the correct commit history from Cirlo's 3d-plugin branch?
> >> 
> >> >>>
> >> >>> Cirilo's commit history remains intact in the merged branch,
> you just
> >> >>> need to walk through that branch instead of master when
> reading the
> >> >>> commit logs. If cirilo's branch was rebased to the current
> master you
> >> >>> could do a fast-forward merge, which would graft his commits
> into the
> >> >>> master branch and make his last commit the "new master". In
> either
> >> >>> case the history is perfectly readable.
> >> >>>
> >> >>
> >> >> Yes but before I got chance to push my branch, Chris pushed a
> change so
> >> >> when I pulled his changes, git conveniently created yet
> another commit
> >> >> message.  Do we really want all this extra cruft in the commit
> log or do
> >> >> we want to rebase against the kicad master?
> >> >
> >> > Start using git pull --rebase like I suggested earlier, it
> would avoid
> >> > that.
> >> >
> >>
> >> I pushed Cirilo's OCE changes so hopefully 

Re: [Kicad-developers] OCE plugin for 3D viewer

[Eldar Khayrullin]

Thank you. It is great work.

В Пятница, 2 сен. 2016 в 1:22 , Cirilo Bernardo 
 написал:
Thanks for the merge and to everyone who's helped out with the 
cross-platform issues.
I've got a new feature branch "kicad-step" with the kicad2step 
standalone tool if anyone
feels like playing with it and providing some feedback.  This is the 
tool which I plan to
make available as an item in the "Export" menu to give KiCad it's own 
built-in MCAD

export.

https://code.launchpad.net/~cirilo-bernardo/kicad/+git/kicad-oce

The long-term plan is to make this tool a genuine plugin, but the API 
required for that
is turning out to be quite a big job and is currently on hold due to 
my limited free time.


This stand-alone tool makes use of mRoszko's SEXPR parser which is a 
great tool

for making third-party tools that can read KiCad PCB files.

- Cirilo


On Fri, Sep 2, 2016 at 4:20 PM, Simon Wells  wrote:

just fyi a couple of tips on OSX

Make sure that brew is installing oce-0.17.2 this was only commited 
to

brew mid august so if its only installing 0.17 (which is broke) then
brew update

add

 -DUSE_OCE=ON 
-DOCE_DIR=/usr/local/opt/oce/OCE.framework/Versions/0.17/Resources/


to your cmake line and it will be bundled automatically. Tested on 
rev

38e7deb with no issues.

On Fri, Sep 2, 2016 at 12:13 PM, Chris Pavlina 
 wrote:

> Okay, this is friggin awesome. I can finally have models of
> *everything*, it's so nice! :)
>
> Sexy PCB shot: https://misc.c4757p.com/12091-motherboard.png
>
> Thanks Cirilo!
>
> On Thu, Sep 01, 2016 at 04:45:33PM -0400, Wayne Stambaugh wrote:
>>
>>
>> On 9/1/2016 4:18 PM, Chris Pavlina wrote:
>> > On Thu, Sep 01, 2016 at 04:10:13PM -0400, Wayne Stambaugh wrote:
>> >> On 9/1/2016 2:29 PM, José Ignacio wrote:
>> >>> On Thu, Sep 1, 2016 at 12:02 PM, Wayne Stambaugh 
 wrote:
>>  Sorry it took so long.  I took a look at Cirilo's changes an 
it looks
>>  good.  We still need a PKGBUILD file for msys2 with JPs 
patch so we

>>  don't have to build oce from source.
>> 
>>  When I merge Cirilo's 3d-plugin branch and I had to create a 
commit
>>  message which made me the commit author.  This seems brain 
dead to me.

>>  Here is the new commit log entry:
>> 
>>  commit 12c26047bffd54ccbb88348acfe7f653556450da
>>  Merge: fcedef8 b656a81
>>  Author: Wayne Stambaugh 
>>  Date:   Thu Sep 1 11:59:44 2016 -0400
>> 
>>  Merge remote-tracking branch 'cirilo/3d-plugin'
>> 
>>  I really only want to show Cirilo's commit log entries as a 
new commit.
>>  WTF! I'm liking git less every time I use it.  What do I 
need to do to

>>  get the correct commit history from Cirlo's 3d-plugin branch?
>> 
>> >>>
>> >>> Cirilo's commit history remains intact in the merged branch, 
you just
>> >>> need to walk through that branch instead of master when 
reading the
>> >>> commit logs. If cirilo's branch was rebased to the current 
master you
>> >>> could do a fast-forward merge, which would graft his commits 
into the
>> >>> master branch and make his last commit the "new master". In 
either

>> >>> case the history is perfectly readable.
>> >>>
>> >>
>> >> Yes but before I got chance to push my branch, Chris pushed a 
change so
>> >> when I pulled his changes, git conveniently created yet 
another commit
>> >> message.  Do we really want all this extra cruft in the commit 
log or do

>> >> we want to rebase against the kicad master?
>> >
>> > Start using git pull --rebase like I suggested earlier, it 
would avoid

>> > that.
>> >
>>
>> I pushed Cirilo's OCE changes so hopefully I didn't fsck up the 
main

>> repo too badly.  Thank you Cirilo for the OCE plugin work.
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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


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

Re: [Kicad-developers] RFC: use of DXF files

[timofonic timofonic]

Hello.


I don't know how others see DXF (DWG too?) useful, but I find the file
format implementation situation somewhat chaotic:


- Bert Timmerman is actively developing libdxf (https://github.com/bert/libdxf).

- A try to isolate dxf code from LibArea project:
https://github.com/thatcadguy/dxf-cpp https://github.com/Heeks/libarea

- libdxfrw, born from the LibreDWG controversy to license it to GPLv3
instead something like LGPL:
https://github.com/LibreCAD/LibreCAD/tree/master/libraries/libdxfrw

- libdxf, I have no idea but it's in the LibreCAD repo:
https://github.com/LibreCAD/LibreCAD/tree/master/libraries/dxflib

- There's LibDWG fork using GPLv3 too, but not so actively developed.

- Libopencad (https://github.com/sandyre/libopencad), but it uses
muparser with the GPL-incompatible IBM's Common Public License.


Why so much projects for only DXF and DWG formats?

Kind regards.

2016-09-01 10:49 GMT+02:00 Cirilo Bernardo :
> Hi Folks,
>
>  DXF Import seems to be popular enough that we have the
> occasional questions and complaints about how to use it
> for a specific task. The items I can think of include:
>
> 1. being able to process Layers and associate a named
> DXF Layer with a specific KiCad Layer.
>
> 2. "I can't import Feature X". This one comes up now and then;
> the most popular is "why doesn't kicad support DXF filled
> regions?" More recently someone was asking about importing
> a DXF Point (what that would represent in KiCad is anyone's guess).
>
> In the past I put a little work into a few minor fixes and adding
> PolyLine support for outlines, but I haven't done anything more
> since there seems to be no long-term plan for DXF. Does anyone
> think some effort should go into a grand plan for how DXF can
> interact with KiCad, especially on the Import side? If it is a
> useful enough tool and we can come up with a sensible scheme
> which general users would find useful I can put in a little time to
> code it.
>
> - 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] libngspice in Homebrew

[Simon Wells]

ah ok, all good yeah i had bison brewed already as it was
required, and i have no issues with using the osx version of flex but
probably not a bad idea, i just got a bit confused as i hadn't used it
to build..

still thanks for pushing it to brew, i was just satisfied with
building it myself but can't beat brew for deps

On Sat, Sep 3, 2016 at 1:54 AM, Johannes Maibaum  wrote:
>> Am 02.09.2016 um 15:34 schrieb Simon Wells :
>>
>> Hey johannes,
>>
>> I am just in the process of brewing libngspice and noticed that flex
>> was a requirement? should that not be an option as i don't seem to
>> have needed it to build myself?
>>
>> Simon
>
> Hi Simon,
>
> actually I am not really sure a Homebrewed flex is needed for
> successfully building libngspice.  As with bison, flex comes with
> OSX, but in an older version.  The OSX version of bison (2.3, I
> think) is too old for building ngspice’s HEAD, so I had that in my
> formula already.  My thinking went further that if a newer bison
> is needed for a HEAD build, perhaps using a newer flex might be good
> as well, as the two tools are often used together for lexing and
> parsing.  So I included flex as a dependency, too.
>
> I had some discussions with the Homebrew maintainers who did not
> want me to add options for --enable-cider and -xspice, but to
> hardcode them in.  Their rationale seems to be that options should
> only be there, when there are issues for some people.  If you find
> an issue with Homebrewed flex, they might let me add and option for
> flex.
>
> Best,
> Johannes

___
Mailing list: https://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] libngspice in Homebrew

[Johannes Maibaum]

> Am 02.09.2016 um 15:34 schrieb Simon Wells :
> 
> Hey johannes,
> 
> I am just in the process of brewing libngspice and noticed that flex
> was a requirement? should that not be an option as i don't seem to
> have needed it to build myself?
> 
> Simon

Hi Simon,

actually I am not really sure a Homebrewed flex is needed for
successfully building libngspice.  As with bison, flex comes with
OSX, but in an older version.  The OSX version of bison (2.3, I
think) is too old for building ngspice’s HEAD, so I had that in my
formula already.  My thinking went further that if a newer bison
is needed for a HEAD build, perhaps using a newer flex might be good
as well, as the two tools are often used together for lexing and
parsing.  So I included flex as a dependency, too.

I had some discussions with the Homebrew maintainers who did not
want me to add options for --enable-cider and -xspice, but to
hardcode them in.  Their rationale seems to be that options should
only be there, when there are issues for some people.  If you find
an issue with Homebrewed flex, they might let me add and option for
flex.

Best,
Johannes
___
Mailing list: https://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] libngspice in Homebrew

[Simon Wells]

The only issue i see with those being the only options is head is a
moving target which may cause us issues down the road, esspecially
considering the last time a stable was released i am unsure of the
stability of head and iirc the current "stable" version is either
buggy or in some other way bad, however its better than nothing so i
also offer thanks

On Sat, Sep 3, 2016 at 12:46 AM, Adam Wolf
 wrote:
> Thanks Johannes!
>
> On Fri, Sep 2, 2016 at 4:07 AM, Johannes Maibaum  wrote:
>>
>> Hi OSX devs & packagers,
>>
>> just FYI, the Homebrew maintainers have merged my PR for a
>> libngspice formula [1].
>>
>> The formula builds ngspice as shared library, either the current
>> stable version (26, bottled) or the current HEAD from Sourceforge
>> git.
>>
>> It uses the same ./configure arguments as Orson’s ngspice build
>> script, so it may be used as a direct replacement for OSX devs
>> working on Kicad.
>>
>> I have also fixed the bug that the headers don’t get installed to
>> /usr/local/include/, which Orson had reported upstream [2].
>>
>>
>> Cheers,
>> Johannes
>>
>>
>> [1]
>> https://github.com/Homebrew/homebrew-core/blob/master/Formula/libngspice.rb
>> [2] https://sourceforge.net/p/ngspice/bugs/327
>> ___
>> Mailing list: https://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] libngspice in Homebrew

[Adam Wolf]

Thanks Johannes!

On Fri, Sep 2, 2016 at 4:07 AM, Johannes Maibaum  wrote:

> Hi OSX devs & packagers,
>
> just FYI, the Homebrew maintainers have merged my PR for a
> libngspice formula [1].
>
> The formula builds ngspice as shared library, either the current
> stable version (26, bottled) or the current HEAD from Sourceforge
> git.
>
> It uses the same ./configure arguments as Orson’s ngspice build
> script, so it may be used as a direct replacement for OSX devs
> working on Kicad.
>
> I have also fixed the bug that the headers don’t get installed to
> /usr/local/include/, which Orson had reported upstream [2].
>
>
> Cheers,
> Johannes
>
>
> [1] https://github.com/Homebrew/homebrew-core/blob/master/
> Formula/libngspice.rb
> [2] https://sourceforge.net/p/ngspice/bugs/327
> ___
> Mailing list: https://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] OCE plugin for 3D viewer

[Adam Wolf]

Thanks Simon!

On Fri, Sep 2, 2016 at 1:20 AM, Simon Wells  wrote:

> just fyi a couple of tips on OSX
>
> Make sure that brew is installing oce-0.17.2 this was only commited to
> brew mid august so if its only installing 0.17 (which is broke) then
> brew update
>
> add
>
>  -DUSE_OCE=ON -DOCE_DIR=/usr/local/opt/oce/OCE.framework/Versions/0.17/
> Resources/
>
> to your cmake line and it will be bundled automatically. Tested on rev
> 38e7deb with no issues.
>
> On Fri, Sep 2, 2016 at 12:13 PM, Chris Pavlina 
> wrote:
> > Okay, this is friggin awesome. I can finally have models of
> > *everything*, it's so nice! :)
> >
> > Sexy PCB shot: https://misc.c4757p.com/12091-motherboard.png
> >
> > Thanks Cirilo!
> >
> > On Thu, Sep 01, 2016 at 04:45:33PM -0400, Wayne Stambaugh wrote:
> >>
> >>
> >> On 9/1/2016 4:18 PM, Chris Pavlina wrote:
> >> > On Thu, Sep 01, 2016 at 04:10:13PM -0400, Wayne Stambaugh wrote:
> >> >> On 9/1/2016 2:29 PM, José Ignacio wrote:
> >> >>> On Thu, Sep 1, 2016 at 12:02 PM, Wayne Stambaugh <
> stambau...@gmail.com> wrote:
> >>  Sorry it took so long.  I took a look at Cirilo's changes an it
> looks
> >>  good.  We still need a PKGBUILD file for msys2 with JPs patch so we
> >>  don't have to build oce from source.
> >> 
> >>  When I merge Cirilo's 3d-plugin branch and I had to create a commit
> >>  message which made me the commit author.  This seems brain dead to
> me.
> >>  Here is the new commit log entry:
> >> 
> >>  commit 12c26047bffd54ccbb88348acfe7f653556450da
> >>  Merge: fcedef8 b656a81
> >>  Author: Wayne Stambaugh 
> >>  Date:   Thu Sep 1 11:59:44 2016 -0400
> >> 
> >>  Merge remote-tracking branch 'cirilo/3d-plugin'
> >> 
> >>  I really only want to show Cirilo's commit log entries as a new
> commit.
> >>  WTF! I'm liking git less every time I use it.  What do I need to
> do to
> >>  get the correct commit history from Cirlo's 3d-plugin branch?
> >> 
> >> >>>
> >> >>> Cirilo's commit history remains intact in the merged branch, you
> just
> >> >>> need to walk through that branch instead of master when reading the
> >> >>> commit logs. If cirilo's branch was rebased to the current master
> you
> >> >>> could do a fast-forward merge, which would graft his commits into
> the
> >> >>> master branch and make his last commit the "new master". In either
> >> >>> case the history is perfectly readable.
> >> >>>
> >> >>
> >> >> Yes but before I got chance to push my branch, Chris pushed a change
> so
> >> >> when I pulled his changes, git conveniently created yet another
> commit
> >> >> message.  Do we really want all this extra cruft in the commit log
> or do
> >> >> we want to rebase against the kicad master?
> >> >
> >> > Start using git pull --rebase like I suggested earlier, it would avoid
> >> > that.
> >> >
> >>
> >> I pushed Cirilo's OCE changes so hopefully I didn't fsck up the main
> >> repo too badly.  Thank you Cirilo for the OCE plugin work.
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://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] OCE plugin for 3D viewer

[Wayne Stambaugh]

On 09/01/2016 08:13 PM, Chris Pavlina wrote:
> Okay, this is friggin awesome. I can finally have models of
> *everything*, it's so nice! :)
> 
> Sexy PCB shot: https://misc.c4757p.com/12091-motherboard.png

Nice!

> 
> Thanks Cirilo!
> 
> On Thu, Sep 01, 2016 at 04:45:33PM -0400, Wayne Stambaugh wrote:
>>
>>
>> On 9/1/2016 4:18 PM, Chris Pavlina wrote:
>>> On Thu, Sep 01, 2016 at 04:10:13PM -0400, Wayne Stambaugh wrote:
 On 9/1/2016 2:29 PM, José Ignacio wrote:
> On Thu, Sep 1, 2016 at 12:02 PM, Wayne Stambaugh  
> wrote:
>> Sorry it took so long.  I took a look at Cirilo's changes an it looks
>> good.  We still need a PKGBUILD file for msys2 with JPs patch so we
>> don't have to build oce from source.
>>
>> When I merge Cirilo's 3d-plugin branch and I had to create a commit
>> message which made me the commit author.  This seems brain dead to me.
>> Here is the new commit log entry:
>>
>> commit 12c26047bffd54ccbb88348acfe7f653556450da
>> Merge: fcedef8 b656a81
>> Author: Wayne Stambaugh 
>> Date:   Thu Sep 1 11:59:44 2016 -0400
>>
>> Merge remote-tracking branch 'cirilo/3d-plugin'
>>
>> I really only want to show Cirilo's commit log entries as a new commit.
>> WTF! I'm liking git less every time I use it.  What do I need to do to
>> get the correct commit history from Cirlo's 3d-plugin branch?
>>
>
> Cirilo's commit history remains intact in the merged branch, you just
> need to walk through that branch instead of master when reading the
> commit logs. If cirilo's branch was rebased to the current master you
> could do a fast-forward merge, which would graft his commits into the
> master branch and make his last commit the "new master". In either
> case the history is perfectly readable.
>

 Yes but before I got chance to push my branch, Chris pushed a change so
 when I pulled his changes, git conveniently created yet another commit
 message.  Do we really want all this extra cruft in the commit log or do
 we want to rebase against the kicad master?
>>>
>>> Start using git pull --rebase like I suggested earlier, it would avoid
>>> that.
>>>
>>
>> I pushed Cirilo's OCE changes so hopefully I didn't fsck up the main
>> repo too badly.  Thank you Cirilo for the OCE plugin work.

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

Re: [Kicad-developers] OCE plugin for 3D viewer

[Cirilo Bernardo]

Thanks for the merge and to everyone who's helped out with the
cross-platform issues.
I've got a new feature branch "kicad-step" with the kicad2step standalone
tool if anyone
feels like playing with it and providing some feedback.  This is the tool
which I plan to
make available as an item in the "Export" menu to give KiCad it's own
built-in MCAD
export.

https://code.launchpad.net/~cirilo-bernardo/kicad/+git/kicad-oce

The long-term plan is to make this tool a genuine plugin, but the API
required for that
is turning out to be quite a big job and is currently on hold due to my
limited free time.

This stand-alone tool makes use of mRoszko's SEXPR parser which is a great
tool
for making third-party tools that can read KiCad PCB files.

- Cirilo


On Fri, Sep 2, 2016 at 4:20 PM, Simon Wells  wrote:

> just fyi a couple of tips on OSX
>
> Make sure that brew is installing oce-0.17.2 this was only commited to
> brew mid august so if its only installing 0.17 (which is broke) then
> brew update
>
> add
>
>  -DUSE_OCE=ON -DOCE_DIR=/usr/local/opt/oce/OCE.framework/Versions/0.17/
> Resources/
>
> to your cmake line and it will be bundled automatically. Tested on rev
> 38e7deb with no issues.
>
> On Fri, Sep 2, 2016 at 12:13 PM, Chris Pavlina 
> wrote:
> > Okay, this is friggin awesome. I can finally have models of
> > *everything*, it's so nice! :)
> >
> > Sexy PCB shot: https://misc.c4757p.com/12091-motherboard.png
> >
> > Thanks Cirilo!
> >
> > On Thu, Sep 01, 2016 at 04:45:33PM -0400, Wayne Stambaugh wrote:
> >>
> >>
> >> On 9/1/2016 4:18 PM, Chris Pavlina wrote:
> >> > On Thu, Sep 01, 2016 at 04:10:13PM -0400, Wayne Stambaugh wrote:
> >> >> On 9/1/2016 2:29 PM, José Ignacio wrote:
> >> >>> On Thu, Sep 1, 2016 at 12:02 PM, Wayne Stambaugh <
> stambau...@gmail.com> wrote:
> >>  Sorry it took so long.  I took a look at Cirilo's changes an it
> looks
> >>  good.  We still need a PKGBUILD file for msys2 with JPs patch so we
> >>  don't have to build oce from source.
> >> 
> >>  When I merge Cirilo's 3d-plugin branch and I had to create a commit
> >>  message which made me the commit author.  This seems brain dead to
> me.
> >>  Here is the new commit log entry:
> >> 
> >>  commit 12c26047bffd54ccbb88348acfe7f653556450da
> >>  Merge: fcedef8 b656a81
> >>  Author: Wayne Stambaugh 
> >>  Date:   Thu Sep 1 11:59:44 2016 -0400
> >> 
> >>  Merge remote-tracking branch 'cirilo/3d-plugin'
> >> 
> >>  I really only want to show Cirilo's commit log entries as a new
> commit.
> >>  WTF! I'm liking git less every time I use it.  What do I need to
> do to
> >>  get the correct commit history from Cirlo's 3d-plugin branch?
> >> 
> >> >>>
> >> >>> Cirilo's commit history remains intact in the merged branch, you
> just
> >> >>> need to walk through that branch instead of master when reading the
> >> >>> commit logs. If cirilo's branch was rebased to the current master
> you
> >> >>> could do a fast-forward merge, which would graft his commits into
> the
> >> >>> master branch and make his last commit the "new master". In either
> >> >>> case the history is perfectly readable.
> >> >>>
> >> >>
> >> >> Yes but before I got chance to push my branch, Chris pushed a change
> so
> >> >> when I pulled his changes, git conveniently created yet another
> commit
> >> >> message.  Do we really want all this extra cruft in the commit log
> or do
> >> >> we want to rebase against the kicad master?
> >> >
> >> > Start using git pull --rebase like I suggested earlier, it would avoid
> >> > that.
> >> >
> >>
> >> I pushed Cirilo's OCE changes so hopefully I didn't fsck up the main
> >> repo too badly.  Thank you Cirilo for the OCE plugin work.
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://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] libngspice in Homebrew

[Johannes Maibaum]

Hi OSX devs & packagers,

just FYI, the Homebrew maintainers have merged my PR for a
libngspice formula [1].

The formula builds ngspice as shared library, either the current
stable version (26, bottled) or the current HEAD from Sourceforge
git.

It uses the same ./configure arguments as Orson’s ngspice build
script, so it may be used as a direct replacement for OSX devs
working on Kicad.

I have also fixed the bug that the headers don’t get installed to
/usr/local/include/, which Orson had reported upstream [2].


Cheers,
Johannes


[1] https://github.com/Homebrew/homebrew-core/blob/master/Formula/libngspice.rb
[2] https://sourceforge.net/p/ngspice/bugs/327
___
Mailing list: https://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] OCE plugin for 3D viewer

[Simon Wells]

just fyi a couple of tips on OSX

Make sure that brew is installing oce-0.17.2 this was only commited to
brew mid august so if its only installing 0.17 (which is broke) then
brew update

add

 -DUSE_OCE=ON 
-DOCE_DIR=/usr/local/opt/oce/OCE.framework/Versions/0.17/Resources/

to your cmake line and it will be bundled automatically. Tested on rev
38e7deb with no issues.

On Fri, Sep 2, 2016 at 12:13 PM, Chris Pavlina  wrote:
> Okay, this is friggin awesome. I can finally have models of
> *everything*, it's so nice! :)
>
> Sexy PCB shot: https://misc.c4757p.com/12091-motherboard.png
>
> Thanks Cirilo!
>
> On Thu, Sep 01, 2016 at 04:45:33PM -0400, Wayne Stambaugh wrote:
>>
>>
>> On 9/1/2016 4:18 PM, Chris Pavlina wrote:
>> > On Thu, Sep 01, 2016 at 04:10:13PM -0400, Wayne Stambaugh wrote:
>> >> On 9/1/2016 2:29 PM, José Ignacio wrote:
>> >>> On Thu, Sep 1, 2016 at 12:02 PM, Wayne Stambaugh  
>> >>> wrote:
>>  Sorry it took so long.  I took a look at Cirilo's changes an it looks
>>  good.  We still need a PKGBUILD file for msys2 with JPs patch so we
>>  don't have to build oce from source.
>> 
>>  When I merge Cirilo's 3d-plugin branch and I had to create a commit
>>  message which made me the commit author.  This seems brain dead to me.
>>  Here is the new commit log entry:
>> 
>>  commit 12c26047bffd54ccbb88348acfe7f653556450da
>>  Merge: fcedef8 b656a81
>>  Author: Wayne Stambaugh 
>>  Date:   Thu Sep 1 11:59:44 2016 -0400
>> 
>>  Merge remote-tracking branch 'cirilo/3d-plugin'
>> 
>>  I really only want to show Cirilo's commit log entries as a new commit.
>>  WTF! I'm liking git less every time I use it.  What do I need to do to
>>  get the correct commit history from Cirlo's 3d-plugin branch?
>> 
>> >>>
>> >>> Cirilo's commit history remains intact in the merged branch, you just
>> >>> need to walk through that branch instead of master when reading the
>> >>> commit logs. If cirilo's branch was rebased to the current master you
>> >>> could do a fast-forward merge, which would graft his commits into the
>> >>> master branch and make his last commit the "new master". In either
>> >>> case the history is perfectly readable.
>> >>>
>> >>
>> >> Yes but before I got chance to push my branch, Chris pushed a change so
>> >> when I pulled his changes, git conveniently created yet another commit
>> >> message.  Do we really want all this extra cruft in the commit log or do
>> >> we want to rebase against the kicad master?
>> >
>> > Start using git pull --rebase like I suggested earlier, it would avoid
>> > that.
>> >
>>
>> I pushed Cirilo's OCE changes so hopefully I didn't fsck up the main
>> repo too badly.  Thank you Cirilo for the OCE plugin work.
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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