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

[Nick Østergaard]

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

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

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

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

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

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

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

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

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

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

I think this makes sense.

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

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

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

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

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

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

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

> Please let me know what I can do to help this process along.
>
> Regards,
>
> Oliver
>
>
> ___
> Mailing list: 

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

[Nick Østergaard]

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

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

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

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

[Nick Østergaard]

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

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

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

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

[Nick Østergaard]

It seems it has been there for long, there are only few mentions of it
on the list while I have been subscribed, but I find:

https://www.mail-archive.com/kicad-developers@lists.launchpad.net/msg20577.html
https://lists.launchpad.net/kicad-developers/msg20046.html

It does not really mention anything about the intention. But by the
fact that there have been some implementation to support it for a
decade is probably an indicator that someone wanted to support it at
some poiny, but never got the time to finish it.

I hope someone else can comment further on this.

2016-09-13 11:36 GMT+02:00 Tomasz Wlostowski :
> Hi all,
>
> Looking at the sources of the DRAWSEGMENT class (with the hopes of
> refactoring it a bit to enable arbitrary copper shapes), I noticed that
> it supports Bezier curves. They are also supported by the file format
> parser/writer. There's however no drawing tool for these. Is this some
> outdated code that can be removed or do we plan to support Bezier curves
> in PCBnew?
>
> Cheers,
> Tom
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] translation code rework

[Nick Østergaard]

2016-09-09 16:02 GMT+02:00 Wayne Stambaugh <stambau...@gmail.com>:
> On 9/7/2016 2:27 PM, Nick Østergaard wrote:
>> 2016-03-12 1:37 GMT+01:00 Simon Wells <swel...@gmail.com>:
>>> As part of the translation code rework that i am working on (and
>>> auto-detection) part of it is moving the need for changing anything in
>>> code to add a new language. As part of this involves the flags i was
>>> wondering whether anyone would be against moving them into the i18n
>>> repo (and distributed in the individual language folders, so that if
>>> kicad is compiled with having icons enabled in the menu they could
>>> still be used but they will be pulled at runtime so no addtional code
>>> nor icons required in the kicad tree
>>>
>>
>> This discussion seem to be related to the other thread:
>> https://www.mail-archive.com/kicad-developers@lists.launchpad.net/msg17648.html
>>
>> It does not seem anyone is directly against removing the flags all together.
>
> As I stated in the previous thread I'm OK with removing the flags.  I'm
> just concerned about what text we will use in the language menu.
> Translated, English, always the current locale, or something else?  I
> still haven't seen a good solution to that issue.
>

Maybe have it both? Like:

Français (French)

Then you have it "easily readable for the native" and still easy for
others to understand?

I still think it is nice to keep the menu, or at least the
fucntionality. I may not need to be a seperate menu from the top bar
menu as is now, it might actually be more appropiate in "normal"
settings dialogs. I know those are not the same for eeschema and
pcbnew, but maybe more similar in the future. This is just some
ideas/proposals for the future.

>>
>> I like the idea of validating the available languages runtime as
>> mentioned in the related thread.
>
> Makes sense to me.  I see no reason to add entries in the language menu
> for translations that are not available.
>
>>
>>> Something unrelated to the flags but similar is do we need the
>>> translations tab with all the translators in the about box? or would a
>>> better place be in the i18n repo on github and linked from the website
>>> and only the current translation information provided in the about
>>> dialog. This can be pulled at runtime from the po files using the
>>> Language-Team header in the po file. There are a few ways this could
>>> be left how it is, including having a list of all INSTALLED
>>> translations in the translations tab instead of only showing current,
>>> would just require the program at startup processing all the language
>>> files to get the header information.
>>>
>>> for example the one in the ru po file is
>>> "Language-Team: Russian KiCad Translation Team: Andrey Fedorushkov, Eldar "
>>> "Khayrullin, Igor Plyatov <an...@mail.ru>\n"
>>>
>>> As i only know english i haven't had the oppurtunity to use the po
>>> utility but i have been advised this is a setting rather than just
>>> something that is edited manually
>>>
>>> the one in the fr po file is
>>> "Language-Team: jp-charras\n"
>>>
>>> which if this idea is implemented jp might need to change his to be a
>>> bit more informative, (at least being his full name or something)
>>>
>>> I think i have mentioned before about making the language list in
>>> preferences reliant on whether the i18n files have been installed so
>>> that people don't get caught up with wondering why no other languages
>>> work.
>>>
>>
>> Lets assume that all contributors have "proper" names here.
>>
>> What will happen with translators which work might not even be present
>> anymore, how are we supposed to detect that? Or are we just going to
>> count all contributors from epoch?
>>
>>> Mainly i am looking for arguments against moving the flags into the
>>> i18n repo as that may prove that most of my code is not possible.
>>> seeing as some people seem to be against just ditching the flags
>>>
>>
>> Remove the flags. :P
>>
>> I don't know if the languages maybe sould be written in their
>> localized form, maybe?
>>
>>> thanks
>>>
>>> Simon
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kic

Re: [Kicad-developers] [PATCH] Update version string formatting after git migration

[Nick Østergaard]

Den 09/09/2016 20.09 skrev "Wayne Stambaugh" :
>
> Have we come to any consensus on this yet?  I'm not sure the fake bzr
> revision numbers have any meaning.  Git doesn't have any concept of
> linear commits so having a linear number will only make sense when
> building from the master repo.  These numbers will not track upstream
> for anything built from a local repo that has deviated from the main
> repo.

This was also the case for BZR  :)

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

Re: [Kicad-developers] [PATCH] Print layer names in pcbnew

[Nick Østergaard]

I have not tried this patch, but could you be a bit more descriptive of
what this patch do for the user and why?

Den 08/09/2016 17.09 skrev "Ian Roth" :

> This patch allows for printing layer names in pcbnew using a %L formater.
> This is helpful when printing 1 layer per page.
>
> Ian
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] Add KICAD_INSTALL_DEMOS CMake option

[Nick Østergaard]

The proposed patch does not document the option in the devdocs.

2016-09-08 19:15 GMT+02:00 Wayne Stambaugh :
> Anyone object to this?  I don't really have an opinion one way or the
> other since it defaults to the current behavior.  I guess there is a
> reason not to install the demos.  What's one more option at this point. ;)
>
> On 9/8/2016 3:04 AM, José Ignacio Romero wrote:
>>
>> It is ON by default, determines wether to install the bundled demos
>> and examples.
>> ---
>>  CMakeLists.txt | 6 ++
>>  1 file changed, 6 insertions(+)
>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] [PATCH] Add KICAD_INSTALL_DEMOS CMake option

[Nick Østergaard]

What is the reasoning for doing this?

2016-09-08 9:04 GMT+02:00 José Ignacio Romero :
>
> It is ON by default, determines wether to install the bundled demos
> and examples.
> ---
>  CMakeLists.txt | 6 ++
>  1 file changed, 6 insertions(+)
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>

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

Re: [Kicad-developers] translation code rework

[Nick Østergaard]

2016-03-12 1:37 GMT+01:00 Simon Wells :
> As part of the translation code rework that i am working on (and
> auto-detection) part of it is moving the need for changing anything in
> code to add a new language. As part of this involves the flags i was
> wondering whether anyone would be against moving them into the i18n
> repo (and distributed in the individual language folders, so that if
> kicad is compiled with having icons enabled in the menu they could
> still be used but they will be pulled at runtime so no addtional code
> nor icons required in the kicad tree
>

This discussion seem to be related to the other thread:
https://www.mail-archive.com/kicad-developers@lists.launchpad.net/msg17648.html

It does not seem anyone is directly against removing the flags all together.

I like the idea of validating the available languages runtime as
mentioned in the related thread.

> Something unrelated to the flags but similar is do we need the
> translations tab with all the translators in the about box? or would a
> better place be in the i18n repo on github and linked from the website
> and only the current translation information provided in the about
> dialog. This can be pulled at runtime from the po files using the
> Language-Team header in the po file. There are a few ways this could
> be left how it is, including having a list of all INSTALLED
> translations in the translations tab instead of only showing current,
> would just require the program at startup processing all the language
> files to get the header information.
>
> for example the one in the ru po file is
> "Language-Team: Russian KiCad Translation Team: Andrey Fedorushkov, Eldar "
> "Khayrullin, Igor Plyatov \n"
>
> As i only know english i haven't had the oppurtunity to use the po
> utility but i have been advised this is a setting rather than just
> something that is edited manually
>
> the one in the fr po file is
> "Language-Team: jp-charras\n"
>
> which if this idea is implemented jp might need to change his to be a
> bit more informative, (at least being his full name or something)
>
> I think i have mentioned before about making the language list in
> preferences reliant on whether the i18n files have been installed so
> that people don't get caught up with wondering why no other languages
> work.
>

Lets assume that all contributors have "proper" names here.

What will happen with translators which work might not even be present
anymore, how are we supposed to detect that? Or are we just going to
count all contributors from epoch?

> Mainly i am looking for arguments against moving the flags into the
> i18n repo as that may prove that most of my code is not possible.
> seeing as some people seem to be against just ditching the flags
>

Remove the flags. :P

I don't know if the languages maybe sould be written in their
localized form, maybe?

> 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

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

[Nick Østergaard]

FYI the windows nightlies now built with OCE enabled. The first
nightlies are ready and my sanity check says that it works. As I write
this only the x86_64 build have it enabled, but I expect the i686
build to be ready within a few hours from now on.

I know that js-reynaud also enabled it on the ubunut PPA's.

I don't know what the status for getting OSX nightlies running again is.

So all in all this is good news. Lets see if we get any new bug
reports on its usage now. :)

Cirilo and Mario (and others), thank you for making this feature a reality.

2016-09-03 2:18 GMT+02:00 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


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

Re: [Kicad-developers] [PATCH] A few small changes to CMake and the compiling instructions

[Nick Østergaard]

I have attached a new patch that should apply cleanly.

2016-09-05 1:17 GMT+02:00 Wayne Stambaugh <stambau...@gmail.com>:
> Nick,
>
> Your patch 1 did not apply against Jon's changes to compiling.md.
> Please rebase and send me the new patch when you get a chance.
>
> Thanks,
>
> Wayne
>
> On 9/3/2016 5:05 PM, Nick Østergaard wrote:
>> I also prepared some patches to address this issue with the switch,
>> but I did not submit them, because no one commented further on it.
>>
>> But for the git descriptions, why do you suggest "-b master" for the
>> git clone, that should not be necessary.
>>
>> My patches replaces the 0001 patch of Jon's, they also add the
>> preprocessor define and adds it to the version information. Also it
>> adds a description for the new eeschema IO manager stuff. Please
>> reveiw the description I made.
>>
>> 2016-09-03 22:28 GMT+02:00 Jon Neal <reporting...@gmail.com>:
>>> 0001 changes the USE_OCE flag to KICAD_USE_OCE as discussed.
>>> 0002 adds libngspice and OCE to the INSTALL.txt dependencies list and
>>> removes a dead link
>>> 0003 updates compiling.md to remove bzr references and adds info about the
>>> KICAD_USE_OCE flag
>>>
>>> Jon
>>>
>>> ___
>>> Mailing list: https://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


0001-Add-KICAD_-prefix-to-build-switches_v2.patch
Description: plain/text
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] A few small changes to CMake and the compiling instructions

[Nick Østergaard]

Yes

2016-09-04 23:01 GMT+02:00 Wayne Stambaugh <stambau...@gmail.com>:
> So I have this straight:
>
> John's 0002 and 0003 patches
> Nick's 0001, 0002, and 0003 patches
>
> Is this correct?
>
> On 9/3/2016 5:09 PM, Nick Østergaard wrote:
>> I just made my changes in multiple patches such that they are easy to
>> review, they should probably be squashed with the commit description
>> if committed.
>>
>> 2016-09-03 23:05 GMT+02:00 Nick Østergaard <oe.n...@gmail.com>:
>>> I also prepared some patches to address this issue with the switch,
>>> but I did not submit them, because no one commented further on it.
>>>
>>> But for the git descriptions, why do you suggest "-b master" for the
>>> git clone, that should not be necessary.
>>>
>>> My patches replaces the 0001 patch of Jon's, they also add the
>>> preprocessor define and adds it to the version information. Also it
>>> adds a description for the new eeschema IO manager stuff. Please
>>> reveiw the description I made.
>>>
>>> 2016-09-03 22:28 GMT+02:00 Jon Neal <reporting...@gmail.com>:
>>>> 0001 changes the USE_OCE flag to KICAD_USE_OCE as discussed.
>>>> 0002 adds libngspice and OCE to the INSTALL.txt dependencies list and
>>>> removes a dead link
>>>> 0003 updates compiling.md to remove bzr references and adds info about the
>>>> KICAD_USE_OCE flag
>>>>
>>>> Jon
>>>>
>>>> ___
>>>> Mailing list: https://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

[Nick Østergaard]

I guess using the USE_WX_OVERLAY is more descriptive than just a
platform like OSX in this case.

2016-09-04 21:21 GMT+02:00 Wayne Stambaugh <stambau...@gmail.com>:
> Is there ever a reason to build OSX with USE_WX_OVERLAY=OFF or any other
> platform with USE_WX_OVERLAY=ON?  If not, maybe we should replace #if
> USE_WX_OVERLAY with #if OSX (or whatever it should be).
>
> On 9/4/2016 3:18 PM, Simon Wells wrote:
>> i am pretty sure one of them at least is used on osx as its the
>> default set in cmake on osx
>>
>> On Mon, Sep 5, 2016 at 7:15 AM, Wayne Stambaugh <stambau...@gmail.com> wrote:
>>> On 9/3/2016 6:49 AM, Nick Østergaard wrote:
>>>> 2016-09-01 19:02 GMT+02:00 Wayne Stambaugh <stambau...@gmail.com>:
>>>>> 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 <stambau...@gmail.com>
>>>>> 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?
>>>>>
>>>>> On 9/1/2016 7:35 AM, Nick Østergaard wrote:
>>>>>> I would also like to see this merged (I have only tested the out of
>>>>>> tree plugin), but I suggest that the build switch is named something
>>>>>> prefixed with "KICAD_" like most other kicad specific build switches
>>>>>> are, except for the github plugin.  Maybe KICAD_USE_OCE.
>>>>>
>>>>> For the sake of consistency, we probably should prefix everything with
>>>>> KICAD_.  I always liked the autotools --with- and --enable- prefixes for
>>>>> config options.  There is no consistency as far as cmake goes.  CMake
>>>>> should have adopted a standard prefix naming convention for options.
>>>>>
>>>>>>
>>>>>> And to that I will add that Documentation/development/compiling.md
>>>>>> should be updated too to reflect the usage for that compile switch, :)
>>>>>
>>>>> Yes, we need to be keeping these up to date.
>>>>>
>>>>
>>>> So would a patch to change USE_OCE to KICAD_USE_OCE with description
>>>> be accepted?
>>>>
>>>> Aslo, I note that the recently introduced option USE_SCH_IO_MANAGER is
>>>> also missing a prefix and it not decribed in compiling.md either.
>>>> Should that be changed too?
>>>
>>> I may change it since I'm guessing none of the packages are be built
>>> with it enabled and that only myself and a few brave testers are
>>> probably the only ones using it.  Please keep in mind, this will be
>>> removed once the schematic I/O plugin manager is the default.
>>>
>>>>
>>>> There are also USE_WX_GRAPHICS_CONTEXT and USE_WX_OVERLAY, but I think
>>>> I will ignore those two.
>>>
>>> These have been around for a long time.  I doubt USE_WX_GRAPHICS_CONTEXT
>>> even builds anymore.  Is USE_WX_OVERLAY still used by the OSX folks?
>>> Maybe we can just get rid of them.
>>>
>>>>
>>>>>>
>>>>>> Nick
>>>>>>
>>>>>> 2016-09-01 11:39 GMT+02:00 Tomasz Wlostowski <tomasz.wlostow...@cern.ch>:
>>>>>>> On 01.09.2016 10:30, Cirilo Bernardo wrote:
>>>>>>>> Just a ping to remind devs of a branch introducing the OCE plugin:
>>>>>>>>
>>>>>>>> https://code.launchpad.net/~cirilo-bernardo/kicad/+git/kicad-oce/+merge/303513
>>>>>>>>
>>>>>>>> Since the OCE plugin code must be activated with -DUSE_OCE=ON
>>>>>>>> when configuring with CMake, I think it's safe to include this code. 

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

[Nick Østergaard]

2016-09-04 21:15 GMT+02:00 Wayne Stambaugh <stambau...@gmail.com>:
> On 9/3/2016 6:49 AM, Nick Østergaard wrote:
>> 2016-09-01 19:02 GMT+02:00 Wayne Stambaugh <stambau...@gmail.com>:
>>> 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 <stambau...@gmail.com>
>>> 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?
>>>
>>> On 9/1/2016 7:35 AM, Nick Østergaard wrote:
>>>> I would also like to see this merged (I have only tested the out of
>>>> tree plugin), but I suggest that the build switch is named something
>>>> prefixed with "KICAD_" like most other kicad specific build switches
>>>> are, except for the github plugin.  Maybe KICAD_USE_OCE.
>>>
>>> For the sake of consistency, we probably should prefix everything with
>>> KICAD_.  I always liked the autotools --with- and --enable- prefixes for
>>> config options.  There is no consistency as far as cmake goes.  CMake
>>> should have adopted a standard prefix naming convention for options.
>>>
>>>>
>>>> And to that I will add that Documentation/development/compiling.md
>>>> should be updated too to reflect the usage for that compile switch, :)
>>>
>>> Yes, we need to be keeping these up to date.
>>>
>>
>> So would a patch to change USE_OCE to KICAD_USE_OCE with description
>> be accepted?
>>
>> Aslo, I note that the recently introduced option USE_SCH_IO_MANAGER is
>> also missing a prefix and it not decribed in compiling.md either.
>> Should that be changed too?
>
> I may change it since I'm guessing none of the packages are be built
> with it enabled and that only myself and a few brave testers are
> probably the only ones using it.  Please keep in mind, this will be
> removed once the schematic I/O plugin manager is the default.
>

Even though it might be removed soon I still think it is good practice
to document it for consistensy.  Also, I made a patch to add the
prefix to that switch too if that is what you ask. Anyways, "soon" in
a KiCad sense is still a long time in real time.

>>
>> There are also USE_WX_GRAPHICS_CONTEXT and USE_WX_OVERLAY, but I think
>> I will ignore those two.
>
> These have been around for a long time.  I doubt USE_WX_GRAPHICS_CONTEXT
> even builds anymore.  Is USE_WX_OVERLAY still used by the OSX folks?
> Maybe we can just get rid of them.
>
>>
>>>>
>>>> Nick
>>>>
>>>> 2016-09-01 11:39 GMT+02:00 Tomasz Wlostowski <tomasz.wlostow...@cern.ch>:
>>>>> On 01.09.2016 10:30, Cirilo Bernardo wrote:
>>>>>> Just a ping to remind devs of a branch introducing the OCE plugin:
>>>>>>
>>>>>> https://code.launchpad.net/~cirilo-bernardo/kicad/+git/kicad-oce/+merge/303513
>>>>>>
>>>>>> Since the OCE plugin code must be activated with -DUSE_OCE=ON
>>>>>> when configuring with CMake, I think it's safe to include this code. 
>>>>>> Having
>>>>>> the code in the main base will make it easier for other volunteers to 
>>>>>> help
>>>>>> sort out build and deployment issues of the OCE plugin on Windows and
>>>>>> OSX.
>>>>>
>>>>> Hi Cirilo,
>>>>>
>>>>> I fully agree to merge the OCE plug-in code. Users have been desperately
>>>>> asking for ages for STEP & IGES support in the 3d-viewer ;-)
>>>>>
>>>>> @Wayne/@Orson: since this is optional, are there any obstacles for the
>>>>> merge?
>>>>>
>>>>> Cheers,
>>>>> Tom
>>>>>
>>>>> ___
>>>>> Mailing list: https://laun

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

[Nick Østergaard]

2016-09-02 23:05 GMT+02:00 Nick Østergaard <oe.n...@gmail.com>:
> 2016-09-02 23:00 GMT+02:00 Wayne Stambaugh <stambau...@gmail.com>:
>> On 9/2/2016 4:28 PM, Nick Østergaard wrote:
>>> 2016-09-02 21:25 GMT+02:00 Wayne Stambaugh <stambau...@gmail.com>:
>>>> 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.

My pull request for oce have been merged. I guess it is only a matter
of time before there will be prebuild packages for it.

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

Re: [Kicad-developers] [PATCH] A few small changes to CMake and the compiling instructions

[Nick Østergaard]

I just made my changes in multiple patches such that they are easy to
review, they should probably be squashed with the commit description
if committed.

2016-09-03 23:05 GMT+02:00 Nick Østergaard <oe.n...@gmail.com>:
> I also prepared some patches to address this issue with the switch,
> but I did not submit them, because no one commented further on it.
>
> But for the git descriptions, why do you suggest "-b master" for the
> git clone, that should not be necessary.
>
> My patches replaces the 0001 patch of Jon's, they also add the
> preprocessor define and adds it to the version information. Also it
> adds a description for the new eeschema IO manager stuff. Please
> reveiw the description I made.
>
> 2016-09-03 22:28 GMT+02:00 Jon Neal <reporting...@gmail.com>:
>> 0001 changes the USE_OCE flag to KICAD_USE_OCE as discussed.
>> 0002 adds libngspice and OCE to the INSTALL.txt dependencies list and
>> removes a dead link
>> 0003 updates compiling.md to remove bzr references and adds info about the
>> KICAD_USE_OCE flag
>>
>> Jon
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>

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

Re: [Kicad-developers] [PATCH] A few small changes to CMake and the compiling instructions

[Nick Østergaard]

I also prepared some patches to address this issue with the switch,
but I did not submit them, because no one commented further on it.

But for the git descriptions, why do you suggest "-b master" for the
git clone, that should not be necessary.

My patches replaces the 0001 patch of Jon's, they also add the
preprocessor define and adds it to the version information. Also it
adds a description for the new eeschema IO manager stuff. Please
reveiw the description I made.

2016-09-03 22:28 GMT+02:00 Jon Neal :
> 0001 changes the USE_OCE flag to KICAD_USE_OCE as discussed.
> 0002 adds libngspice and OCE to the INSTALL.txt dependencies list and
> removes a dead link
> 0003 updates compiling.md to remove bzr references and adds info about the
> KICAD_USE_OCE flag
>
> Jon
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>


0001-Add-KICAD_-prefix-to-build-switches.patch
Description: plain/text


0002-Add-new-development-build-swtiches-to-version-info.patch
Description: plain/text


0003-Remove-unused-version-info.patch
Description: plain/text
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

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

[Nick Østergaard]

2016-09-01 19:02 GMT+02:00 Wayne Stambaugh <stambau...@gmail.com>:
> 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 <stambau...@gmail.com>
> 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?
>
> On 9/1/2016 7:35 AM, Nick Østergaard wrote:
>> I would also like to see this merged (I have only tested the out of
>> tree plugin), but I suggest that the build switch is named something
>> prefixed with "KICAD_" like most other kicad specific build switches
>> are, except for the github plugin.  Maybe KICAD_USE_OCE.
>
> For the sake of consistency, we probably should prefix everything with
> KICAD_.  I always liked the autotools --with- and --enable- prefixes for
> config options.  There is no consistency as far as cmake goes.  CMake
> should have adopted a standard prefix naming convention for options.
>
>>
>> And to that I will add that Documentation/development/compiling.md
>> should be updated too to reflect the usage for that compile switch, :)
>
> Yes, we need to be keeping these up to date.
>

So would a patch to change USE_OCE to KICAD_USE_OCE with description
be accepted?

Aslo, I note that the recently introduced option USE_SCH_IO_MANAGER is
also missing a prefix and it not decribed in compiling.md either.
Should that be changed too?

There are also USE_WX_GRAPHICS_CONTEXT and USE_WX_OVERLAY, but I think
I will ignore those two.

>>
>> Nick
>>
>> 2016-09-01 11:39 GMT+02:00 Tomasz Wlostowski <tomasz.wlostow...@cern.ch>:
>>> On 01.09.2016 10:30, Cirilo Bernardo wrote:
>>>> Just a ping to remind devs of a branch introducing the OCE plugin:
>>>>
>>>> https://code.launchpad.net/~cirilo-bernardo/kicad/+git/kicad-oce/+merge/303513
>>>>
>>>> Since the OCE plugin code must be activated with -DUSE_OCE=ON
>>>> when configuring with CMake, I think it's safe to include this code. Having
>>>> the code in the main base will make it easier for other volunteers to help
>>>> sort out build and deployment issues of the OCE plugin on Windows and
>>>> OSX.
>>>
>>> Hi Cirilo,
>>>
>>> I fully agree to merge the OCE plug-in code. Users have been desperately
>>> asking for ages for STEP & IGES support in the 3d-viewer ;-)
>>>
>>> @Wayne/@Orson: since this is optional, are there any obstacles for the
>>> merge?
>>>
>>> Cheers,
>>> Tom
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
> ___
> Mailing list: https://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] Stable release 5 road map.

[Nick Østergaard]

A small paragraph ahve been added to the getting started section
describing the v5 and CERN road map.

2016-07-07 9:33 GMT+02:00 Wayne Stambaugh :
> On 7/6/2016 1:38 PM, Jon Neal wrote:
>> It took me a solid 15 minutes of searching to find the roadmap, so
>> hopefully I'll do someone a favor and provide a link
>> here: 
>> http://ci.kicad-pcb.org/job/kicad-doxygen/ws/Documentation/doxygen/html/v5_road_map.html
>
> It's probably not obvious that the road map is part of the developer
> docs.  Would one of our fearless website devs add a link to the version
> 5 road map in the developers page?
>
> Thanks,
>
> Wayne
>
>>
>> On Tue, Jul 5, 2016 at 6:07 PM Cirilo Bernardo
>> > wrote:
>>
>> Hi Wayne,
>>
>>  Thanks for the heads up on where to find the roadmap; I'll have a good
>> look through it.
>>
>>  Getting an MCAD plugin before FOSDEM would be challenging. I could
>> shoehorn yet another exporter in a matter of days but a working plugin
>> system would require some thought on how to expose some of pcbnew's
>> internal data to a DLL. I have a working external tool based on OCE
>> and it works ok for exporting STEP assemblies but there's something
>> wrong with my IGES export - but that's OK since STEP is the better
>> model to use. OCE itself is happy to read IGES files and write them to
>> a STEP assembly, it's only my IGES export which doesn't work.
>>
>> - Cirilo
>>
>> On Tue, Jul 5, 2016 at 6:13 PM, Wayne Stambaugh
>> > wrote:
>>
>> Funny you should ask Cirilo since your name came up about the 3D
>> model
>> plugins.  The current road map version 5 is published as part of the
>> developer documentation which is available on the KiCad
>> website.  In the
>> road map there is mention of support for exporting to STEP
>> and/or IGES.
>> Any chance that you could provide a plugin for either one of
>> these or
>> both by FOSDEM 2017?  It would be a nice feature for users to
>> directly
>> export boards and footprint models to a format that can be used
>> directly
>> by FreeCAD and less than free CAD tools for mechanical design.
>> Maybe
>> you could get some help from Mario and Maurice.  If you don't
>> think this
>> is possible, please let me know so I can update the road map.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 7/5/2016 4:07 AM, Cirilo Bernardo wrote:
>> > Is there a pre-commit version somewhere where we can see what's
>> > on the roadmap?
>> >
>> > I want to work on a PCB API so that pcbnew importers/exporters
>> > can be turned into plugins and I can add an MCAD exporter, but
>> > given my free time and the size of the job I wouldn't expect it to
>> > be ready for FOSDEM 2017.
>> >
>> > - Cirilo
>> >
>> > On Tue, Jul 5, 2016 at 5:55 PM, Wayne Stambaugh 
>> 
>> > >> wrote:
>> >
>> > I spent much of yesterday discussing and finalizing the stable 
>> version 5
>> > road map with everyone here at CERN.  I will be committing the 
>> revised
>> > road map soon.  Before I do, I want to make sure no one is 
>> working on
>> > anything outside the road map that I do not know about.  If 
>> you are
>> > working on new features that are not in the version 5 road 
>> map, please
>> > inform me of what you working on and whether or not it will be 
>> ready to
>> > release by FOSDEM 2017.  If it will not be ready by then, 
>> please do not
>> > commit it to the product branch and keep your changes in you 
>> own
>> > development branch until after I create the stable release 5 
>> branch on
>> > launchpad.
>> >
>> > 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
>> >
>> >
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> 

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

[Nick Østergaard]

2016-09-02 23:05 GMT+02:00 Nick Østergaard <oe.n...@gmail.com>:
> 2016-09-02 23:00 GMT+02:00 Wayne Stambaugh <stambau...@gmail.com>:
>> On 9/2/2016 4:28 PM, Nick Østergaard wrote:
>>> 2016-09-02 21:25 GMT+02:00 Wayne Stambaugh <stambau...@gmail.com>:
>>>> 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 KiCa

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

[Nick Østergaard]

2016-09-02 23:00 GMT+02:00 Wayne Stambaugh <stambau...@gmail.com>:
> On 9/2/2016 4:28 PM, Nick Østergaard wrote:
>> 2016-09-02 21:25 GMT+02:00 Wayne Stambaugh <stambau...@gmail.com>:
>>> 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 <swel...@gmail.com
>>>> <mailto:swel...@gmail.com>> 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/oc

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, 

Re: [Kicad-developers] Git transition

[Nick Østergaard]

I think the mirror should be working again now, we will see when
something is pushed to lp.

2016-08-25 7:40 GMT+02:00 Nick Østergaard <oe.n...@gmail.com>:
> I will try to make the mirror be synced from launchpad, at latest on friday.
>
> 2016-08-24 5:39 GMT+02:00 kinichiro inoguchi <kinichiro.inogu...@gmail.com>:
>> Hi,
>>
>> I hope mirror on GitHub keeps refreshing from new git repo on Launchpad.
>> https://github.com/KiCad/kicad-source-mirror
>>
>> For GUI translators task,
>> we need to download source code tarball to obtain strings in the GUI.
>>
>> On GitHub, we could download every committed rev as tarball by one click.
>> On Launchpad, it seems that only tagged rev can be downloaded.
>>
>> If POT file for GUI is provided for every commits, maybe, GUI translators do
>> not need to access mirror, though.
>>
>> Best regards
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>

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

Re: [Kicad-developers] Stable release 4.0.4

[Nick Østergaard]

Hi Wayne

Is there any reason that the folder inside the release tarball is
named kicad-4.0 instead of kicad-4.0.4 in line with the previous
releases?

Nick

2016-08-30 3:16 GMT+02:00 Wayne Stambaugh :
> I just finished getting everything updated for the 4.0.4 release.
> Thanks to everyone who made this possible.  I know there were not many
> changes from 4.0.3 but they were critical so I needed to get this out.
>
> 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

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

Re: [Kicad-developers] git stable mirror

[Nick Østergaard]

FYI, I don't think I will manage to get the github mirror going before
medio next week.

2016-07-05 18:41 GMT+02:00 Wayne Stambaugh :
> I'm OK with this.  I just was on github and I didn't see any way to pull
> from a different repo in the add new repo section of github.  Would the
> person (I think it was Miguel) who set this up for the product branch
> please create a mirror on github for the stable 4 branch?
>
> Thanks,
>
> Wayne
>
> On 7/5/2016 12:20 PM, Michael Steinberg wrote:
>> Hey,
>>
>> would it be possible to add the stable branch to the git mirror as well?
>> That would make my work much easier. Take this as a wishlist-item ;)
>>
>> Michael
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] Git transition

[Nick Østergaard]

I will try to make the mirror be synced from launchpad, at latest on friday.

2016-08-24 5:39 GMT+02:00 kinichiro inoguchi :
> Hi,
>
> I hope mirror on GitHub keeps refreshing from new git repo on Launchpad.
> https://github.com/KiCad/kicad-source-mirror
>
> For GUI translators task,
> we need to download source code tarball to obtain strings in the GUI.
>
> On GitHub, we could download every committed rev as tarball by one click.
> On Launchpad, it seems that only tagged rev can be downloaded.
>
> If POT file for GUI is provided for every commits, maybe, GUI translators do
> not need to access mirror, though.
>
> Best regards
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>

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

Re: [Kicad-developers] Git transition

[Nick Østergaard]

I don't like that your "stable-4" branch don't match the 4.0 branch in
the kicad-source mirror.
See:
https://git.launchpad.net/~stambaughw/kicad/+git/kicad-dev/commit/?h=stable-4=7ced0635031e2dcf7ec34db598726f0887da2cc5
https://github.com/KiCad/kicad-source-mirror/commit/bcdcaa724d1097bffd3654220ed549363fac8059

I think it would be better off if we could use the 4.0 branch from the
kicad-source-mirror to base it on, and name the branch 4.0 as it was
named before and everywhere else.

Why did you suddenly start to name the banch "stable-"

2016-08-23 19:39 GMT+02:00 Wayne Stambaugh :
> Thanks everyone for taking a look at this.  I just pushed the stable-4
> branch to lp:kicad so we should be synced up.  I'll tag the bzr stable 4
> repo as obsolete when I get a chance.
>
> On 8/23/2016 1:13 PM, kinichiro inoguchi wrote:
>>> Can someone please take a look at it you get a chance and make sure I
>>> didn't make a mess of things before I push this to the main repo.
>>
>> Hi,
>>
>> I compared the new git stable-4 repository and old bzr lp:kicad/4.0.
>>   https://git.launchpad.net/~stambaughw/kicad/+git/kicad-dev
>>   https://code.launchpad.net/~stambaughw/kicad/4.0
>>
>> 1. empty directory packaging/linux/ is missing
>>
>>   I checked contents by $ diff -rq lp_kicad_4/ git_stable4/ .
>>   Is this directory needed ?
>>
>> 2. difference of commit logs
>>
>>   On lp_kicad_4, lines of logs are 6308.
>>   $ bzr log --line | wc -l
>>   6308
>>
>>   On git_stable4, 8181 logs exists.
>>   $ git log --oneline | wc -l
>>   8181
>>
>>   To see diffs, I created the log texts by these commands.
>>
>>   On lp_kicad_4,
>>   $ bzr log --line | sed 's/^[0-9]*: .*
>> [0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9] //' \
>> | sed 's/^{.*} //' > ../bzr.txt
>>
>>   On git_stable4,
>>   $ git log --oneline | sed 's/^[a-zA-Z0-9]* //' > ../git.txt
>>
>>   Then look at the diffs,
>>   $ diff -y bzr.txt git.txt | less
>>
>>   For example, diffs are like this.
>>   
>> 
>>   ...
>>   Pcbnew: fix potential issue (crash) when loading board filesPcbnew: fix
>>   [merge] OSX: back port touchpad support from development bran | OSX: back 
>> po
>> > Fix 
>> 3d-viewe
>> > Fix 
>> touchpad
>> > Add support
>>   OSX: legacy canvas rendering speed improvements.OSX: legacy
>>   ...
>>   
>> 
>>
>>   This diff referes to revno 6291.
>>   It seems that git displays all the commit logs in 1 merge of bzr.
>>   http://bazaar.launchpad.net/~stambaughw/kicad/4.0/revision/6291
>>
>>   I think these diffs of commit logs are not problem.
>>
>>
>> After all, I think new git stable4 branch is right.
>> And, thanks for all of your hard works.
>>
>> ___
>> Mailing list: https://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] Couple raytracer "problems"/questions

[Nick Østergaard]

Den 23/08/2016 04.43 skrev "Chris Pavlina" :
>
> Mostly asking Mário here - couple slight issues/questions with the
> raytracer..
>
> https://misc.c4757p.com/raytrace-example.png
>
> 1) Am I the only one getting missing chunks in the corner like that?
> That happens very often for me.
>

I see the same issues often. I have reported it to Mario a long time ago,
but I am not sure he can easily reproduce the problem. Maybe he has some
ideas for stuff to poke with the debugger to investigate the issue.

> 2) Any necessary reason why it's so grainy?
>
>

I think it is primarily related to the postprocessing step. Try to disable
that. It creates the shadows and that grainy noise also, IIRC.

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

[Nick Østergaard]

Feel free to procrastinate the announcement.

Since it seems we will reuse the 4.0.3 doc, lib and i18n but I they have
not been retagged yet, it is ok to delay it half a day.  Alternately you
could make the announcement a draft and I can publish it when ready.

Den 22/08/2016 17.46 skrev "Wayne Stambaugh" :

> I just tagged 4.0.4 so technically you can start creating packages
> against it.  I'm not sure of the status of the doc, lib, and translation
> repos.  I will try to make the announcement before I go out of town for
> the weekend but I cannot promise that it will happen.
>
> On 8/22/2016 10:50 AM, Adam Wolf wrote:
> > This package dev is fine with you waiting a few days for 4.0.4, but
> > let's not stretch out much more than that.
> >
> > On Mon, Aug 22, 2016 at 9:21 AM, Chris Pavlina  > > wrote:
> >
> > On Mon, Aug 22, 2016 at 09:57:26AM -0400, Wayne Stambaugh wrote:
> > > On 8/22/2016 9:53 AM, Clemens Koller wrote:
> > > > Hi, Wayne!
> > > >
> > > > On 2016-08-22 14:09, Wayne Stambaugh wrote:
> > > >> I wasn't planning on migrating the stable 4 branch to git.  I'm
> hoping
> > > >> there wont be too many more 4 stable releases so I'm not sure
> it's worth
> > > >> the effort.
> > > >
> > > > Ok, I was wondering...
> > > > I was missing the stable branch, too - as well as all the tags
> of the old
> > > > releases, etc. I personally don't need them, but it could be
> useful
> > > > and interesting to get all former references (r6994, rev 6994,
> 4.0.0-rc...)
> > > > migrated over to the git side once.
> > >
> > > My one gripe about git is the commit hash tags.  They really are
> not
> > > very user friendly.  The tags you mention above are all in 4 stable
> > > branch so if you continue to use bzr for the stable 4 branch, you
> should
> > > not have any issues.  I will tag future stable versions in git
> when we
> > > get to that point so you will be able to use git tags in the same
> > > manner.  I'm not sure how maintaining a stable branch in git is
> going to
> > > work.  I'm guessing that it will be a completely separate repo
> like we
> > > do with bzr but I'm going to worry about that when the time comes.
> >
> > As for the hashes not being user-friendly...well, that's what tags
> are
> > for! Commits aren't really sequential anyway, since you can do all
> sorts
> > of weird stuff with branching and merging, so bzr's sequential
> numbers
> > do start to fall apart once you do that. When you have code you
> think is
> > ready for public release, tag it!
> >
> > We could even do a 'testing' series, where we move commits from devel
> > that are mostly okay, and tag a testing 'release' roughly weekly or
> so
> > with a simple incrementing version number - this would be a nice
> middle
> > ground between stable, which honestly starts to get a bit stale, and
> > devel which occasionally breaks.
> >
> > This could even then be used as a staging ground for things to be
> > brought into the stable branch, allowing a somewhat smoother release
> > cadence.
> >
> > Pardon me, I'm just daydreaming a bit... :)
> >
> > >
> > > >
> > > > Regards,
> > > >
> > > > Clemens
> > > >
> > > > ___
> > > > Mailing list: https://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] Git transition

[Nick Østergaard]

FYI the guy syncing bzr to the kicad-source-mirror managed to make it work.
Although it seems like he only pushed the 4.0 branch once. There is a 4.0
branch in that. (Sorry I don't remember his name exactly now)

Den 22/08/2016 16.34 skrev "Chris Pavlina" :

> I'm used to git repo surgery enough to make the branch - if nobody else
> does it before I get out of work tonight, I'll do it then.
>
> As Shane says it should be very easy though, assuming there's nothing
> funny going on.
>
> On Mon, Aug 22, 2016 at 10:26:46AM -0400, Shane Burrell wrote:
> > It should be really easy.  Create a branch and overlay stable 4 branch
> via
> > manual or checkout the hash mark you need and commit to branch.  I
> > typically do a develop branch (bleeding edge) and branch of stable
> without
> > any issues and created stable in same fashion the first time.
> >
> > On Mon, Aug 22, 2016 at 10:20 AM, Wayne Stambaugh 
> > wrote:
> >
> > > On 8/22/2016 10:13 AM, Chris Pavlina wrote:
> > > > On Mon, Aug 22, 2016 at 09:57:26AM -0400, Wayne Stambaugh wrote:
> > > >> On 8/22/2016 9:53 AM, Clemens Koller wrote:
> > > >>> Hi, Wayne!
> > > >>>
> > > >>> On 2016-08-22 14:09, Wayne Stambaugh wrote:
> > >  I wasn't planning on migrating the stable 4 branch to git.  I'm
> hoping
> > >  there wont be too many more 4 stable releases so I'm not sure it's
> > > worth
> > >  the effort.
> > > >>>
> > > >>> Ok, I was wondering...
> > > >>> I was missing the stable branch, too - as well as all the tags of
> the
> > > old
> > > >>> releases, etc. I personally don't need them, but it could be useful
> > > >>> and interesting to get all former references (r6994, rev 6994,
> > > 4.0.0-rc...)
> > > >>> migrated over to the git side once.
> > > >>
> > > >> My one gripe about git is the commit hash tags.  They really are not
> > > >> very user friendly.  The tags you mention above are all in 4 stable
> > > >> branch so if you continue to use bzr for the stable 4 branch, you
> should
> > > >> not have any issues.  I will tag future stable versions in git when
> we
> > > >> get to that point so you will be able to use git tags in the same
> > > >> manner.  I'm not sure how maintaining a stable branch in git is
> going to
> > > >> work.  I'm guessing that it will be a completely separate repo like
> we
> > > >> do with bzr but I'm going to worry about that when the time comes.
> > > >
> > > > Personally I would do a stable branch as a literal branch in git
> rather
> > > > than a repository. This makes it much easier to move code between the
> > > > branches - when you want to pull a commit onto stable, just 'git
> > > > checkout stable' and 'git cherry-pick 1234567'. Makes it easy for
> > > > developers to switch between them, as well - I would very much
> > > > appreciate stable being a proper branch as it would make developing
> > > > fixes on stable and forward-porting them to devel, as you said we
> > > > should, much simpler.
> > > >
> > > > I suspect most developers familiar with git will be strongly in
> favor of
> > > > this - it's how branches are meant to work in git. Fairly standard
> > > > workflow.
> > > >
> > > > Then just use tags to mark releases in the stable branch.
> > > >
> > > > Easy as pie. :)
> > >
> > > For future stable releases, this is fine but I don't think there is any
> > > easy way to reassemble the separate bzr stable 4 branch into a git
> > > branch that we could commit to the main development repo.  If someone
> > > knows of an easy way to do this or better yet actually creates the
> > > branch, I would be more that happy to start using git to track the
> > > stable 4 branch.
> > >
> > > >
> > > >>
> > > >>>
> > > >>> Regards,
> > > >>>
> > > >>> Clemens
> > > >>>
> > > >>> ___
> > > >>> Mailing list: https://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] Git transition

[Nick Østergaard]

2016-08-21 20:26 GMT+02:00 Chris Pavlina :
> On Sun, Aug 21, 2016 at 11:30:11AM -0400, Wayne Stambaugh wrote:
>> > [snip]
>>
>> To all my developers with commit access, please do not commit any
>> changes to the product branch until further notice.  I am going to
>> attempt to switch the project over to use git as the default vcs
>> sometime later today and I don't want to have to resync from bzr to git
>> during this transition.  I have no idea what issues I will run into so
>> please be patient.  Hopefully things will go smoothly.  I will make the
>> announcement once the git repo is online.  @Orson, since you are the one
>> who drove this, I'm giving you the honor of being the goto guy in case
>> things go side ways.  I just thought you should know. :).
>
> It's like Christmas!! :O
>

Yeah, except there is no powder snow to roll around in because of pure
happiness! (at least not where I am located)

>>
>> 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
>
> ___
> Mailing list: https://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] update on STEP visualization

[Nick Østergaard]

I can provide that, but first I am trying to get OCE merged, I already
made a merge request. But it seems that one more fix needs to be
included, which I will try to do very soon.

2016-08-16 1:12 GMT+02:00 Wayne Stambaugh <stambau...@gmail.com>:
> Thanks for clearing that up.  It wasn't clear to me what he was asking
> or what he was trying to convey.  As for windows support, it is
> desirable to create a PKGBUILD file for the oce library and submit to
> the msys2 project.  The msys2 project is very good about accepting
> PKGBUILDs.  This works for both our package devs and devs who build from
> source (me).
>
> On 8/15/2016 6:21 PM, Nick Østergaard wrote:
>> He is not talking about STEP export, only the visualization plugin. And
>> the question as I understand it is to make sure it works on all
>> supported platforms and being packaged with kicad.  I intend to add it
>> to the windows installer soon.
>>
>>
>> Den 15/08/2016 19.55 skrev "Wayne Stambaugh" <stambau...@gmail.com
>> <mailto:stambau...@gmail.com>>:
>>
>> Cirilo,
>>
>> I'm not sure what you are asking.  Ideally, any conversion tool such as
>> STEP would be part of Pcbnew where a simple export->step menu entry
>> would be available.  Users generally prefer this to running and external
>> tool.  What is the end goal of this?
>>
>> Cheers,
>>
>> Wayne
>>
>> On 8/14/2016 11:45 PM, Cirilo Bernardo wrote:
>> > Hi Folks,
>> >
>> >  Thanks mostly to nickoe we have been able to build the
>> > OCE-based 3D plugin for visualization of STEP (and IGES) files on
>> > Windows. I believe that regardless of the availability of some form
>> > of OCE on Windows, it is best if we distribute a known good version
>> > of OCE which has been built with gcc.
>> >
>> >  Back in May I also received some tips on building the plugin for
>> > OSX: https://github.com/cbernardo/kicad_oce_3D/issues/1
>> <https://github.com/cbernardo/kicad_oce_3D/issues/1>
>> >
>> >  However I have been advised that, as in the case of Windows, it
>> > is probably best if we provide our own OCE as part of the
>> > installer.
>> >
>> >  There is still some cleaning up to do with regards to getting a
>> > Windows build but I believe Nick has sorted out all the biggest
>> > problems.
>> >
>> >  We still need a volunteer to do some work to get an OSX build
>> > of OCE and the 3D plugin, and from there I can put the 3D plugin
>> > *and* a kicad_pcb to STEP converter into KiCad. (Any
>> > volunteers?)
>> >
>> > Currently the 3D plugin can be found here:
>> > https://github.com/cbernardo/kicad_oce_3D
>> <https://github.com/cbernardo/kicad_oce_3D>
>> >
>> > The kicad_pcb to STEP converter is here:
>> > https://github.com/cbernardo/kicad2mcad
>> <https://github.com/cbernardo/kicad2mcad>
>> >
>> > The PCB to STEP converter is currently a stand-alone tool
>> > since integration as a plugin to KiCad requires the implementation
>> > of a PCB API and I just haven't got time to work on that at the
>> > moment.
>> >
>> > - Cirilo
>> >
>> >
>> >
>> > ___
>> > Mailing list: https://launchpad.net/~kicad-developers
>> <https://launchpad.net/~kicad-developers>
>> > Post to : kicad-developers@lists.launchpad.net
>> <mailto:kicad-developers@lists.launchpad.net>
>> > Unsubscribe : https://launchpad.net/~kicad-developers
>> <https://launchpad.net/~kicad-developers>
>> > More help   : https://help.launchpad.net/ListHelp
>> <https://help.launchpad.net/ListHelp>
>> >
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> <https://launchpad.net/~kicad-developers>
>> Post to : kicad-developers@lists.launchpad.net
>> <mailto:kicad-developers@lists.launchpad.net>
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> <https://launchpad.net/~kicad-developers>
>> More help   : https://help.launchpad.net/ListHelp
>> <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] update on STEP visualization

[Nick Østergaard]

He is not talking about STEP export, only the visualization plugin. And the
question as I understand it is to make sure it works on all supported
platforms and being packaged with kicad.  I intend to add it to the windows
installer soon.

Den 15/08/2016 19.55 skrev "Wayne Stambaugh" :

> Cirilo,
>
> I'm not sure what you are asking.  Ideally, any conversion tool such as
> STEP would be part of Pcbnew where a simple export->step menu entry
> would be available.  Users generally prefer this to running and external
> tool.  What is the end goal of this?
>
> Cheers,
>
> Wayne
>
> On 8/14/2016 11:45 PM, Cirilo Bernardo wrote:
> > Hi Folks,
> >
> >  Thanks mostly to nickoe we have been able to build the
> > OCE-based 3D plugin for visualization of STEP (and IGES) files on
> > Windows. I believe that regardless of the availability of some form
> > of OCE on Windows, it is best if we distribute a known good version
> > of OCE which has been built with gcc.
> >
> >  Back in May I also received some tips on building the plugin for
> > OSX: https://github.com/cbernardo/kicad_oce_3D/issues/1
> >
> >  However I have been advised that, as in the case of Windows, it
> > is probably best if we provide our own OCE as part of the
> > installer.
> >
> >  There is still some cleaning up to do with regards to getting a
> > Windows build but I believe Nick has sorted out all the biggest
> > problems.
> >
> >  We still need a volunteer to do some work to get an OSX build
> > of OCE and the 3D plugin, and from there I can put the 3D plugin
> > *and* a kicad_pcb to STEP converter into KiCad. (Any
> > volunteers?)
> >
> > Currently the 3D plugin can be found here:
> > https://github.com/cbernardo/kicad_oce_3D
> >
> > The kicad_pcb to STEP converter is here:
> > https://github.com/cbernardo/kicad2mcad
> >
> > The PCB to STEP converter is currently a stand-alone tool
> > since integration as a plugin to KiCad requires the implementation
> > of a PCB API and I just haven't got time to work on that at the
> > moment.
> >
> > - Cirilo
> >
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Git transition

[Nick Østergaard]

What do you mean with git-SUM, is that the bzrlike revno or is that
the short git sha1?

I personally like the way we have it now with the build date, the
bzrlike revno serial and the git sha1.

Or are you suggesting to do like (2016-08-03 2383bcf-6299)-product
instead of (2016-08-03 BZR 6299, Git 2383bcf)-product?

2016-08-12 21:37 GMT+02:00 Wayne Stambaugh :
> I'm OK with git-SUM rather than the obnoxiously long git rev numbers.
> Anyone object to this?
>
> On 8/12/2016 1:25 AM, Simon Wells wrote:
>> In regards to this, Currently bzr revs are just the number and the git
>> revs are the bzr number and the git sum. Is it worthwhile (esspeically
>> in the title bar just changing this to git-BZRREV or just git-SUM
>> since git will be the primary vcs?
>>
>> On Fri, Aug 12, 2016 at 7:55 AM, Adam Wolf
>>  wrote:
>>> Sounds good!  I think that timeline is fine.
>>>
>>> Adam Wolf
>>>
>>>
>>> On Thu, Aug 11, 2016, 2:54 PM Wayne Stambaugh  wrote:

 You have a couple of options.

 You could just clone directly from the source mirror on github for
 testing then update the url when we go live with git on launchpad.

 You could create your own clone of the github source mirror and add a
 remote link to your own personal git branch on launchpad and use that
 for testing.  This is what I have been using.  The set the url to push
 to your own git repo on launchpad run:

 git remote add launchpad
 git+ssh://u...@git.launchpad.net/~USER/kicad/+git/kicad-dev

 git push launchpad (OPTIONAL-REPO-NAME-ON-LP)

 You will now have your own kicad git repo on launchpad which you can
 clone for testing.

 On 8/11/2016 3:36 PM, Adam Wolf wrote:
> It should.  Can we somehow push a copy of what it is now so I have
> something to build against?
>


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

Re: [Kicad-developers] Git transition

[Nick Østergaard]

Den 11/08/2016 11.18 skrev "Maciej Sumiński" :
>
> On 08/10/2016 03:34 PM, Wayne Stambaugh wrote:
> > On 8/10/2016 5:02 AM, Maciej Sumiński wrote:
> >> On 08/08/2016 06:09 PM, Wayne Stambaugh wrote:
> >>> The last time I looked, notifications of repo commits still were not
> >>> implemented.  This is a show stopper for me.  I don't want to have to
> >>> constantly grep the git commit log to see what changed.  If change
> >>> notifications are working correctly, then I'm OK with moving forward
on
> >>> this if you can get the bug fix linking working.  We definitely should
> >>> do some testing before we go live with this.
> >>
> >> I see there is an option to set notifications, in the same way as for
> >> the bazaar branches ("Edit your subscriptions" on the right side pane).
> >> I could not verify it, as likely I cannot receive notifications for the
> >> changes I introduce. Even if it does not work, I can implement it in my
> >> webhook.
> >
> > I spent some time yesterday creating my own git clone of kicad on LP and
> > I noticed that the subscriptions that I need appear to be available for
> > git repos so we shouldn't need any webhooks in for that unless they do
> > not work.
>
> If they do not work, let me know and I will fix it in the hook.
>
> >>
> >> The webhook has reached beta stage. I have created a dummy project for
> >> testing purposes, where you can see a bug report [1] and a commit [2]
> >> with message that includes a "fix(es)?[ ]+(lp:|#)?([0-9]+)" regex
match.
> >> When it is detected, it automatically adds a message, changes the bug
> >> status and assignee. One thing that is not possible right now is
linking
> >> with git branches, as apparently launchpad does not handle this at the
> >> moment (or I could not find the right format to specify a branch).
> >
> > Bug report linking is very important to me since I am responsible for
> > the stable branch.  If there is no support for this yet, I'm OK with
> > adding the bug report number to the first line of the commit message and
> > the URL somewhere in the commit message body.  If I give the OK to use
> > git, I will expect all developers that have commit privileges to the
> > product repo to follow this without exception.  The commit message for
> > bug report fixes must have this format:
> >
> > Description of bug report fix. (fixes lp:)
> >
> > * https://bugs.launchpad.net/kicad/+bug/
> >
> > If this is not acceptable, then the git transition will have to wait
> > until Canonical gets git bug report linking implemented or Orson beats
> > them to it.
>
> I spoke with a Launchpad developer and they have it already in their
> todo list. There is a plan to migrate Launchpad itself to git, so I
> believe they will do it well.
>
> From what I heard, currently it is possible to link git merge requests
> to bug reports, so it may temporarily solve the problem.
>
> >> All we need to do is to set a webhook pointing to my script [3]. If it
> >> is accepted, then I am going to create a separate lp account for the
> >> automated changes.
> >>
> >> Currently the webhook works on my home server which has a high uptime,
> >> but still it is not as reliable as dedicated servers. If there is
> >> someone willing to host it on a better machine, I will be pleased to
help.
> >>
> >> If you are curious about the source code, then I can put it in the
KiCad
> >> github (once I get a repository there) or just post it somewhere.
> >
> > I can create a repo on github or you can create a repo on launchpad.
> > Either way is fine by me.  If you want to use github, let me know what
> > name you want for the repo and your github user name and I will set up
> > the repo and give you admin rights.
>
> I have just pushed the code to Launchpad [1] and consider it ready to
> go. There is also a new account (KiCad Janitor) awaiting approval for
> kicad-developers membership, so all the changes will be done using this
> dedicated account.
>
> The webhook has been modified to accept a wider set of phrases
> indicating a bugfix (now it is (f|F)ix(es|ed|ing)?:? *(lp:|#)?([0-9]+)).
>

I would like to suggest that we don't write "fixes:" as a prefix, I don't
see it adds any added information. Simply write:
lp:4232442

And in the rare event it is for multiple bugs just append more lines of it.

> Let me know when the git repository is set up, so I can install the
webhook.
>
> Regards,
> Orson
>
> 1. https://launchpad.net/kicad-git-hook
>
> > Thanks for working on this.
> >
> > Cheers,
> >
> > Wayne
> >
> >>
> >> Regards,
> >> Orson
> >>
> >> 1. https://bugs.launchpad.net/kicad-git-test/+bug/1611664
> >> 2.
> >>
https://git.launchpad.net/kicad-git-test/commit/?id=3d29b9be29346fdfaa87cdf8abf6957bf46bb5cd
> >> 3. https://orson.net.pl/kicad_git_hook
> >>
> >>> Before every starts beating the GitHub drum, I have one major issue
with
> >>> GitHub and that is control.  There is no way that I know of to
moderate
> >>> a project on github.  

Re: [Kicad-developers] [Github] incorrect position (commit) of release and tag for v.4.0.3

[Nick Østergaard]

Yeah, that is indeed correct. I will align with Povilas who currently
performs the mirroring.

2016-08-08 18:29 GMT+02:00 Eldar Khayrullin :
> See the theme
> ___
> Mailing list: https://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] [Release 4.0.3] Build bug (Boost 1.54)

[Nick Østergaard]

Not unconditionally!

It seems like you are using some old debian derived system. Please
provide further details... Although I see snappy mentioned in your
URI...

2016-08-08 19:47 GMT+02:00 Eldar Khayrullin :
> Get the msg:
>
> ...failed gcc.compile.c++
> bin.v2/libs/thread/build/gcc-5.4.0/release/link-static/threading-multi/pthread/thread.o...
> ...skipped
> libboost_thread.a(clean)
> for lack of
> pthread/thread.o...
> ...skipped
> libboost_thread.a
> for lack of
> pthread/thread.o...
> ...skipped
> libboost_thread.a
> for lack of
> libboost_thread.a...
> ...failed updating 2 targets...
> ...skipped 9 targets...
>
> Need add the flag -DKICAD_SKIP_BOOST=ON to here:
> http://kicad-pcb.org/download/source/
>
> ___
> Mailing list: https://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] Stable release update.

[Nick Østergaard]

Considering that there are no solution choosen for this issue nor even
a patch, I don't think we should block the 4.0.3 release becasue of
this issue. Changes to DRC should be taken with care, and I would
rather like a potential fix to be tested a bit more than is possible
in a few days timeframe.

2016-08-07 8:47 GMT+02:00 Eldar Khayrullin <eldar.khayrul...@mail.ru>:
> What about this bug:
> https://bugs.launchpad.net/kicad/+bug/1593373
> I don't know it is right to set Importance of this bug to Low.
> I think it Importance should be High and this bug should be fixed before
> Release (I think maybe I'm wrong)
>
> В Воскресенье, 7 авг. 2016 в 1:58 , Wayne Stambaugh <stambau...@gmail.com>
> написал:
>
> On 8/6/2016 6:17 PM, Nick Østergaard wrote:
>
> I think you can make the release tar of the source now on launchpad.
>
> I've got it ready to go. I will go ahead an release it tomorrow. Anyone have
> an issue with this? Package devs please note I had to re-tag 4.0.3 to r6302
> so if you built 4.0.3 prior to this revision, please rebuild to the correct
> version. Sorry, there was a flurry of last minute bug fixes that effected
> the stable branch.
>
> I only need the update from the german translator for the kicad-i18n, the
> docs and libs have been tagged and uploaded now.
>
> Thanks!
>
> Then I will trigger a stable build as a release candidate in testing for a
> sanity check. Poke Adam (OSX) and JS-reynaud (ubuntu PPA) if they can do
> that too and we can publish the release note on the website.
>
> I already have the announcement in my kicad-website-dev repo so I will do a
> pull request and merge (I think I have admin rights to the website repo) the
> announcement.
>
> 2016-08-04 19:15 GMT+02:00 Wayne Stambaugh <stambau...@gmail.com>:
>
> Thanks for the update. Let me know if I need to push the release back to
> Monday. On 8/4/2016 11:44 AM, Nick Østergaard wrote:
>
> FYI Everyhting should probably line up now. I am just waiting for a german
> translator to bring the german GUI translations to 100%, he said he could
> probably do that during the weekend. And then awaiting the librarians tag
> the libs and make sure we do not remove pretties that was existing before. I
> expect this to be done during the weekend nor at latest monday. 2016-08-01
> 14:21 GMT+02:00 Wayne Stambaugh <stambau...@gmail.com>:
>
> I'm just checking in to make sure we are good to go with the upcoming 4.0.3
> stable release. I will plan on announcing the release and creating the
> source archive this weekend unless there is something holding it up. Please
> let me know if there are any issues. Otherwise, expect a new stable release
> this weekend. Thank you everyone for your efforts to make this possible.
> Cheers, Wayne ___ Mailing list:
> https://launchpad.net/~kicad-developers Post to :
> kicad-developers@lists.launchpad.net 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] Stable release update.

[Nick Østergaard]

Please note that you write that it does not contain a new snapshot of
the docs or libs, this is not the case. There is a new snapshot of the
docs, the stable banch supposed to match the stable kicad. It is
mostly improved translations.

Also the libs are updated. :)

2016-08-07 0:58 GMT+02:00 Wayne Stambaugh <stambau...@gmail.com>:
> On 8/6/2016 6:17 PM, Nick Østergaard wrote:
>> I think you can make the release tar of the source now on launchpad.
>
> I've got it ready to go.  I will go ahead an release it tomorrow.
> Anyone have an issue with this?  Package devs please note I had to
> re-tag 4.0.3 to r6302 so if you built 4.0.3 prior to this revision,
> please rebuild to the correct version.  Sorry, there was a flurry of
> last minute bug fixes that effected the stable branch.
>
>>
>> I only need the update from the german translator for the kicad-i18n,
>> the docs and libs have been tagged and uploaded now.
>
> Thanks!
>
>>
>> Then I will trigger a stable build as a release candidate in testing
>> for a sanity check. Poke Adam (OSX) and JS-reynaud (ubuntu PPA) if
>> they can do that too and we can publish the release note on the
>> website.
>
> I already have the announcement in my kicad-website-dev repo so I will
> do a pull request and merge (I think I have admin rights to the website
> repo) the announcement.
>
>>
>> 2016-08-04 19:15 GMT+02:00 Wayne Stambaugh <stambau...@gmail.com>:
>>> Thanks for the update.  Let me know if I need to push the release back
>>> to Monday.
>>>
>>> On 8/4/2016 11:44 AM, Nick Østergaard wrote:
>>>> FYI
>>>>
>>>> Everyhting should probably line up now. I am just waiting for a german
>>>> translator to bring the german GUI translations to 100%, he said he
>>>> could probably do that during the weekend.
>>>>
>>>> And then awaiting the librarians tag the libs and make sure we do not
>>>> remove pretties that was existing before. I expect this to be done
>>>> during the weekend nor at latest monday.
>>>>
>>>> 2016-08-01 14:21 GMT+02:00 Wayne Stambaugh <stambau...@gmail.com>:
>>>>> I'm just checking in to make sure we are good to go with the upcoming
>>>>> 4.0.3 stable release.  I will plan on announcing the release and
>>>>> creating the source archive this weekend unless there is something
>>>>> holding it up.  Please let me know if there are any issues.  Otherwise,
>>>>> expect a new stable release this weekend.  Thank you everyone for your
>>>>> efforts to make this possible.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Wayne
>>>>>
>>>>> ___
>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>> Post to : kicad-developers@lists.launchpad.net
>>>>> 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] 4.0.3 stable release last call.

[Nick Østergaard]

Thanks.

Den 03/08/2016 20.22 skrev "Wayne Stambaugh" <stambau...@gmail.com>:

> My bad.  I thought this patch was part of a bug report.  I'll commit it
> and change the 4.0.3 tag.  This is the last non-critical bug fix for
> 4.0.3.  Any other non-critical bugs can wait until the 4.0.4 release.
>
> On 8/3/2016 2:15 PM, Nick Østergaard wrote:
> > I don't think it has been reported on the tracker, but that doesn't mean
> > it is not a bug ;)
> >
> >
> > Den 03/08/2016 18.01 skrev "Wayne Stambaugh" <stambau...@gmail.com
> > <mailto:stambau...@gmail.com>>:
> >
> > I got that but Nick mentioned a bug fix so I assumed that it fixed a
> bug
> > report.  Did r7000 fix a bug report or not?  If so, what is the bug
> > report number so I can link to it when I commit the stable release
> fix.
> >
> > On 8/3/2016 11:52 AM, Chris Pavlina wrote:
> > > He's referring to revision 7000.
> > >
> > > On Wed, Aug 03, 2016 at 11:41:36AM -0400, Wayne Stambaugh wrote:
> > >> Which bug does it fix?  It is not linked in the commit and I did
> > a quick
> > >> search and I cannot find the bug in question.
> > >>
> > >> A reminder to my devs with commit access, please use the bzr
> --fixes
> > >> option when committing LP bug report fixes so I don't have to go
> back
> > >> and figure out which commit fixes which bug.
> > >>
> > >> On 8/3/2016 9:17 AM, Nick Østergaard wrote:
> > >>> Hi Wayne
> > >>>
> > >>> Will it be possible to include the fix the the F.Silk on new
> > pads too?
> > >>> I know it is not a segfault or anything similar, but I still
> > consider
> > >>> it a bugfix.
> > >>>
> > >>>
> >
> http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/7000
> > >>>
> > >>> 2016-08-03 14:33 GMT+02:00 Wayne Stambaugh <stambau...@gmail.com
> > <mailto:stambau...@gmail.com>>:
> > >>>> If no one has any issues, I'm going to apply this patch to the
> > stable
> > >>>> branch an tag r6298 as 4.0.3 instead of r6297.  I am still
> > planning on
> > >>>> announcing the stable release over the weekend.  Let me know if
> > this is
> > >>>> going to be a problem and I will push the stable release back
> > another
> > >>>> week.  I'm guessing this will only effect our package devs.
> > >>>>
> > >>>> Thanks,
> > >>>>
> > >>>> Wayne
> > >>>>
> > >>>> On 8/2/2016 7:00 PM, Nick Østergaard wrote:
> > >>>>> Hi
> > >>>>>
> > >>>>> Please be aware of this bug which causes a segfault. The issues
> > >>>>> appears both on recent product and 4.0.2.
> > >>>>> https://bugs.launchpad.net/kicad/+bug/1607430
> > >>>>>
> > >>>>> The reason have been found, but I am not sure if you would
> > consider
> > >>>>> the fix for inclusion in 4.0.3 at this stage.
> > >>>>>
> > >>>>> Nick
> > >>>>>
> > >>>>> 2016-07-09 18:07 GMT+02:00 Wayne Stambaugh
> > <stambau...@gmail.com <mailto:stambau...@gmail.com>>:
> > >>>>>> I'm making one last call for any last bug fixes for the
> > version 4 stable
> > >>>>>> branch before I tag 4.0.3.  If you are working on anything or
> > know of
> > >>>>>> anything that could be a show stopper, please let me know.  I
> > hope to
> > >>>>>> tag 4.0.3 early next week to give our doc devs and
> > translators a chance
> > >>>>>> to make any last changes before I roll out 4.0.3 and make the
> > announcement.
> > >>>>>>
> > >>>>>> Cheers,
> > >>>>>>
> > >>>>>> Wayne
> > >>>>>>
> > >>>>>> ___
> > >>>>>> Mailing list: https://launchpad.net/~kicad-developers
> > >>>>>> Post to : kicad-developers@lists.launchpad.net
> > <mailto:kicad-developers@lists.launchpad.net>
> > >>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
> > >>>>>> More help   : https://help.launchpad.net/ListHelp
> > >>
> > >> ___
> > >> Mailing list: https://launchpad.net/~kicad-developers
> > >> Post to : kicad-developers@lists.launchpad.net
> > <mailto:kicad-developers@lists.launchpad.net>
> > >> Unsubscribe : https://launchpad.net/~kicad-developers
> > >> More help   : https://help.launchpad.net/ListHelp
> >
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] 4.0.3 stable release last call.

[Nick Østergaard]

I don't think it has been reported on the tracker, but that doesn't mean it
is not a bug ;)

Den 03/08/2016 18.01 skrev "Wayne Stambaugh" <stambau...@gmail.com>:

> I got that but Nick mentioned a bug fix so I assumed that it fixed a bug
> report.  Did r7000 fix a bug report or not?  If so, what is the bug
> report number so I can link to it when I commit the stable release fix.
>
> On 8/3/2016 11:52 AM, Chris Pavlina wrote:
> > He's referring to revision 7000.
> >
> > On Wed, Aug 03, 2016 at 11:41:36AM -0400, Wayne Stambaugh wrote:
> >> Which bug does it fix?  It is not linked in the commit and I did a quick
> >> search and I cannot find the bug in question.
> >>
> >> A reminder to my devs with commit access, please use the bzr --fixes
> >> option when committing LP bug report fixes so I don't have to go back
> >> and figure out which commit fixes which bug.
> >>
> >> On 8/3/2016 9:17 AM, Nick Østergaard wrote:
> >>> Hi Wayne
> >>>
> >>> Will it be possible to include the fix the the F.Silk on new pads too?
> >>> I know it is not a segfault or anything similar, but I still consider
> >>> it a bugfix.
> >>>
> >>>
> http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/7000
> >>>
> >>> 2016-08-03 14:33 GMT+02:00 Wayne Stambaugh <stambau...@gmail.com>:
> >>>> If no one has any issues, I'm going to apply this patch to the stable
> >>>> branch an tag r6298 as 4.0.3 instead of r6297.  I am still planning on
> >>>> announcing the stable release over the weekend.  Let me know if this
> is
> >>>> going to be a problem and I will push the stable release back another
> >>>> week.  I'm guessing this will only effect our package devs.
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Wayne
> >>>>
> >>>> On 8/2/2016 7:00 PM, Nick Østergaard wrote:
> >>>>> Hi
> >>>>>
> >>>>> Please be aware of this bug which causes a segfault. The issues
> >>>>> appears both on recent product and 4.0.2.
> >>>>> https://bugs.launchpad.net/kicad/+bug/1607430
> >>>>>
> >>>>> The reason have been found, but I am not sure if you would consider
> >>>>> the fix for inclusion in 4.0.3 at this stage.
> >>>>>
> >>>>> Nick
> >>>>>
> >>>>> 2016-07-09 18:07 GMT+02:00 Wayne Stambaugh <stambau...@gmail.com>:
> >>>>>> I'm making one last call for any last bug fixes for the version 4
> stable
> >>>>>> branch before I tag 4.0.3.  If you are working on anything or know
> of
> >>>>>> anything that could be a show stopper, please let me know.  I hope
> to
> >>>>>> tag 4.0.3 early next week to give our doc devs and translators a
> chance
> >>>>>> to make any last changes before I roll out 4.0.3 and make the
> announcement.
> >>>>>>
> >>>>>> 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
> >>
> >> ___
> >> Mailing list: https://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] 4.0.3 stable release last call.

[Nick Østergaard]

Hi Wayne

Will it be possible to include the fix the the F.Silk on new pads too?
I know it is not a segfault or anything similar, but I still consider
it a bugfix.

http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/7000

2016-08-03 14:33 GMT+02:00 Wayne Stambaugh <stambau...@gmail.com>:
> If no one has any issues, I'm going to apply this patch to the stable
> branch an tag r6298 as 4.0.3 instead of r6297.  I am still planning on
> announcing the stable release over the weekend.  Let me know if this is
> going to be a problem and I will push the stable release back another
> week.  I'm guessing this will only effect our package devs.
>
> Thanks,
>
> Wayne
>
> On 8/2/2016 7:00 PM, Nick Østergaard wrote:
>> Hi
>>
>> Please be aware of this bug which causes a segfault. The issues
>> appears both on recent product and 4.0.2.
>> https://bugs.launchpad.net/kicad/+bug/1607430
>>
>> The reason have been found, but I am not sure if you would consider
>> the fix for inclusion in 4.0.3 at this stage.
>>
>> Nick
>>
>> 2016-07-09 18:07 GMT+02:00 Wayne Stambaugh <stambau...@gmail.com>:
>>> I'm making one last call for any last bug fixes for the version 4 stable
>>> branch before I tag 4.0.3.  If you are working on anything or know of
>>> anything that could be a show stopper, please let me know.  I hope to
>>> tag 4.0.3 early next week to give our doc devs and translators a chance
>>> to make any last changes before I roll out 4.0.3 and make the announcement.
>>>
>>> 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

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

Re: [Kicad-developers] PATCH: fix 3d filename parsing

[Nick Østergaard]

I just tested this patch and it work now, the path is not gone from
the 3D properties dialog any more, and it even renders the model :)

2016-08-03 10:36 GMT+02:00 Cirilo Bernardo :
> When I replaced the S3D_MASTER class with S3D_INFO struct
> I made a mistake in my search/replace which resulted in the bug:
>
> https://bugs.launchpad.net/kicad/+bug/1609122
>
> The attached patch fixes this bug.
>
> - 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

[Kicad-developers] Fwd: About DRC from the plot dialog

[Nick Østergaard]

Hi

I forgot to add the kicad list to this thread so I am forwarding it
here for info and if others want to participate in the discussion.

Nick

2016-07-28 13:24 GMT+02:00 jp charras <jp.char...@wanadoo.fr>:
> Le 28/07/2016 à 12:12, Nick Østergaard a écrit :
>> Hello Jean-Pierre,
>>
>> I see you have recently [1] made a commit to add a shortcut to run the
>> DRC from the plot dialog in pcbnew. I suspect this is a proposal for a
>> fix to [2]. Thanks.
>>
>> Is this true?
>
> Yes.
> Since a long time, there are a few bug reports about this topic.
>
> The bug happens only on Linux, and it is fixed on my working branch (will be 
> committed very soon)
>
>
>>
>> Either way, I think the current implementation is not ideal and have
>> another proposal.
>>
>> Currently it works like a shortcut to the DRC dialog, but with the bug
>> that it can not jump to the locations of for example unconnected
>> traces.
>>
>> There is a problem with running DRC from the plot dialog, it is that
>> it will modify the board when plotting, like refilling zones and
>> removing "orphaned" vias for example.
>
> It is not specific of "running DRC from the plot dialog".
>
> It rebuild all data related to the netlist info, and rebuild the zones.
> Because a good practice is to run DRC before plotting the board, the fact the 
> DRC is run from the
> plot dialog has no matter.

Yes, but the problem is that it still modifies the board in contrast
to what it was before the user made the plot.

>
>>
>> I would like to see it as a checker only. I propose to not have it as
>> a "Run DRC" button, but have a checkbox to enabled DRC on plotting or
>> not. And in this case it should not refill zones nor remove orphaned
>> vias, it should only be used to warn the user that there might still
>> be problems with the board.
>>
>> If there are not errors, it should just plot like normal.
>
> Unfortunately, it is no possible.
>
> The DRC function  which calculates unconnected and clearance issues imply a 
> few requirement in Kicad
> code:
>
> * the connectivity info is good
> It means orphan vias have no net, becuase they are not really connected.
> Orphan stitching vias are not yet supported because until now I never see a 
> working patch, and even
> see a working solution.
> Moreover, when reloading the board, the connectivity info will be rebuilt.
> Therefore running DRC before plotting fixes this potential issue.

What is the reason that we can't update the file format to include net
info for vias then? This would solve the problem as I see it. (unless
there is some detail I forgot)

>
> * the copper areas are good. Especially isolated islands are removed, and the 
> shapes are good:
> It means they meet their setup (for instance clearance and pad connection 
> options)
>
> For instance:
> - Fill a zone having pads connected by thermal stubs.
> Change the  thermal stubs option by no thermal.
> The DRC is still perfectly good. But the shape is not good.
> - Create and fill a zone with a given clearance.
> Change with a smaller clearance.
> The DRC is still perfectly good. But the shape is not good.
>
> Be sure there are a lot of other similar cases.

But if this is the reasoning, why shouldn't the DRC be run
automatically every time? It could optinally warn the user that
orphaned board objects have been removed if that is really the case.

I know some people say it is bad to have it automatically change the
board on plot, but if that change is the same as when reloading the
board I am ok with that. The same people also say that they want to
know if the board has DRC errors before plotting. Hence I think my
proposal with that option to auto run the DRC would be helpful to the
user.

>
>>
>> If there are errors it should probably present the user with a dialog
>> telling that there are issues with the board and allow the user to
>> plot anyway or cancel such that the user can go back and fix the
>> issues.
>
> For me, it does not fix all issues, only some of them.
>
> To tell the true, I do not understand what is the real issue to run the DRC 
> from plot dialog.
>
> All changes the DRC can make will be made when reloading the board, or the 
> next time a DRC will be
> run from the board editor.

Sorry if my reply sounds a bit grumpy, I don't mean to at least. I
just want to understand the issue better, and why we can't have a
better way to handle this issue, such that it is not a manual step to
assure that the plot is a valid board.

>
>>
>> Regards
>> Nick Østergaard
>
> Regards,
>
> --
> Jean-Pierre CHARRAS

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

Re: [Kicad-developers] New eeschema file format

[Nick Østergaard]

2016-07-31 21:53 GMT+02:00 Mário Luzeiro :
> Hi all,
>
> Feature request for eeschema:
>
> Not sure if this is the right thread, as now I started using again KiCad,
> one thing I miss and I believe I found somewhere other requests, is the 
> ability to
> make some kind of notes in schematics.
>
> Usually I use "Add text" but that text is visible and printed.
> I was looking for a "speech bubble" that you can edit the text content.
>
> It should be useful for add comments, explanations of the circuit or things 
> you do not want to forget.
> Also useful for add URLs in that notes..
>
> Is there any workaround for this at moment?

I guess the workaround is to put the text outside of the printable area.

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

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

Re: [Kicad-developers] Build failed in Jenkins: linux-kicad-full-gcc-head #1389

[Nick Østergaard]

This is just me messing about. Ignore this.

2016-07-28 18:30 GMT+02:00 Miguel Angel Ajo :
> See 
>
> --
> Started by user Nick Ostergaard
> Building remotely on falkenberg-docker-c0427c74fc08 (docker_debian-jessie) in 
> workspace 
> Cleaning workspace...
> $ bzr branch lp:kicad 
> 
> You have not informed bzr of your Launchpad ID, and you must do this to
> write to Launchpad or access private data.  See "bzr help launchpad-login".
> Branched 6996 revisions.
> Getting local revision...
> $ bzr revision-info -d 
> 
> info result: bzr revision-info -d 
>  returned 0. 
> Command output: "6996 jp.char...@wanadoo.fr-20160728120735-ygvjkcw20hvkligw
> " stderr: ""
> RevisionState revno:6996 
> revid:jp.char...@wanadoo.fr-20160728120735-ygvjkcw20hvkligw
> [linux-kicad-full-gcc-head] $ /bin/sh -xe /tmp/hudson1153694114405633705.sh
> + OPTS= -DCMAKE_BUILD_TYPE=Debug -DBUILD_GITHUB_PLUGIN=ON 
> -DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON 
> -DKICAD_SCRIPTING_WXPYTHON=ON
> + export TERM=vt220
> + [ -d build ]
> + mkdir build
> + cd build
> + /usr/bin/cmake .. -DCMAKE_BUILD_TYPE=Debug -DBUILD_GITHUB_PLUGIN=ON 
> -DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON 
> -DKICAD_SCRIPTING_WXPYTHON=ON
> -- The C compiler identification is GNU 4.9.2
> -- The CXX compiler identification is GNU 4.9.2
> -- Check for working C compiler: /usr/bin/cc
> -- Check for working C compiler: /usr/bin/cc -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Check for working CXX compiler: /usr/bin/c++
> -- Check for working CXX compiler: /usr/bin/c++ -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Kicad install dir: 
> -- Looking for malloc.h
> -- Looking for malloc.h - found
> -- Looking for iso646.h
> -- Looking for iso646.h - found
> -- Looking for stdint.h
> -- Looking for stdint.h - found
> -- Looking for strcasecmp
> -- Looking for strcasecmp - found
> -- Looking for strncasecmp
> -- Looking for strncasecmp - found
> -- Looking for strtok_r
> -- Looking for strtok_r - found
> -- Looking for malloc
> -- Looking for malloc - found
> -- Looking for math.h
> -- Looking for math.h - found
> -- Looking for C++ include cmath
> -- Looking for C++ include cmath - found
> -- Looking for asinh
> -- Looking for asinh - found
> -- Looking for acosh
> -- Looking for acosh - found
> -- Looking for atanh
> -- Looking for atanh - found
> -- Performing Test HAVE_CMATH_ISINF
> -- Performing Test HAVE_CMATH_ISINF - Success
> -- Looking for clock_gettime in rt
> -- Looking for clock_gettime in rt - found
> -- Looking for gettimeofday
> -- Looking for gettimeofday - found
> -- Looking for getc_unlocked
> -- Looking for getc_unlocked - found
> -- Performing Test COMPILER_SUPPORTS_CXX11
> -- Performing Test COMPILER_SUPPORTS_CXX11 - Success
> -- Try OpenMP C flag = [-fopenmp]
> -- Performing Test OpenMP_FLAG_DETECTED
> -- Performing Test OpenMP_FLAG_DETECTED - Success
> -- Try OpenMP CXX flag = [-fopenmp]
> -- Performing Test OpenMP_FLAG_DETECTED
> -- Performing Test OpenMP_FLAG_DETECTED - Success
> -- Found OpenMP: -fopenmp
> -- Found wxWidgets: 
> -L/usr/lib/x86_64-linux-gnu;-pthread;;;-lwx_gtk2u_gl-3.0;-lwx_gtk2u_aui-3.0;-lwx_gtk2u_adv-3.0;-lwx_gtk2u_html-3.0;-lwx_gtk2u_core-3.0;-lwx_baseu_net-3.0;-lwx_baseu-3.0;-lwx_baseu_xml-3.0;-lwx_gtk2u_stc-3.0
>  (found suitable version "3.0.2", minimum required is "3.0.0")
> -- Looking for XOpenDisplay in 
> /usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so
> -- Looking for XOpenDisplay in 
> /usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so - 
> found
> -- Looking for gethostbyname
> -- Looking for gethostbyname - found
> -- Looking for connect
> -- Looking for connect - found
> -- Looking for remove
> -- Looking for remove - found
> -- Looking for shmat
> -- Looking for shmat - found
> -- Looking for IceConnectionNumber in ICE
> -- Looking for IceConnectionNumber in ICE - found
> -- Found X11: /usr/lib/x86_64-linux-gnu/libX11.so
> -- Found OpenGL: /usr/lib/x86_64-linux-gnu/libGL.so
> -- Found Glew: /usr/lib/x86_64-linux-gnu/libGLEW.so
> -- Check for installed GLEW -- found
> -- Found GLM: /usr/include (found suitable version "0.9.5.4", minimum 
> required is "0.9.5.1")
> -- Found CURL: /usr/lib/x86_64-linux-gnu/libcurl.so (found version "7.38.0")
> -- Found PkgConfig: /usr/bin/pkg-config (found version "0.28")
> -- checking for module 'cairo'
> --   found cairo, version 1.14.0
> -- Found Cairo: /usr/lib/x86_64-linux-gnu/libcairo.so (found suitable version 
> "1.14.0", minimum required is "1.8.8")
> -- Boost version: 1.55.0
> -- 

Re: [Kicad-developers] Geometry ongoing work

[Nick Østergaard]

2016-07-26 14:58 GMT+02:00 Wayne Stambaugh <stambau...@gmail.com>:
> On 7/26/2016 7:20 AM, Nick Østergaard wrote:
>> Welcome.
>>
>> I have found a pcb file on my computer, I am not sure of its origin,
>> that has a buggy rendering both in legacy and GAL in different, but
>> similar ways. Maybe you should include this in your testing and
>> development.
>>
>> About unittests, there is already some stuff in the qa folder using
>> python... but this is mostly a proof of concept. Nothing is really
>> tested at the moment, except for file loading more or less. I would
>> personally like to see some more testing, although I am not sure that
>> the boost test module is the best for this either.
>
> I suggested using the boost unit testing framework to Alejandro.  The
> problem with using python unit testing is that not everything in Pcbnew
> is swigged so you wouldn't be able to test that code unless there is
> someway to compile and run C++ test code from the python unit test
> framework.  If this can be done, then boost unit test wouldn't be necessary.
>
> While I'm not 100% convinced that the boost unit test frameworks is the
> way to go, it seems to compare well to the other C++ test frameworks.
> The benefit is it does not add yet another dependency and allows us to
> use C++ code to write tests.  I do not have any experience in this area
> so if someone as experience using the different c++ unit test
> frameworks, feel free to comment.
>
>>
>> Will your work eventually lead to use for example arcs on copper
>> layers, which is not supported by the DRC?
>
> It should allow for this but AFAIK we still cannot generate gerbers with
> arcs.

Why not?

The gerber spec has: 4.5  Circular Interpolation (G02/G03) and (G74/G75)

I might be misinterpreting the spec, but I see that as it supports
_circular_ arcs. Which is what we have in KiCad.

>
>>
>> Nick
>>
>> 2016-07-15 12:25 GMT+02:00 Alejandro Garcia Montoro
>> <alejandro.garciamont...@gmail.com>:
>>> Hi!
>>>
>>> I've been working on some geometry code on this branch:
>>> https://code.launchpad.net/~alejandro-garciamontoro/kicad/kicad-polygon-refactor
>>>
>>> This is still an ongoing work. You can consider this as a new developer
>>> getting used to the code, waiting for Wayne and Javier to review the code
>>> and decide if I finally join the team :) By the way, for the guys that were
>>> not at the CERN hackaton: I am Alejandro García, a Computer Science and
>>> Mathematics student from Granada, Spain; the idea is to work on KiCAD
>>> full-time once I finish my studies; that is, since September 19th.
>>>
>>> So far, the following has been done:
>>>
>>> CPolyLine refactoring, thouroughly tested in the tests directory.
>>>
>>> CPolyLine::Chamfer method has been refactored into
>>> SHAPE_POLY_SET::ChamferPolygon method. The main behaviour of the old method
>>> has been maintained, returning a completely new POLYGON object; if you think
>>> it should modify the original polygon instead of returning a copy of a new
>>> one, let me know. This was done this way just to preserve the way CPolyLine
>>> did its job. Furthermore, a sanity check was introduced into the old
>>> CPolyLine method: due to rounding errors, two corners with the exact same
>>> coordinates could be added, and the CPolyLine::RemoveNullSegments was not
>>> able to remove them (this is a bug that should be studied if we continue to
>>> use CPolyLine code; as this is not the idea, I just fixed the errors in the
>>> new ChamferPolygon method to be able to test my refactoring).
>>> CPolyLine::Fillet method has been refactored into
>>> SHAPE_POLY_SET::FilletPolygon method. The same previous comments apply here.
>>> The AppendBezier methods have not been moved to SHAPE_POLY_SET yes. As I
>>> think Michele is working on a SHAPE_ARC class, I though it's better to wait
>>> for that code to be ready.
>>>
>>> The collision between a SHAPE_POLY_SET object and a point has been
>>> implemented and tested: the main behaviour is managed from the Contains
>>> method, that has been fixed to support holes, and that is implemented with
>>> the new containsSingle private method.
>>> Some more simple methods have been implemented in the SHAPE_POLY_SET class:
>>> HasHoles method, which was declared but not defined and PointOnEdge, which
>>> is basically a loop over the SHAPE_LINE_CHAIN::PointOnEdge method.
>>> A tests folder has been added to the project directory structure

Re: [Kicad-developers] Geometry ongoing work

[Nick Østergaard]

Welcome.

I have found a pcb file on my computer, I am not sure of its origin,
that has a buggy rendering both in legacy and GAL in different, but
similar ways. Maybe you should include this in your testing and
development.

About unittests, there is already some stuff in the qa folder using
python... but this is mostly a proof of concept. Nothing is really
tested at the moment, except for file loading more or less. I would
personally like to see some more testing, although I am not sure that
the boost test module is the best for this either.

Will your work eventually lead to use for example arcs on copper
layers, which is not supported by the DRC?

Nick

2016-07-15 12:25 GMT+02:00 Alejandro Garcia Montoro
:
> Hi!
>
> I've been working on some geometry code on this branch:
> https://code.launchpad.net/~alejandro-garciamontoro/kicad/kicad-polygon-refactor
>
> This is still an ongoing work. You can consider this as a new developer
> getting used to the code, waiting for Wayne and Javier to review the code
> and decide if I finally join the team :) By the way, for the guys that were
> not at the CERN hackaton: I am Alejandro García, a Computer Science and
> Mathematics student from Granada, Spain; the idea is to work on KiCAD
> full-time once I finish my studies; that is, since September 19th.
>
> So far, the following has been done:
>
> CPolyLine refactoring, thouroughly tested in the tests directory.
>
> CPolyLine::Chamfer method has been refactored into
> SHAPE_POLY_SET::ChamferPolygon method. The main behaviour of the old method
> has been maintained, returning a completely new POLYGON object; if you think
> it should modify the original polygon instead of returning a copy of a new
> one, let me know. This was done this way just to preserve the way CPolyLine
> did its job. Furthermore, a sanity check was introduced into the old
> CPolyLine method: due to rounding errors, two corners with the exact same
> coordinates could be added, and the CPolyLine::RemoveNullSegments was not
> able to remove them (this is a bug that should be studied if we continue to
> use CPolyLine code; as this is not the idea, I just fixed the errors in the
> new ChamferPolygon method to be able to test my refactoring).
> CPolyLine::Fillet method has been refactored into
> SHAPE_POLY_SET::FilletPolygon method. The same previous comments apply here.
> The AppendBezier methods have not been moved to SHAPE_POLY_SET yes. As I
> think Michele is working on a SHAPE_ARC class, I though it's better to wait
> for that code to be ready.
>
> The collision between a SHAPE_POLY_SET object and a point has been
> implemented and tested: the main behaviour is managed from the Contains
> method, that has been fixed to support holes, and that is implemented with
> the new containsSingle private method.
> Some more simple methods have been implemented in the SHAPE_POLY_SET class:
> HasHoles method, which was declared but not defined and PointOnEdge, which
> is basically a loop over the SHAPE_LINE_CHAIN::PointOnEdge method.
> A tests folder has been added to the project directory structure (the main
> CMakeFile.txt was also modified in order to handle this new directory).  As
> a new developer in the project I missed there were some kind of standard
> test suite in KiCAD to be used; hopefully, Michele showed to me at CERN how
> he was doing his tests (thank you!), so this is based on his files. I think
> we should make sure that in the not so distant future we add some standard
> test suite to the project; maybe not this one, as I think you wanna get rid
> of Boost library and these tests are based on Boost Test; anyway, I think
> this could be a good idea for the project.
> The tests folder I added contains the following new files:
>
> CMakeLists.txt: it creates a new MyTests executable inside the tests
> directory.
> module.cpp: Defines the Boost test module.
> fixtures.h: Defines common data for the tests to check the methods.
> chamfer_fillet_test.cpp: Defines unity tests to check the CPolyLine ->
> SHAPE_POLY_SET refactor did not change the previous behaviour.
> collision_test.cpp: Defines unity tests to check the implementation of the
> methods HasHoles, PointOnEdge, Contains and Collide works well.
>
> Wayne, please, review these code changes and let me know if there is
> anything wrong or something I can improve for the future work :)
>
> Looking forward to hear from you, guys!
>
> Regards,
> Alejandro
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>


buggy-zone-fill-rendering.kicad_pcb
Description: Binary data
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : 

Re: [Kicad-developers] 4.0.3 stable release last call.

[Nick Østergaard]

Thank you. I will notify the the translators and make sure everything
is as good as it gets.

2016-07-22 15:12 GMT+02:00 Wayne Stambaugh :
> I planned on tagging it some time today but since you asked, I just went
> ahead and tagged stable version r6297 as 4.0.3.  This is the official
> notice for our packagers, doc devs, and translators to make whatever
> final preparations you need for the 4.0.3 release.  Two weeks should be
> enough time to get things in order to announce the official release.
> Please let me know if you need more time than that.
>
> Thanks,
>
> Wayne
>
> On 7/22/2016 8:52 AM, Adam Wolf wrote:
>> Hi Wayne,
>>
>> How are things on 4.0.3?
>>
>> Adam Wolf
>>
>> On Tue, Jul 12, 2016 at 2:30 AM, Fabrizio Tappero
>> > wrote:
>>
>> Hi Wayne,
>> Sure, no worries. Could you please give me an idea about when these
>> icons will make it to the KiCad stable release?
>>
>> Cheers
>> Fabrizio
>>
>>
>> On Mon, Jul 11, 2016 at 2:22 PM, Wayne Stambaugh
>> > wrote:
>>
>> Fabrizio,
>>
>> For the stable release, I want to keep the current icons.  Good,
>> bad or
>> otherwise, users are used to them in the stable release.  Since
>> we are
>> working on some user experience improvements for the next stable
>> release, I think that is the time to spring new icons on the users.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 7/10/2016 12:47 PM, Fabrizio Tappero wrote:
>> > Hi Wayne,
>> > would it be possible to include the 4 new main kicad icons in this
>> > release? I will need two more days to finish them up and maybe few 
>> days
>> > to update the english documentation to sync the changes.
>> >
>> > cheers
>> > Fabrizio
>> >
>> >
>> > On Sat, Jul 9, 2016 at 6:07 PM, Wayne Stambaugh 
>> 
>> > >> wrote:
>> >
>> > I'm making one last call for any last bug fixes for the 
>> version 4 stable
>> > branch before I tag 4.0.3.  If you are working on anything or 
>> know of
>> > anything that could be a show stopper, please let me know.  I 
>> hope to
>> > tag 4.0.3 early next week to give our doc devs and translators 
>> a chance
>> > to make any last changes before I roll out 4.0.3 and make the
>> > announcement.
>> >
>> > 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
>> >
>> >
>>
>>
>>
>> ___
>> Mailing list: https://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] CvPcb window

[Nick Østergaard]

2016-07-14 21:10 GMT+02:00 jp charras <jp.char...@wanadoo.fr>:
> Le 14/07/2016 à 20:49, Wayne Stambaugh a écrit :
>> On 7/14/2016 12:53 PM, Nick Østergaard wrote:
>>> Hi
>>>
>>> What was the incentive for this change?
>>
>> Usability.  We have repeatedly been beat over the head about our library
>> object selection UI design.  The goal is to design a filtered library
>> tree view that can be used in CvPcb, footprint editor, component editor,
>> footprint selection dialog, and component selection dialog.  This would
>> present a consistent library object selection paradigm to the user
>> rather than the multitude of designs we currently have.  It uses Henner
>> and Chris's filtering code along with a base tree control that could
>> include other filtering options.  Ideally it would be extended to
>> include drag and drop for library management.  We are currently
>> exploring proof of concept right now but we are by no means bound to a
>> tree control although it seems like the best fit given the library data
>> model.
>>
>>> Why is there listed a number in front of the parts in the tree?
>>> Would it be possible to make the panes not fixed width?
>>
>> I don't know why I didn't think of it before but a preview pane below
>> the tree control would be useful.  Opening up yet another window to view
>> the footprint is annoying.
>>
>
> Why do not use the left side area freed by the library list to show both the 
> footprint preview panel
> and the 3D view panel?
>
> Altium does that, and this is not so bad.
>
> No need to have a large area to display the shapes.
>
It might be advantageous to also display some of the properties of the
footprint, like is done for the schematic symbols in Henner's dialog
for eeschema. This becomes three things to display if possible;
footprint view, 3d view, properties.

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

Re: [Kicad-developers] CvPcb window

[Nick Østergaard]

Hi

What was the incentive for this change?
Why is there listed a number in front of the parts in the tree?
Would it be possible to make the panes not fixed width?

2016-07-13 12:03 GMT+02:00 Michele Castellana :
> Hello,
>
> just to be more clear with respect to the previous email: this is a simple
> sketch of how it should look like in the near future.
> It has been implemented just to receive a first feedback in order to
> understand if there is something to improve in terms of usability.
>
> Thanks,
> Michele.
>
>
> On 13/07/16 10:49, Michele Castellana wrote:
>
> Hello,
>
> I have pushed a branch to change the existing 3-columns CvPcb window with a
> new tree-based one [1].
> When you get a chance, please, test/review it and let me know if you find
> anything wrong.
>
> Thanks,
> Michele.
>
> [1] https://code.launchpad.net/~michele-castellana/kicad/new_tree_view
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>

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

Re: [Kicad-developers] KiCad New Main Icon proposal

[Nick Østergaard]

What happened to the icons proposed earlire?

https://lists.launchpad.net/kicad-developers/msg18155.html

2016-07-10 20:04 GMT+02:00 Fabrizio Tappero :
> thanks Simon,
> I get you point. Will do my best to fix this issue.
>
> cheers
> Fabrizio
>
> On Sat, Jul 9, 2016 at 12:09 AM, Simon Wells  wrote:
>>
>> just in regards to the footprint icon, one potential issue i see with
>> it is its very similar to the 3d module icon as seen in cvpcb, which
>> could confuse some new users. could you not have a footprint (either
>> in real world-ish colours or in pcbnew colours) a dip-6 and/or a
>> soic-6 could be used and have the pads/silk/mask etc... and maybe a
>> refdes?
>>
>> Not sure if i am making sense, but i am also not a designer :)
>>
>> On Fri, Jul 8, 2016 at 7:26 PM, Trygve Laugstøl  wrote:
>> > On 07. juli 2016 17:44, Eldar Khayrullin wrote:
>> >>
>> >> Sorry, I forgot to attach.
>> >
>> >
>> > I really like this style of icons. Much less clutter and a single symbol
>> > instead of a full picture.
>> >
>> > --
>> > Trygve
>> >
>> >>
>> >> В Четверг, 7 июл. 2016 в 6:23 , Simon Wells 
>> >> написал:
>> >>>
>> >>> i agree, the footprint and symbol icons are nice, however i also think
>> >>> the page and the pen in the schematic/pcbnew icons are unnecessary,
>> >>> Simon On Fri, Jul 8, 2016 at 2:58 AM, Marco Ciampa > >>> > wrote:
>> >>>
>> >>> On Thu, Jul 07, 2016 at 04:06:37PM +0200, Fabrizio Tappero wrote:
>> >>>
>> >>> Hello, Following and integrating the feedback from all you
>> >>> guys, here we have some new main kicad icons. Looks is still
>> >>> not completely polished. To make Wayne happy I have even
>> >>> included a pretty pen in some main icons ! ;-)
>> >>>
>> >>> my 0.0002 cents In my humble opinion, either the pen is drawn
>> >>> as in the act of writing (as it was for old KiCad icons and is
>> >>> Openstreetmap JOSM for an example: https://josm.openstreetmap.de/)
>> >>> or it is just distracting... The new component and footprint icons
>> >>> are great though... -- Marco Ciampa I know a joke about UDP, but
>> >>> you might not get it.  GNU/Linux User
>> >>> #78271 FSFE fellow #364 
>> >>> ___ Mailing list:
>> >>> https://launchpad.net/~kicad-developers Post to :
>> >>> kicad-developers@lists.launchpad.net
>> >>>  Unsubscribe :
>> >>> https://launchpad.net/~kicad-developers More help :
>> >>> https://help.launchpad.net/ListHelp
>> >>>
>> >>> ___ Mailing list:
>> >>> https://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] 3D-Viewer - Request for merge evaluation

[Nick Østergaard]

Ok, I just wanted to know if I had to update wx for the windows builds.

2016-06-24 12:31 GMT+02:00 Collin Anderson :
> Antialiasing is not dependent on wx.  wx doesn't actually need to support or 
> not support it.  The bug in question is that wx doesn't really ask the driver 
> if multisampling (antialiasing) is supported the way windows wants, so it 
> incorrectly repots that it doesn't work.
>
> However, antialiasing/multisampling is entirely the domain of the driver.  
> Many drivers (at least windows one, such as if you install Catalyst Control 
> Center in windows for example) allow you to override applications that ask 
> for a nonmultisampled context.  Basically, wx takes what the driver gives it 
> (as does everything else) so if the context is multisampled, it is 
> multisampled.  It's not something wx really has the option of supporting or 
> not supporting.  In this case, only the check to see if it is supported is 
> broken.
>
> That said, virtually every driver that supports MSAA (multisample 
> anti-aliasing) also has it turned on by default.  Honestly, just letting the 
> driver give the context it gives is a perfectly valid solution.  Often, there 
> will only be code that is there specifically to turn MSAA off (for 
> performance, if needed) but it won't ever be explicitly turned on.
> --
> "Violence is the last refuge of the incompetent." - Isaac Asimov
>
>> On Jun 24, 2016, at 3:43 AM, Mário Luzeiro  wrote:
>>
>>> What version of wx is required to make anti-aliasing work on windows?
>>
 I found that (anti-aliasing) was an issue on wxGLCanvas (see wxMSW FIXES):
 http://trac.wxwidgets.org/ticket/16909
>>
>> Hi Nick,
>>
>> I don't know, I have no knowledge to follow that ticket in the link and see 
>> where it was applied.
>> Anyway, as I explain on my last email to JP, I changed the source code so I 
>> hope that your GPU driver will able to decide what is best, or you can force 
>> it to use max quality.
>> I tested on my 2 windows machines and it works for me. == anti-aliasing is 
>> working (provide that I set it on the GPU driver configurations)
>>
>> Mario
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>

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

Re: [Kicad-developers] 3D-Viewer - Request for merge evaluation

[Nick Østergaard]

Den 24/06/2016 01.59 skrev "Mário Luzeiro" :
>
> Hi Jean-Pierre,
>
> From what I learn (web), it looks the GL context was not created.
> That may be because I was forcing the use of a anti-aliasing option
(maybe not supported by your GPU?)
> I "revert" the code that was doing the proper checks, however, that means
there will be no anti-aliasing (on Windows) for some? people :/
>

What version of wx is required to make anti-aliasing work on windows?

> I found that (anti-aliasing) was an issue on wxGLCanvas (see wxMSW FIXES):
> http://trac.wxwidgets.org/ticket/16909
> Maybe also your new wxWidget version is dealing with that in a different
way.
>
> Hope this change doesn't break other systems (Wayne)
>
> Let me know how it behaves,
> Regards,
> Mario Luzeiro
> 
> From: jp charras [jp.char...@wanadoo.fr]
> Sent: 23 June 2016 19:34
> To: Mário Luzeiro; joanthespa...@gmail.com
> Cc: kicad-developers@lists.launchpad.net
> Subject: Re: [Kicad-developers] 3D-Viewer - Request for merge evaluation
>
> Le 23/06/2016 à 19:11, Mário Luzeiro a écrit :
> > Hi Nick, Jean-Pierre, Maurice, Joan,
> >
> > I fixed on my branch some of your reported issues and suggestions,
please see below.
> >
>
> Hi, Mario.
>
> With your latest version, I have a new endless error message "Missing GL
version", and I cannot run
> the 3D viewer.
>
> Sorry.
>
>
> --
> Jean-Pierre CHARRAS
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] kicad osx builds 2016-06-02

[Nick Østergaard]

Adam, please reread. Or did I misunderstand it?

2016-06-23 23:43 GMT+02:00 Adam Wolf :
> Good to know.  The stable release is ready on my side, nightlies are running
> again, the 3D test builds are going... Now to get cracking on some bugs!
>
>
> On Thu, Jun 23, 2016, 4:35 PM Simon Wells  wrote:
>>
>> Hey Adam,
>>
>> Just tested the latest nightly and am still getting the cvpcb crash
>>
>> Simon
>>
>> On Sun, Jun 19, 2016 at 2:46 PM, Simon Wells  wrote:
>> > well to clarify only on your 2nd of june nightly, all the others work
>> > fine
>> >
>> > On Sun, Jun 19, 2016 at 2:45 PM, Simon Wells  wrote:
>> >> only on your builds, works fine on my builds
>> >>
>> >> On Sun, Jun 19, 2016 at 2:31 PM, Adam Wolf
>> >>  wrote:
>> >>> I was trying to see if the issue is in the packaging/packaging
>> >>> environment,
>> >>> or in the code.
>> >>>
>> >>> Can you reproduce it on the posted builds only or on builds you make
>> >>> too?
>> >>>
>> >>>
>> >>> On Sat, Jun 18, 2016, 9:21 PM Simon Wells  wrote:
>> 
>>  I can reproduce it here, So i have tested 6775 nightly which works
>>  fine, stable -rc7 also works fine here. Are you unable to reproduce
>>  the issue?
>> 
>>  On Sun, Jun 19, 2016 at 1:31 PM, Adam Wolf
>>   wrote:
>>  > Thanks!  I'll take a look--any chance we can have the user try the
>>  > latest
>>  > nightlies before that, the ones from May?
>>  >
>>  > Adam Wolf
>>  >
>>  > On Sat, Jun 18, 2016 at 6:34 AM, Simon Wells 
>>  > wrote:
>>  >>
>>  >> Hi Adam,
>>  >>
>>  >> Had someone report to me that cvpcb in the "latest" nightly (aka
>>  >> 2016-06-02) is consistently crashing in cvpcb likely related to
>>  >> the
>>  >> github plugin. Attached is crash log.
>>  >>
>>  >> I can't remember any changes over the last 22 days that
>>  >> have/should
>>  >> have solved this,
>>  >>
>>  >> Application: kicad
>>  >> Version: (2016-06-02 BZR 6871)-product, release build
>>  >> Libraries: wxWidgets 3.0.2
>>  >>libcurl/7.43.0 SecureTransport zlib/1.2.5
>>  >> Platform: Mac OS X (Darwin 15.5.0 x86_64), 64 bit, Little endian,
>>  >> wxMac
>>  >> - Build Info -
>>  >> wxWidgets: 3.0.2 (UTF-8,STL containers,compatible with 2.8)
>>  >> Boost: 1.57.0
>>  >> Curl: 7.43.0
>>  >> KiCad - Compiler: Clang 7.0.0 with C++ ABI 1002
>>  >> Settings: USE_WX_GRAPHICS_CONTEXT=ON
>>  >>   USE_WX_OVERLAY=ON
>>  >>   KICAD_SCRIPTING=ON
>>  >>   KICAD_SCRIPTING_MODULES=ON
>>  >>   KICAD_SCRIPTING_WXPYTHON=ON
>>  >>   USE_FP_LIB_TABLE=HARD_CODED_ON
>>  >>   BUILD_GITHUB_PLUGIN=ON
>>  >>
>>  >>
>>  >> it doesn't crash on self-builds which have the following version
>>  >> info
>>  >>
>>  >> Application: kicad
>>  >> Version: (2016-06-14 BZR 6933)-product, release build
>>  >> Libraries: wxWidgets 3.0.2
>>  >>libcurl/7.43.0 SecureTransport zlib/1.2.5
>>  >> Platform: Mac OS X (Darwin 15.5.0 x86_64), 64 bit, Little endian,
>>  >> wxMac
>>  >> - Build Info -
>>  >> wxWidgets: 3.0.2 (UTF-8,STL containers,compatible with 2.8)
>>  >> Boost: 1.60.0
>>  >> Curl: 7.43.0
>>  >> KiCad - Compiler: Clang 7.3.0 with C++ ABI 1002
>>  >> Settings: USE_WX_GRAPHICS_CONTEXT=ON
>>  >>   USE_WX_OVERLAY=ON
>>  >>   KICAD_SCRIPTING=ON
>>  >>   KICAD_SCRIPTING_MODULES=ON
>>  >>   KICAD_SCRIPTING_WXPYTHON=ON
>>  >>   USE_FP_LIB_TABLE=HARD_CODED_ON
>>  >>   BUILD_GITHUB_PLUGIN=ON
>>  >
>>  >
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>

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

Re: [Kicad-developers] 3D viewer broken on 32 bit windows.

[Nick Østergaard]

Den 23/06/2016 16.19 skrev "Wayne Stambaugh" <stambau...@gmail.com>:
>
> On 6/23/2016 10:13 AM, Nick Østergaard wrote:
> >
> > Den 23/06/2016 15.52 skrev "Wayne Stambaugh" <stambau...@gmail.com
> > <mailto:stambau...@gmail.com>>:
> >>
> >> On 6/23/2016 9:49 AM, Mário Luzeiro wrote:
> >> > Hi Wayne,
> >> >
> >> > Is that on the KiCad main branch?
> >>
> >> Yes
> >>
> >> > Do you experienced the same on my branch?
> >>
> >> I did not test the 32 bit build of your branch.  I will try to test it
> >> today or tomorrow and let you know.
> >>
> >> >
> >> > As far as I was following the changed on 3d-viewer on main branch, I
> > am not aware of any major change.
> >> > The only thing I have in mind that may be causing this type of
> > issues could be the OpenGL context implemented by Orson recently (that
> > is also used on 3D-Viewer).
> >> > (Orson did lots of changes / commits, make sure the source tree is
> > updated)
> >> >
> >> > I have no Windows 32 to test it, but I just build it (the main
> > branch) today and works for me on a Windows 7 64 bit.
> >>
> >> 32 bit windows is the only platform I'm having issues with.  The 64 bit
> >> Linux and windows builds are fine.
> >
> > Are you testing the i386 msys2 build on a 32 bit or 64 bit windows
system?
>
> Both my 7 and 10 versions of windows are 64 bits.  I don't have access
> to a 32 bit windows any longer without using a VM.  I guess I will have
> to set one up if no one else out there has a 32 bit windows machine that
> they can verify this on.  It would be useful to know if the same
> behavior occurs on 32 bit windows.  I'm guessing most 64-bit windows
> users will download the mingw64 build of kicad so it may not be a big
> issue but I'm sure someone else will get bit by it if I have.
>

Ok, i just wanted to make sure that we are supposed to be able to see the
prolem on our 64 bit windows.

> >
> >> >
> >> > Mario
> >> > 
> >> > From: Kicad-developers
> > [kicad-developers-bounces+mrluzeiro=ua...@lists.launchpad.net
> > <mailto:ua...@lists.launchpad.net>] on behalf of Wayne Stambaugh
> > [stambau...@gmail.com <mailto:stambau...@gmail.com>]
> >> > Sent: 23 June 2016 00:11
> >> > To: KiCad Developers
> >> > Subject: [Kicad-developers] 3D viewer broken on 32 bit windows.
> >> >
> >> > I think this may be the same issue as JP is seeing but every time I
> >> > launch the 3D viewer on 32 bit windows builds (msys2/ming32), it
either
> >> > hangs indefinitely with a blank canvas and a busy cursor on 64 bit
> >> > Windows 7 or crashes almost immediately after being launched with the
> >> > same blank canvas and busy cursor on 64 bit windows 10.  This
situation
> >> > really needs to be addressed.  Can one of our resident 3D viewer
experts
> >> > please take a look at this?
> >> >
> >> > Thanks,
> >> >
> >> > Wayne
> >> >
> >> > ___
> >> > Mailing list: https://launchpad.net/~kicad-developers
> >> > Post to : kicad-developers@lists.launchpad.net
> > <mailto:kicad-developers@lists.launchpad.net>
> >> > Unsubscribe : https://launchpad.net/~kicad-developers
> >> > More help   : https://help.launchpad.net/ListHelp
> >> >
> >>
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to : kicad-developers@lists.launchpad.net
> > <mailto:kicad-developers@lists.launchpad.net>
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> More help   : https://help.launchpad.net/ListHelp
> >
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] 3D viewer broken on 32 bit windows.

[Nick Østergaard]

Den 23/06/2016 15.52 skrev "Wayne Stambaugh" :
>
> On 6/23/2016 9:49 AM, Mário Luzeiro wrote:
> > Hi Wayne,
> >
> > Is that on the KiCad main branch?
>
> Yes
>
> > Do you experienced the same on my branch?
>
> I did not test the 32 bit build of your branch.  I will try to test it
> today or tomorrow and let you know.
>
> >
> > As far as I was following the changed on 3d-viewer on main branch, I am
not aware of any major change.
> > The only thing I have in mind that may be causing this type of issues
could be the OpenGL context implemented by Orson recently (that is also
used on 3D-Viewer).
> > (Orson did lots of changes / commits, make sure the source tree is
updated)
> >
> > I have no Windows 32 to test it, but I just build it (the main branch)
today and works for me on a Windows 7 64 bit.
>
> 32 bit windows is the only platform I'm having issues with.  The 64 bit
> Linux and windows builds are fine.

Are you testing the i386 msys2 build on a 32 bit or 64 bit windows system?

> >
> > Mario
> > 
> > From: Kicad-developers [kicad-developers-bounces+mrluzeiro=
ua...@lists.launchpad.net] on behalf of Wayne Stambaugh [
stambau...@gmail.com]
> > Sent: 23 June 2016 00:11
> > To: KiCad Developers
> > Subject: [Kicad-developers] 3D viewer broken on 32 bit windows.
> >
> > I think this may be the same issue as JP is seeing but every time I
> > launch the 3D viewer on 32 bit windows builds (msys2/ming32), it either
> > hangs indefinitely with a blank canvas and a busy cursor on 64 bit
> > Windows 7 or crashes almost immediately after being launched with the
> > same blank canvas and busy cursor on 64 bit windows 10.  This situation
> > really needs to be addressed.  Can one of our resident 3D viewer experts
> > please take a look at this?
> >
> > Thanks,
> >
> > Wayne
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] 3D-Viewer - Request for merge evaluation

[Nick Østergaard]

I think you should test another thing on windows too. I just tested
with 6112 on  both windows and linux. On linux this thing is good, but
on windows it is not so nice.

Be in opengal rendering mode. I guess that the render thickness should
be enabled. Hit the oneshot raytrace button.  Then the opengl picture
seems to refresk every time there is a new raytrace thing refreshing.
It looks like the opengl image is switching between the render with
thickness image and render without thickness.

2016-06-23 0:22 GMT+02:00 Nick Østergaard <oe.n...@gmail.com>:
> 2016-06-23 0:07 GMT+02:00 Mário Luzeiro <mrluze...@ua.pt>:
>> Hi Nick,
>>
>> I cannot experience that on Linux, I will try on Windows latter.
>
> I tested on archlinux.
>
>>
>>> to avoid this transient artifact?
>> that means it is a transient ? It recover back? Or does it stays all the 
>> time after that black?
>> Does the GAL still works and the 3D-viewer windows?
>> What if you open another footprint?
>
> I guess I forgot to add after "...that was in pcbnew itself."  That it
> will render the proper 3d image after about a second or so. The same
> amount of time it takes to switch to the 3D settings tab initially.
>
>>
>> What is your system? ;) (Windows? wxwidget version?)
>
> Archlinux, wx 3.0.2
>
>>
>> Thanks for reporting,
>> Mario
>> 
>> From: Nick Østergaard [oe.n...@gmail.com]
>> Sent: 22 June 2016 22:20
>> To: Mário Luzeiro
>> Cc: kicad-developers@lists.launchpad.net
>> Subject: Re: [Kicad-developers] 3D-Viewer - Request for merge evaluation
>>
>> Hi Mario
>>
>> I have noticed someting new.
>>
>> When I hit edit on a footprint, then switch to the 3D Settings tab it
>> will freeze briefly until the 3D preview is assembled. Ok. Then I
>> close the dialog on cancel. Then I open it again on the same footprint
>> and it now shows the 3D Settings tab directly instead of the
>> Properties tab, but now it is seen that the content in the 3D preview
>> is the image on the screen from the Opengal (GAL) canvas that was in
>> pcbnew itself. Maybe the 3D preview need to initialize a black canvas
>> to avoid this transient artifact?
>>
>> Nick

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

Re: [Kicad-developers] 3D-Viewer - Request for merge evaluation

[Nick Østergaard]

2016-06-23 0:07 GMT+02:00 Mário Luzeiro <mrluze...@ua.pt>:
> Hi Nick,
>
> I cannot experience that on Linux, I will try on Windows latter.

I tested on archlinux.

>
>> to avoid this transient artifact?
> that means it is a transient ? It recover back? Or does it stays all the time 
> after that black?
> Does the GAL still works and the 3D-viewer windows?
> What if you open another footprint?

I guess I forgot to add after "...that was in pcbnew itself."  That it
will render the proper 3d image after about a second or so. The same
amount of time it takes to switch to the 3D settings tab initially.

>
> What is your system? ;) (Windows? wxwidget version?)

Archlinux, wx 3.0.2

>
> Thanks for reporting,
> Mario
> 
> From: Nick Østergaard [oe.n...@gmail.com]
> Sent: 22 June 2016 22:20
> To: Mário Luzeiro
> Cc: kicad-developers@lists.launchpad.net
> Subject: Re: [Kicad-developers] 3D-Viewer - Request for merge evaluation
>
> Hi Mario
>
> I have noticed someting new.
>
> When I hit edit on a footprint, then switch to the 3D Settings tab it
> will freeze briefly until the 3D preview is assembled. Ok. Then I
> close the dialog on cancel. Then I open it again on the same footprint
> and it now shows the 3D Settings tab directly instead of the
> Properties tab, but now it is seen that the content in the 3D preview
> is the image on the screen from the Opengal (GAL) canvas that was in
> pcbnew itself. Maybe the 3D preview need to initialize a black canvas
> to avoid this transient artifact?
>
> Nick

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

Re: [Kicad-developers] 3D-Viewer - Request for merge evaluation

[Nick Østergaard]

Ohh ok, can we have tooltips on the buttons?

2016-06-23 0:03 GMT+02:00 Mário Luzeiro <mrluze...@ua.pt>:
> Hi Nick,
>
> sorry I didn't get. You mean that button in the Footprint->3D settings 
> preview?
> That "refresh" button.. is for Reload the preview board.
> For example if (lets say..) the footprint was changed or for example the 3D 
> models (external files) were changed and need to be reloaded.
> It may be useful if someone is external editing the 3D files at same time 
> that is making changes there.
>
> Mario
>
> ____
> From: Nick Østergaard [oe.n...@gmail.com]
> Sent: 22 June 2016 22:21
> To: Mário Luzeiro
> Cc: kicad-developers@lists.launchpad.net
> Subject: Re: [Kicad-developers] 3D-Viewer - Request for merge evaluation
>
> Additionally I can't figure out what the bottom left button is for the
> preview. It is rendered as two circular arrows on my screen. i can't
> see the view changing when I click it.

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

Re: [Kicad-developers] 3D-Viewer - Request for merge evaluation

[Nick Østergaard]

Additionally I can't figure out what the bottom left button is for the
preview. It is rendered as two circular arrows on my screen. i can't
see the view changing when I click it.

2016-06-22 23:20 GMT+02:00 Nick Østergaard <oe.n...@gmail.com>:
> Hi Mario
>
> I have noticed someting new.
>
> When I hit edit on a footprint, then switch to the 3D Settings tab it
> will freeze briefly until the 3D preview is assembled. Ok. Then I
> close the dialog on cancel. Then I open it again on the same footprint
> and it now shows the 3D Settings tab directly instead of the
> Properties tab, but now it is seen that the content in the 3D preview
> is the image on the screen from the Opengal (GAL) canvas that was in
> pcbnew itself. Maybe the 3D preview need to initialize a black canvas
> to avoid this transient artifact?
>
> Nick
>
> 2016-06-19 22:36 GMT+02:00 Nick Østergaard <oe.n...@gmail.com>:
>> 2016-06-19 20:09 GMT+02:00 Mário Luzeiro <mrluze...@ua.pt>:
>>> Hi Nick,
>>>
>>> Thanks for the comments.
>>>
>>>
>>>> It seems that it cannot abort while performing the post processing shader.
>>>
>>> True, but.. What CPU do you have?
>>
>> Intel(R) Core(TM) i5 CPU   M 540  @ 2.53GHz
>>
>> That is a two core cpu with hyperthreading of 4.
>>
>>> It should take just hundreds of ms ... up to <1s depending on many cores 
>>> you have.
>>>
>>
>> It takes about a second. If I time it manually I get about 1.4 to 1.5
>> seconds, by looking at the status bar. I can even make it three to
>> five seconds. Same board, just zoomed in. It is not a complex board,
>> it just contains a few footprints, a three VRML models and a STEP
>> model.
>>
>>>
>>>> When in opengl mode and you hit the render button, it will show the lowres 
>>>> raytrace.
>>>> I think it might be better to keep showing the last opengl image instead 
>>>> of the lowres raytrace, maybe.
>>>
>>> I implemented that suggestion, check my latest branch updates.
>>>
>>
>> That feels way better.
>>
>>>
>>>> Also, there is a black border when in raytracing mode.
>>>> When I resize the window it will short of change in jumps.
>>>> I assume this is because you have a "discrete" size for the image itself.
>>>> Is this something you plan to change/fix?
>>>
>>> At this moment it is not an easy change.
>>> But with your previous suggestion and some other changes I did (in 
>>> raytracing mode preview) it may looks more OK.
>>>
>>> The render is optimized in ray packages. One possible solution will be in 
>>> future to render to a bigger than screen buffer resolution, then draw that 
>>> buffer on the windows. That will waste some computation but should be OK.
>>>
>>
>> I think that will be a sane solution. I don't mind too much, I just
>> noticed the behaivour.
>>
>>> Anyway... a black frame is something that increase the value price of your 
>>> picture ;)
>>
>> I think it needs to be a frame of gold leafs. :P
>>
>>>
>>> Mario
>>>
>>> 
>>> From: Nick Østergaard [oe.n...@gmail.com]
>>> Sent: 18 June 2016 13:08
>>> To: Mário Luzeiro
>>> Cc: Cirilo Bernardo; Chris Pavlina; kicad-developers@lists.launchpad.net
>>> Subject: Re: [Kicad-developers] 3D-Viewer - Request for merge evaluation
>>>
>>> Hi Mario,
>>>
>>> I just tried to test this, and I will comment a bit.
>>>
>>> It seems that it cannot abort while performing the post processing shader.
>>>
>>> When in opengl mode and you hit the render button, it will show the lowres 
>>> raytrace. I think it might be better to keep showing the last opengl image 
>>> instead of the lowres raytrace, maybe.
>>>
>>> Also, there is a black border when in raytracing mode. When I resize the 
>>> window it will short of change in jumps. I assume this is because you have 
>>> a "discrete" size for the image itself. Is this something you plan to 
>>> change/fix?

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

Re: [Kicad-developers] 3D-Viewer - Request for merge evaluation

[Nick Østergaard]

Hi Mario

I have noticed someting new.

When I hit edit on a footprint, then switch to the 3D Settings tab it
will freeze briefly until the 3D preview is assembled. Ok. Then I
close the dialog on cancel. Then I open it again on the same footprint
and it now shows the 3D Settings tab directly instead of the
Properties tab, but now it is seen that the content in the 3D preview
is the image on the screen from the Opengal (GAL) canvas that was in
pcbnew itself. Maybe the 3D preview need to initialize a black canvas
to avoid this transient artifact?

Nick

2016-06-19 22:36 GMT+02:00 Nick Østergaard <oe.n...@gmail.com>:
> 2016-06-19 20:09 GMT+02:00 Mário Luzeiro <mrluze...@ua.pt>:
>> Hi Nick,
>>
>> Thanks for the comments.
>>
>>
>>> It seems that it cannot abort while performing the post processing shader.
>>
>> True, but.. What CPU do you have?
>
> Intel(R) Core(TM) i5 CPU   M 540  @ 2.53GHz
>
> That is a two core cpu with hyperthreading of 4.
>
>> It should take just hundreds of ms ... up to <1s depending on many cores you 
>> have.
>>
>
> It takes about a second. If I time it manually I get about 1.4 to 1.5
> seconds, by looking at the status bar. I can even make it three to
> five seconds. Same board, just zoomed in. It is not a complex board,
> it just contains a few footprints, a three VRML models and a STEP
> model.
>
>>
>>> When in opengl mode and you hit the render button, it will show the lowres 
>>> raytrace.
>>> I think it might be better to keep showing the last opengl image instead of 
>>> the lowres raytrace, maybe.
>>
>> I implemented that suggestion, check my latest branch updates.
>>
>
> That feels way better.
>
>>
>>> Also, there is a black border when in raytracing mode.
>>> When I resize the window it will short of change in jumps.
>>> I assume this is because you have a "discrete" size for the image itself.
>>> Is this something you plan to change/fix?
>>
>> At this moment it is not an easy change.
>> But with your previous suggestion and some other changes I did (in 
>> raytracing mode preview) it may looks more OK.
>>
>> The render is optimized in ray packages. One possible solution will be in 
>> future to render to a bigger than screen buffer resolution, then draw that 
>> buffer on the windows. That will waste some computation but should be OK.
>>
>
> I think that will be a sane solution. I don't mind too much, I just
> noticed the behaivour.
>
>> Anyway... a black frame is something that increase the value price of your 
>> picture ;)
>
> I think it needs to be a frame of gold leafs. :P
>
>>
>> Mario
>>
>> 
>> From: Nick Østergaard [oe.n...@gmail.com]
>> Sent: 18 June 2016 13:08
>> To: Mário Luzeiro
>> Cc: Cirilo Bernardo; Chris Pavlina; kicad-developers@lists.launchpad.net
>> Subject: Re: [Kicad-developers] 3D-Viewer - Request for merge evaluation
>>
>> Hi Mario,
>>
>> I just tried to test this, and I will comment a bit.
>>
>> It seems that it cannot abort while performing the post processing shader.
>>
>> When in opengl mode and you hit the render button, it will show the lowres 
>> raytrace. I think it might be better to keep showing the last opengl image 
>> instead of the lowres raytrace, maybe.
>>
>> Also, there is a black border when in raytracing mode. When I resize the 
>> window it will short of change in jumps. I assume this is because you have a 
>> "discrete" size for the image itself. Is this something you plan to 
>> change/fix?

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

Re: [Kicad-developers] 3D-Viewer - Request for merge evaluation

[Nick Østergaard]

2016-06-20 14:45 GMT+02:00 Wayne Stambaugh :
> I had some time over the weekend to look at this and I'm satisfied with
> it although I'm not 100% sure what it buys us.  The eye candy is nice.
> The performance not so much but such is the case with povray.  My
> biggest gripe is that the povray rendering button on the toolbar doesn't
> give any feedback as to whether or not the povray rendering is enabled.

The button on the toolbar is not to toggle raytracing vs opengl, it is
just a "single shot" raytrace button.

> It would be nice if this was a toggle button rather than having to go
> into the menu to see which mode is being rendered.  Other than that, the
> only thing you need to resolve is any outstanding crash/freeze bugs
> before I would be willing to merge it into the product branch.
>
> On 6/17/2016 7:55 AM, Mário Luzeiro wrote:
>> Thank Wayne! Looking for your feedback...
>>
>> I was comparing my branch with current kicad branch and found some modules 
>> on my branch that were never tested by me.
>> Due the use of new structures related with 3d shapes information there are 
>> some changes on pcbnew.
>> They were imported from Cirilo's branch while he was working on 3d plugin 
>> refactoring. They are:
>> export_idf.cpp
>> export_vrml.cpp
>> kicad_plugin.cpp
>> legacy_plugin.cpp
>>
>> The changes handle with the new S3D_INFO structure (store 3d shape 
>> information of the footprints).
>> If anyone that is testing my branch also knows how to test this modules I 
>> appreciate.
>> Thanks,
>> Mario Luzeiro
>> 
>> From: Wayne Stambaugh [stambau...@gmail.com]
>> Sent: 14 June 2016 19:02
>> To: Mário Luzeiro; kicad-developers@lists.launchpad.net
>> Subject: Re: 3D-Viewer - Request for merge evaluation
>>
>> Mario,
>>
>> I may not have time to look at it until this weekend.  As soon as I've
>> had a chance to build and run it and look over the code, I'll let you know.
>>
>> 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

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

Re: [Kicad-developers] 3D-Viewer - Request for merge evaluation

[Nick Østergaard]

2016-06-19 20:09 GMT+02:00 Mário Luzeiro <mrluze...@ua.pt>:
> Hi Nick,
>
> Thanks for the comments.
>
>
>> It seems that it cannot abort while performing the post processing shader.
>
> True, but.. What CPU do you have?

Intel(R) Core(TM) i5 CPU   M 540  @ 2.53GHz

That is a two core cpu with hyperthreading of 4.

> It should take just hundreds of ms ... up to <1s depending on many cores you 
> have.
>

It takes about a second. If I time it manually I get about 1.4 to 1.5
seconds, by looking at the status bar. I can even make it three to
five seconds. Same board, just zoomed in. It is not a complex board,
it just contains a few footprints, a three VRML models and a STEP
model.

>
>> When in opengl mode and you hit the render button, it will show the lowres 
>> raytrace.
>> I think it might be better to keep showing the last opengl image instead of 
>> the lowres raytrace, maybe.
>
> I implemented that suggestion, check my latest branch updates.
>

That feels way better.

>
>> Also, there is a black border when in raytracing mode.
>> When I resize the window it will short of change in jumps.
>> I assume this is because you have a "discrete" size for the image itself.
>> Is this something you plan to change/fix?
>
> At this moment it is not an easy change.
> But with your previous suggestion and some other changes I did (in raytracing 
> mode preview) it may looks more OK.
>
> The render is optimized in ray packages. One possible solution will be in 
> future to render to a bigger than screen buffer resolution, then draw that 
> buffer on the windows. That will waste some computation but should be OK.
>

I think that will be a sane solution. I don't mind too much, I just
noticed the behaivour.

> Anyway... a black frame is something that increase the value price of your 
> picture ;)

I think it needs to be a frame of gold leafs. :P

>
> Mario
>
> 
> From: Nick Østergaard [oe.n...@gmail.com]
> Sent: 18 June 2016 13:08
> To: Mário Luzeiro
> Cc: Cirilo Bernardo; Chris Pavlina; kicad-developers@lists.launchpad.net
> Subject: Re: [Kicad-developers] 3D-Viewer - Request for merge evaluation
>
> Hi Mario,
>
> I just tried to test this, and I will comment a bit.
>
> It seems that it cannot abort while performing the post processing shader.
>
> When in opengl mode and you hit the render button, it will show the lowres 
> raytrace. I think it might be better to keep showing the last opengl image 
> instead of the lowres raytrace, maybe.
>
> Also, there is a black border when in raytracing mode. When I resize the 
> window it will short of change in jumps. I assume this is because you have a 
> "discrete" size for the image itself. Is this something you plan to 
> change/fix?

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

Re: [Kicad-developers] 3D-Viewer - Request for merge evaluation

[Nick Østergaard]

Hi Mario,

I just tried to test this, and I will comment a bit.

It seems that it cannot abort while performing the post processing shader.

When in opengl mode and you hit the render button, it will show the lowres
raytrace. I think it might be better to keep showing the last opengl image
instead of the lowres raytrace, maybe.

Also, there is a black border when in raytracing mode. When I resize the
window it will short of change in jumps. I assume this is because you have
a "discrete" size for the image itself. Is this something you plan to
change/fix?
Den 15/06/2016 22.40 skrev "Mário Luzeiro" :

> Hi Cirilo, Chris,
>
> As I received so many requests from you ;)
> I implemented the features similar as you describe below.
> Please update, rebuild and retry with the latest updates from my branch.
>
> I found an easy and elegant way of implement it,
> with just some minimal changes.
> It only add a small overhead time (about 1s or less on some tests I did)
>
> So, the new features are:
> - Display the progress of raytracing render.
> - If user move with the mouse it will abort the render.
> - It also works on OpenGL mode, if a raytracing render is requested and
> during the render the mouse is moved,
> it will stop the render and back to OpenGL.
> - This also may fix possible issues on some systems that make the windows
> not responding because the render took too long. Now the windows is
> refreshed periodically with the redraws.
>
> Regards,
> Mario Luzeiro
> 
> From: Cirilo Bernardo [cirilo.berna...@gmail.com]
> Sent: 15 June 2016 00:40
>
> Another possible tweak in the raytrace window is to show progress somehow.
> In SolidWorks this is done by showing a small black frame moving around as
> parts of the scene are refined. This is not essential though, only
> eyecandy,
> but it does help a little on long render jobs because the user can see that
> something is still happening.
>
>
> 
> From: Chris Pavlina [pavlina.ch...@gmail.com]
> Sent: 14 June 2016 20:15
>
> 3) Even at the faster speed, the raytracer is too slow and unresponsive.
>
> 3A) Raytracer UI responsiveness improvements. Allow the user to start
> dragging
> the PCB around even after the render has started, rather than going
> completely
> frozen during the render.
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] 3D-Viewer - Request for merge evaluation

[Nick Østergaard]

This patch seem to fix the build issues I was having with
3d-viewer/3d_rendering/3d_render_raytracing/accelerators/cbvh_pbrt.cpp
too.

2016-06-15 23:11 GMT+02:00 Chris Pavlina :
> VERY nice, I wasn't expecting that so fast! :D
>
> Attached is what I think is the "final" patch to make it build right on other
> systems. Still haven't heard back from anyone on the wxString/UTF8 thing, but 
> I
> *think* this is right, we can always change it later if not.
>
> On Wed, Jun 15, 2016 at 08:40:29PM +, Mário Luzeiro wrote:
>> Hi Cirilo, Chris,
>>
>> As I received so many requests from you ;)
>> I implemented the features similar as you describe below.
>> Please update, rebuild and retry with the latest updates from my branch.
>>
>> I found an easy and elegant way of implement it,
>> with just some minimal changes.
>> It only add a small overhead time (about 1s or less on some tests I did)
>>
>> So, the new features are:
>> - Display the progress of raytracing render.
>> - If user move with the mouse it will abort the render.
>> - It also works on OpenGL mode, if a raytracing render is requested and 
>> during the render the mouse is moved,
>> it will stop the render and back to OpenGL.
>> - This also may fix possible issues on some systems that make the windows 
>> not responding because the render took too long. Now the windows is 
>> refreshed periodically with the redraws.
>>
>> Regards,
>> Mario Luzeiro
>> 
>> From: Cirilo Bernardo [cirilo.berna...@gmail.com]
>> Sent: 15 June 2016 00:40
>>
>> Another possible tweak in the raytrace window is to show progress somehow.
>> In SolidWorks this is done by showing a small black frame moving around as
>> parts of the scene are refined. This is not essential though, only eyecandy,
>> but it does help a little on long render jobs because the user can see that
>> something is still happening.
>>
>>
>> 
>> From: Chris Pavlina [pavlina.ch...@gmail.com]
>> Sent: 14 June 2016 20:15
>>
>> 3) Even at the faster speed, the raytracer is too slow and unresponsive.
>>
>> 3A) Raytracer UI responsiveness improvements. Allow the user to start 
>> dragging
>> the PCB around even after the render has started, rather than going 
>> completely
>> frozen during the render.
>>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>

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

Re: [Kicad-developers] 3D-Viewer - Request for merge evaluation

[Nick Østergaard]

I also got build errors, with gcc on archlinux, regarding those:
error: '_mm_malloc' was not declared in this scope

From 3d-viewer/3d_rendering/3d_render_raytracing/accelerators/cbvh_pbrt.cpp

2016-06-14 22:29 GMT+02:00 Mário Luzeiro :
> Hi Chris,
>
> I only knew about 3 people (me included) that were using my branch regularly 
> and I was build / testing it on Linux/Windows.
> So it will be helpful now to have more people using it and give more 
> feedback, special on any segfault issues.
>
> Mario
>
> 
> From: Chris Pavlina [pavlina.ch...@gmail.com]
> Sent: 14 June 2016 19:13
> To: firewalker
> Cc: Mário Luzeiro; kicad-developers@lists.launchpad.net
> Subject: Re: [Kicad-developers] 3D-Viewer - Request for merge evaluation
>
> Have you been reporting the random segfaults to him? If this branch is still
> having random segfaults, then it's not ready to be merged yet in my opinion, 
> as
> that would be a regression - current 3D viewer doesn't segfault anywhere that 
> I
> know of.
>
> On Tue, Jun 14, 2016 at 09:07:48PM +0300, firewalker wrote:
>> I am using it for some time now.
>>
>> One note for the component preview. For through hole components the pcb is
>> quite larger.
>>
>> There were also some random segfaults.
>
> ___
> Mailing list: https://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] Announcement, CERN trip.

[Nick Østergaard]

Yeah, enjoy your trip and lots of Toblerone. If you eat enough of it
you will probably discover the "hidden" bear.

2016-06-13 23:32 GMT+02:00 Jon Neal :
> That's awesome!
>
> Enjoy Switzerland, I've heard nothing but awesome things about it.
>
> On Mon, Jun 13, 2016 at 11:38 AM Wayne Stambaugh 
> wrote:
>>
>> I'm am excited to announce that I will be traveling to CERN to spend a
>> full week working on KiCad.  I will arrive in Geneva on Saturday, July
>> 2nd and return on Sunday, July 10th.  If anyone in that part of the
>> world can find the time to get together, please let me know and I will
>> do my best to make it happen.
>>
>> 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
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>

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

Re: [Kicad-developers] [PATCH] Legacy: delete and force middle button pan for GAL consistency

[Nick Østergaard]

2016-06-09 20:52 GMT+02:00 Timofonic <timofo...@gmail.com>:
> I'm just a bad user but...
>
> Why isn't Legacy canvas ditched in the development branch and focus efforts 
> in the GAL one exclusively?

I think you follow the list enough to know why this is. :)

> What about OpenGL and slow in certain platforms? What OpenGL version is KiCad 
> using currently? I fail to see it. Damn, even MESA is getting OpenGL 4.3+ 
> too. Can newer OpenGL features provide performance improvements too?
>
> Windows Intel graphics are known to have an awful OpenGL implementation. 
> Would using a OGL->D3D wrapper be an issue?
>
> Would using a library like BGFX be an issue? Can the switch traits lots of 
> coding and rewriting?
>
> What are the issues to massively remove all the cruft in KiCad code and 
> develop by thinking in the future?
>
> What's going to happen with KiCad 5.0? Personally, I would prefer a new one 
> with massive usability, performance and feature improvements than another 
> small one if that slows the progress to make KiCad a lot better EDA tool for 
> the future.
>

Things takes time.

> On June 7, 2016 5:31:32 PM CEST, "Nick Østergaard" <oe.n...@gmail.com> wrote:
>>I am looking forward to "better" things :)
>>
>>2016-06-07 17:12 GMT+02:00 Chris Pavlina <pavlina.ch...@gmail.com>:
>>> Heh :)
>>>
>>> I'm working on the replacement feature. There is definitely a strong
>>argument
>>> in favor of writing the replacement before removing the original, so
>>I'm going
>>> to do that. Could be a couple days, I have to spread it out with Real
>>Work now.
>>> I promise it'll be better than what we had :)
>>>
>>> On Tue, Jun 07, 2016 at 05:08:29PM +0200, Marco Ciampa wrote:
>>>> On Tue, Jun 07, 2016 at 10:20:56AM -0400, Chris Pavlina wrote:
>>>> > Also, I really feel like I should point out - it's not feasible to
>>gather user
>>>> > input for _every change_. That's how we got to the point we're at,
>>really -
>>>> > lots of "this would be useful for _me_", so it gets thrown in, and
>>then we have
>>>> > a hodgepodge of incoherent "features" each used by one person too
>>fond of it to
>>>> > remove it.
>>>> >
>>>>
>>>> Sorry, couldn't resist: https://xkcd.com/1172/
>>>>
>>>> --
>>>>
>>>>
>>>> Marco Ciampa
>>>>
>>>> I know a joke about UDP, but you might not get it.
>>>>
>>>> 
>>>>
>>>>  GNU/Linux User #78271
>>>>  FSFE fellow #364
>>>>
>>>> 
>>>>
>>>>
>>>> ___
>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>> Post to : kicad-developers@lists.launchpad.net
>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>> ___
>>> Mailing list: https://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
>
> --
> Enviado desde mi dispositivo Android con K-9 Mail. Por favor disculpa mi 
> brevedad.
>
> ___
> Mailing list: https://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] Failed to build on my system

[Nick Østergaard]

Which exact system are you using here? Compiler and version?

2016-06-09 19:20 GMT+02:00 Mário Luzeiro :
> Hi Cirilo,
>
> With this commit:
> http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/6905
>
> I cannot build now on Linux:
>
> 3d-viewer/3d_cache/3d_filename_resolver.cpp:845: error: no matching function 
> for call to 
> ‘std::list::insert(std::list::const_iterator&, 
> S3D_ALIAS&)’
>  m_Paths.insert( sPL, lpath );
> ^
>
> It successful build on msys2 today.
>
> Is it a problem just on my system?
>
> Cheers,
> Mario
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] Python build options

[Nick Østergaard]

What about one that just enables all three, for example -DKICAD_PYTHON?

And it would enable?
-DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON -DKICAD_SCRIPTING_WXPYTHON=ON


2016-06-07 20:24 GMT+02:00 Simon Wells :
> Is there anyone who doesn't use All or None of the python build
> options? As with how codependent a lot of the code has become it seems
> pointless still having the 3 build options. Would it not be better to
> just have one saying -DKICAD_PYTHON or -DKICAD_SCRIPTING?
>
> 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

Re: [Kicad-developers] [PATCH] Legacy: delete and force middle button pan for GAL consistency

[Nick Østergaard]

I am looking forward to "better" things :)

2016-06-07 17:12 GMT+02:00 Chris Pavlina :
> Heh :)
>
> I'm working on the replacement feature. There is definitely a strong argument
> in favor of writing the replacement before removing the original, so I'm going
> to do that. Could be a couple days, I have to spread it out with Real Work 
> now.
> I promise it'll be better than what we had :)
>
> On Tue, Jun 07, 2016 at 05:08:29PM +0200, Marco Ciampa wrote:
>> On Tue, Jun 07, 2016 at 10:20:56AM -0400, Chris Pavlina wrote:
>> > Also, I really feel like I should point out - it's not feasible to gather 
>> > user
>> > input for _every change_. That's how we got to the point we're at, really -
>> > lots of "this would be useful for _me_", so it gets thrown in, and then we 
>> > have
>> > a hodgepodge of incoherent "features" each used by one person too fond of 
>> > it to
>> > remove it.
>> >
>>
>> Sorry, couldn't resist: https://xkcd.com/1172/
>>
>> --
>>
>>
>> Marco Ciampa
>>
>> I know a joke about UDP, but you might not get it.
>>
>> 
>>
>>  GNU/Linux User #78271
>>  FSFE fellow #364
>>
>> 
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>
> ___
> Mailing list: https://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] Stable release bug fixes.

[Nick Østergaard]

Sounds like sane recommendations to me. :)

2016-06-01 14:19 GMT+02:00 Wayne Stambaugh :
> I've been running into issues with merging bug fixes into the 4 stable
> branch.  This is to be expected as the code bases diverge.  However,
> some of the merge issues are due to new code being committed along with
> the bug fix which causes merge conflicts.  Please try to commit only the
> code required to fix a bug that applies to both the stable and product
> branches.  This is not an issue when fixing bugs that only apply to the
> product branch.  This makes my life a lot easier when merging the
> commits from the product branch into the stable branch.  Even better
> would be to test your commit by merging it into a local copy of the
> stable branch and verify that it merges cleanly and builds.  Also, I am
> loosing track of which fixes effect the stable branch since the bug
> reports are not always clear and sometimes there is no bug report for
> the fix.  Please either add a note in commit message that it effects the
> stable branch or send me a email with the commit number so I know to
> merge it into the stable branch.
>
> Thanks,
>
> Wayne
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] bugs Fix Commited

[Nick Østergaard]

I that that it is ok to mark as released when it was introduced and
fixed in one dev cycle. That is that it never was a bug in a release.

2016-05-31 18:12 GMT+02:00 Simon Wells :
> I know that bugs should be fix commited until a new version is
> released that has the bug fix in it. But IF a bug was only introduced
> in the product repo and subsequently fixed
>
> https://bugs.launchpad.net/kicad/+bug/1523933
>
> as seen in this bug which was Introduced in 6352 fixed in 6359 the
> version that caused the issue is just as "released" as the version
> that fixed the issue does it not make sense to mark this as fix
> released and other similar bugs
>
> 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

Re: [Kicad-developers] I'm back.

[Nick Østergaard]

Welcome back, Simon Wells havr been busy trying to clean up the bug tracker
:)
Den 26/05/2016 16.40 skrev "Wayne Stambaugh" :

> Just a quick heads up.  I'm back from vacation and sorting through my
> inbox.  Please be patient as I slog through all of them.  There are few
> things that I want to comment on.  It may take a few days until I get to
> them so please be patient.
>
> Thanks,
>
> Wayne
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Boost 1.61.0

[Nick Østergaard]

Hi

Just a heads up, Boost 1.61.0 breaks the KiCad build.

See https://bugs.launchpad.net/kicad/+bug/1584326

Regards
Nick Østergaard

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

Re: [Kicad-developers] 3D cache path

[Nick Østergaard]

I think using a max suze could problematic too. What happens if this size
is too small to even hold one single board view?

I think a time pased approach might be better, like if there exists models
that are older, say a week, then delete them if they are not part of the
current project.
Den 19/05/2016 15.53 skrev "Mário Luzeiro" <mrluze...@ua.pt>:

> You mean loading and process a model on the first time?
> On my machine (i7) I remember that a moderate models can take some seconds
> (1.. 2.. 3s) to load and process on the first time.
> So it will be noticeable for boards with lots of different models files..
> depending on the complexity of the models..
>
> On other part, loading from cache "we are talking about" milliseconds.
>
> * these values are from mind and may need confirmation! :)
>
> IMO a good feature that could be implemented latter would be to define the
> max size of the cache and keep the "recent most used" models.
>
> Mario
> 
> From: Simon Wells [swel...@gmail.com]
> Sent: 19 May 2016 14:41
> To: Mário Luzeiro
> Cc: Bernhard Stegmaier; Nick Østergaard; KiCad Developers
> Subject: Re: [Kicad-developers] 3D cache path
>
> with the current state of things how many seconds are we talking
> about? is it almost better to just use temp files and delete on close?
>
> On Fri, May 20, 2016 at 1:39 AM, Mário Luzeiro <mrluze...@ua.pt> wrote:
> > Btw,
> > On relation to the cache size, on my development tests with my branch, I
> notice it can easily reach hundreds of MBytes.
> >
> > Mario
> >
> > 
> > From: Kicad-developers [kicad-developers-bounces+mrluzeiro=
> ua...@lists.launchpad.net] on behalf of Mário Luzeiro [mrluze...@ua.pt]
> > Sent: 19 May 2016 14:32
> > To: Bernhard Stegmaier; Nick Østergaard
> > Cc: KiCad Developers
> > Subject: Re: [Kicad-developers] 3D cache path
> >
> > Hi Bernhard,
> >
> > At moment 3D cache has almost any use in the current code.
> >
> > If my branch get merged on day:
> > https://code.launchpad.net/~mrluzeiro/kicad/kicad_new3d-viewer
> > The 3D viewer will use that cached models to speed up the board loading
> (so there is no need to parse the model files and recalculate normals etc..)
> >
> > The cache is global, on accord to last Cirilo email, that will be per
> user account.
> > There is a hash function that maps the real file to the cached data,
> also it checks for file modification (Cirilo can give more details about
> it).
> >
> > Mario
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] 3D cache path

[Nick Østergaard]

I am not sure having a manual button to click to clear the cache helps a
lot... I think some autocleanup would be nice, but that does of course not
exclude a button for those people who likes to click on stuff.
Den 19/05/2016 12.09 skrev "José Ignacio" :

> +1 on a "Clear cache" button/menu item
>
> On Thu, May 19, 2016 at 3:39 AM, easyw  wrote:
> > Hi,
> > I think it would also useful to have a menu item to clean 3D cache on
> > request...
> > just to avoid having a huge caching ...
> >
> > Maurice
> >
> >
> > On 19/05/2016 05.42, Cirilo Bernardo wrote:
> >>
> >> Hi Folks,
> >>
> >>   I've had some feedback on the location of the 3D cache data on various
> >> systems.
> >> At the moment the data is in
> >> wxStandardPaths::Get().GetUserConfigDir()/kicad/3d/cache
> >> and since that's a subdir of a configuration directory I guess it's not
> >> surprising
> >> that users are not happy.
> >>
> >>  From discussion with other devs it seems to be agreed that the
> >> 3D cache data should go into:
> >>
> >> 1. OSX: ~/Library/Caches/kicad/3d
> >>  Equivalent: ${HOME}/Library/Caches/kicad/3d
> >>
> >> 2. Linux: ~/.cache/kicad/3d
> >>  Actually it should be ${XDG_CACHE_HOME}/kicad/3d with the fallback
> >>  ${HOME}/.cache/kicad/3d
> >>
> >> 3. MSWin: AppData\Local\kicad\3d
> >> wxStandardPaths::UseAppInfo( AppInfo_None );
> >> wxStandardPaths::Get().GetUserLocalDataDir();
> >> So far we have %AppData%\Local or equivalent, now we add kicad\3d
> >>
> >> Any comments/objections? If there are no objections I will create a
> patch
> >> to implement this. One drawback of course is that current users of the
> >> dev branch will have a lot of junk cache data in the old location but
> >> this is
> >> a detail which should be fixed.
> >>
> >> - Cirilo
> >>
> >>
> >>
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to : kicad-developers@lists.launchpad.net
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> More help   : https://help.launchpad.net/ListHelp
> >>
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] GerbView is very very slow to be unusable, is any one seeing this ? (build 6813 ) Linux Debian 64bit 8.3

[Nick Østergaard]

What about pcbnew in the legacy canvas?
Den 19/05/2016 09.26 skrev "Lachlan Audas" :

> GerbView is very very slow, so slow to be unusable,
> So I switch to  gerbv which works just fine is any one else  seeing this ?
> (build 6813 ) Linux Debian 64bit 8.3
>
> Lachlan
>
>
> ___
> Mailing list: https://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] Jenkins build is back to normal : linux-kicad-full-gcc-head #1265

[Nick Østergaard]

It seems like the cxx file generated by SWIG for python has been moved and
vas therefore not deleted on the buildserver.
Den 17/05/2016 16.22 skrev "Miguel Angel Ajo" :

> See 
>
>
> ___
> Mailing list: https://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] Build failed in Jenkins: KiCad (Linux, all options, Debug) #1251

[Nick Østergaard]

Jenkins operations should now be back to normal. The main build is
green, time will show if it will trigger on new commits properly.

2016-05-11 18:46 GMT+02:00 Nick Østergaard <oe.n...@gmail.com>:
> Ahh yeah, we were messing about with that some time ago. :)
>
> 2016-05-11 17:38 GMT+02:00 Jon Neal <reporting...@gmail.com>:
>> The issue is because the master jenkins node doesn't support c++11. I'm
>> wondering if we should lay out a plan to upgrade the jenkins server since it
>> is so out of date (some of our other scripts can't run on it due to things
>> like git being 5 or 6 years out of date).
>>
>> We've also started getting lots of gateway timeout errors lately which makes
>> things difficult. I can't actually update the jenkins main config any more
>> due to this.
>>
>> On Wed, May 11, 2016 at 11:31 AM Nick Østergaard <oe.n...@gmail.com> wrote:
>>>
>>> Something is wonky with the jenkins master. I will give it a look when i
>>> get home. It seems to not have built for a month on the lp:kicad branch.
>>>


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

Re: [Kicad-developers] Build failed in Jenkins: KiCad (Linux, all options, Debug) #1251

[Nick Østergaard]

Ahh yeah, we were messing about with that some time ago. :)

2016-05-11 17:38 GMT+02:00 Jon Neal <reporting...@gmail.com>:
> The issue is because the master jenkins node doesn't support c++11. I'm
> wondering if we should lay out a plan to upgrade the jenkins server since it
> is so out of date (some of our other scripts can't run on it due to things
> like git being 5 or 6 years out of date).
>
> We've also started getting lots of gateway timeout errors lately which makes
> things difficult. I can't actually update the jenkins main config any more
> due to this.
>
> On Wed, May 11, 2016 at 11:31 AM Nick Østergaard <oe.n...@gmail.com> wrote:
>>
>> Something is wonky with the jenkins master. I will give it a look when i
>> get home. It seems to not have built for a month on the lp:kicad branch.
>>
>> Den 11/05/2016 17.28 skrev "Miguel Angel Ajo" <miguelan...@ajo.es>:
>>>
>>> See <http://ci.kicad-pcb.org/job/kicad-full/1251/changes>
>>>
>>> Changes:
>>>
>>> [jean-pierre charras] Pcbnew: Fix a very minor bug ( The "Move
>>> exactly..."  sometimes truncates the saved parameter floating point values
>>> during a session)
>>>
>>> [jean-pierre charras] Fix minor bug in Modedit: Adding a new rounded rect
>>> pad to a footprint doesn't clone rectangle rounding
>>>
>>> [jean-pierre charras] Fix a few deprecated compil warnings in dialogs
>>> generated by wxformbuilder
>>>
>>> [Chris Pavlina] OS X: Disable full-screen cursor
>>>
>>> This feature cannot work reliably for reasons explained in lp:1463505.
>>> Remove
>>> the option on OS X builds and force cursor to the small one.
>>>
>>> https://bugs.launchpad.net/kicad/+bug/1463505
>>>
>>> > Bernhard Stegmaier (stegmaier) wrote on 2016-01-14:
>>> >
>>> > As far as I see from the code this is no bug but done on intention.
>>> >
>>> > The reason probably is that on OSX in the legacy canvas you don't have
>>> > the
>>> > XOR-drawing as on other platforms. To the best of my knowledge, this
>>> > would
>>> > mean that on every mouse move you would have to repaint the whole
>>> > window just
>>> > to get rid of the "old" cross.
>>> >
>>> > So, I would say this is a clear "won't fix".
>>> > We could think of just removing/disabling the button in the legacy
>>> > canvas.
>>>
>>> [Chris Pavlina] Correct handling of unused parameter
>>>
>>> Coverity: CID 143742
>>>
>>> [Chris Pavlina] Clean up dodgy array dimension
>>>
>>> Array is in pairs but has a single sentinel, trips up Coverity (CID
>>> 147346) and
>>> does allow an out-of-bounds write if WX_GL_SAMPLES were ever removed from
>>> the
>>> array.
>>>
>>> [Chris Pavlina] Remove unneeded 'new' and NULL check
>>>
>>> Coverity CID: 143743
>>>
>>> [Chris Pavlina] Fix null dereference for certain bad PCB files
>>>
>>> Coverity: CID 147344 Unchecked dynamic_cast
>>>
>>> If a file that parses validly in Parse() but does not return a BOARD is
>>> loaded,
>>> no exception will be thrown but the dynamic_cast will return NULL. This
>>> NULL
>>> is tested by wxASSERT(), which does not actually halt anything
>>> (especially in
>>> release builds), and then we proceed to board->SetFileName().
>>>
>>> This can be demonstrated quickly by renaming a .kicad_mod to .kicad_pcb
>>> and
>>> trying to load it. pcbnew will crash.
>>>
>>> [Chris Pavlina] Fix uninitialized fields
>>>
>>> Coverity: CIDs 102698, 147347, 147349, 147350
>>>
>>> [Chris Pavlina] Fix build error on some platforms from r6788
>>>
>>> r6788 = git f9386fc
>>>
>>> [Chris Pavlina] Remove "Dump zone geometry to files when filling"
>>>
>>> The code to perform the dump has not been removed, but the GUI option and
>>> global flag (ugh) have been.
>>>
>>> [Chris Pavlina] pcbnew legacy: remove option to hide via drill
>>>
>>> Via drills are now shown in all cases, matching GAL behavior, and the
>>> option no
>>> longer exists in the preferences dialog.
>>>
>>> [Chris Pavlina] Add support for PCB and footprint format versioning
>>>
>>> Currently, kicad_pcb files have a (version ...) ta

Re: [Kicad-developers] Preferences rework - pcbnew

[Nick Østergaard]

I can imagine it, but I thought it was necessary to mention the idea.
This task would be easier if we could just get rid of the legacy
canvas. But that probably can't happen immediately, as we all know.

2016-05-03 17:13 GMT+02:00 Chris Pavlina <pavlina.ch...@gmail.com>:
> Oh god no. Can you imagine the bug reports from people who can't find 
> settings?
>
> http://i3.kym-cdn.com/photos/images/newsfeed/000/727/910/577.gif
>
> On Tue, May 03, 2016 at 04:41:20PM +0200, Nick Østergaard wrote:
>> Maybe just show or enable the settings if the appropriate canvas is active?
>>
>> 2016-05-03 14:52 GMT+02:00 Wayne Stambaugh <stambau...@gmail.com>:
>> > On 5/2/2016 4:54 PM, Chris Pavlina wrote:
>> >> I'd like to start having a look at how I can organize the preferences for
>> >> pcbnew, having mostly finished in eeschema. (A few things remain to be 
>> >> tweaked
>> >> and will probably be done at the same time as pcbnew, to keep things in 
>> >> sync).
>> >>
>> >> The problem of legacy preferences vs GAL preferences needs to be 
>> >> addressed. How
>> >> do we want to handle that? At this point, I'm not sure what the timeline 
>> >> is for
>> >> actual removal of legacy - should I wait until we do that?
>> >
>> > This is most likely going to be a while so you wont be able to remove
>> > the legacy canvas settings until we completely remove the legacy canvas
>> > from the source.
>> >
>> >>
>> >> If not, I want to try to merge options as much as possible. There are some
>> >> things that are duplicated between the two, which I'd like to fix. But the
>> >> bigger question is: how should we present to the user things that are only
>> >> available in one or the other?
>> >>
>> >> I could simply make sections on the preferences pages: "Legacy canvas 
>> >> only",
>> >> "OpenGL or Cairo canvas only". That's ugly and makes me cringe, but I 
>> >> can't
>> >> think of anything better. Two separate, parallel preferences systems like 
>> >> we
>> >> have right now just won't do. Thoughts?
>> >
>> > Even though separating the settings is probably going to be ugly, it's
>> > the most prudent way to go in terms of effort.  If they are organized
>> > this way, it should be fairly easy to remove them when we finally get
>> > around to dumping the legacy canvas.
>> >
>> >>
>> >> ___
>> >> Mailing list: https://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] Bitmap fonts (+ dotted grid)

[Nick Østergaard]

2016-05-03 21:10 GMT+02:00 Bernhard Stegmaier :
> You are right.
> I didn’t expect the dots to be different, but every 10th dot is the bigger 
> one.

Exactly as is the case with the lines...

>
> BTW:
> I do seem to get a popup “OpenGL 2.1 supported” on every start recently.
> Is that on intention and what should it tell me (apart from the fact that 
> OpenGL 2.1 is supported… :) )?
> It is quite annoying… could this information maybe be moved to the About 
> dialog?
>
>
> Regards,
> Bernhard
>
>> On 03 May 2016, at 19:14, Simon Wells  wrote:
>>
>> bernhard, are the ones that are the easily visible ones the darker
>> grid lines (ever 5 or so) that are more intense in the line mode
>>
>> On Wed, May 4, 2016 at 4:27 AM, Bernhard Stegmaier
>>  wrote:
>>> Maybe some anti-aliasing issue?
>>> For me, dots are also quite small and some of them are barely visible, while
>>> others look quite normal.
>>>
>>> When I played around with the grid dots on OS X in legacy canvas I also had
>>> a hard time to find a configuration where dots are visible both on (HiDPI)
>>> retina and normal displays (on OS X also legacy canvas is anti-aliased).
>>>
>>> On 03 May 2016, at 18:20, jp charras  wrote:
>>>
>>> Le 03/05/2016 à 18:06, Bernhard Stegmaier a écrit :
>>>
>>> In the Dimensions => Grid menu you can switch between dots/lines (also took
>>> me some while, I would have expected it in some preferences dialog).
>>> I don’t think that it is a (common) wxWidgets 3.1 issue.
>>> My OS X build uses a wxWidgets master maybe two weeks old and grid is fine
>>> both with dots and lines.
>>>
>>>
>>> Thanks, Bernhard.
>>>
>>> @Orson,
>>> On wxWidgets 3.1, the dotted grid is not visible on Opengl. The line grid is
>>> visible.
>>> On Cairo, both are displayed.
>>>
>>>
>>>
>>> Regards,
>>> Bernhard
>>>
>>> On 03 May 2016, at 17:46, jp charras  wrote:
>>>
>>> Le 03/05/2016 à 15:56, Maciej Sumiński a écrit :
>>>
>>> On 05/02/2016 06:33 PM, jp charras wrote:
>>>
>>> Le 02/05/2016 à 17:16, Maciej Sumiński a écrit :
>>>
>>> As noone had opposed the changes, I have just merged the bitmap fonts
>>> branch.
>>>
>>> As a small bonus, we have also added an option to switch to dotted grid
>>> in GAL (thanks to Tom for refactoring the grid drawing routine).
>>>
>>> Regards,
>>> Orson
>>>
>>>
>>> A lot of work! Thanks to Tomasz and you.
>>>
>>> After a fast and short test, the change looks good.
>>>
>>> However, I noticed 2 issues (W7 32 bits on msys2):
>>> - The grid is not visible on OpenGL, but is visible on Cairo.
>>> - I can switch between legacy and Cairo, as long I not switched to OpenGL,
>>> but if I switch to Cairo
>>> from OpenGL, or from legacy after having previously switched to Opengl,
>>> Pcbnew crashes.
>>>
>>>
>>> Hi Jean-Pierre,
>>>
>>> Is grid invisible in both modes (lines & dots)?
>>>
>>>
>>> How to change the mode ?
>>>
>>> Nevertheless, the dot grid is not displayed when using wxWidgets 3.1, and it
>>> is displayed when using
>>> wxWidgets 3.0.2.
>>> I never see issues previously with lines.
>>>
>>>
>>> Would you send me a backtrace? I cannot make it crash on W7_64/msys2.
>>>
>>>
>>> Unfortunately, the bt is small:
>>> When switching from OpenGL to cairo:
>>> #0  0x77293c4d in ntdll!DbgBreakPoint () from C:\Windows\SYSTEM32\ntdll.dll
>>> #1  0x772febef in ntdll!DbgUiRemoteBreakin ()
>>> from C:\Windows\SYSTEM32\ntdll.dll
>>> #2  0x29813028 in ?? ()
>>> #3  0x75b0ef1c in KERNEL32!BaseThreadInitThunk ()
>>> from C:\Windows\system32\kernel32.dll
>>> #4  0x772c3648 in ntdll!RtlInitializeExceptionChain ()
>>> from C:\Windows\SYSTEM32\ntdll.dll
>>> #5  0x772c361b in ntdll!RtlInitializeExceptionChain ()
>>> from C:\Windows\SYSTEM32\ntdll.dll
>>> #6  0x in ?? ()
>>>
>>> And when existing in legacy mode (after using Opengl mode):
>>> #0  0x5628ae51 in ?? () from C:\Windows\system32\ig4icd32.dll
>>> Backtrace stopped: Cannot access memory at address 0x3
>>>
>>>
>>> More strange, when starting pcbnew (Debug build) in legacy mode and
>>> switching to Cairo more:
>>> - crash if running under gdb (giving the same backtrace as when switching
>>> from OpenGL to cairo,
>>> therefore this bt is perhaps due only to switching to cairo on gdb).
>>> - does no crash when running without gdb.
>>>
>>>
>>> Regards,
>>> Orson
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Jean-Pierre CHARRAS
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> 
>>> Post to : kicad-developers@lists.launchpad.net
>>> 
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> 
>>> More help   : https://help.launchpad.net/ListHelp
>>> 
>>>
>>>
>>>
>>>
>>> --
>>> Jean-Pierre CHARRAS
>>>
>>> ___

Re: [Kicad-developers] Preferences rework - pcbnew

[Nick Østergaard]

Maybe just show or enable the settings if the appropriate canvas is active?

2016-05-03 14:52 GMT+02:00 Wayne Stambaugh :
> On 5/2/2016 4:54 PM, Chris Pavlina wrote:
>> I'd like to start having a look at how I can organize the preferences for
>> pcbnew, having mostly finished in eeschema. (A few things remain to be 
>> tweaked
>> and will probably be done at the same time as pcbnew, to keep things in 
>> sync).
>>
>> The problem of legacy preferences vs GAL preferences needs to be addressed. 
>> How
>> do we want to handle that? At this point, I'm not sure what the timeline is 
>> for
>> actual removal of legacy - should I wait until we do that?
>
> This is most likely going to be a while so you wont be able to remove
> the legacy canvas settings until we completely remove the legacy canvas
> from the source.
>
>>
>> If not, I want to try to merge options as much as possible. There are some
>> things that are duplicated between the two, which I'd like to fix. But the
>> bigger question is: how should we present to the user things that are only
>> available in one or the other?
>>
>> I could simply make sections on the preferences pages: "Legacy canvas only",
>> "OpenGL or Cairo canvas only". That's ugly and makes me cringe, but I can't
>> think of anything better. Two separate, parallel preferences systems like we
>> have right now just won't do. Thoughts?
>
> Even though separating the settings is probably going to be ugly, it's
> the most prudent way to go in terms of effort.  If they are organized
> this way, it should be fairly easy to remove them when we finally get
> around to dumping the legacy canvas.
>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] PCBNEW B.SilkS text rotation problems, is any one working on this or have see this bugs, on (bzr 6765)

[Nick Østergaard]

I am sure this is related to pcbnew refusing to put text upside down.
Den 03/05/2016 14.36 skrev "jp charras" :

> Le 03/05/2016 à 14:18, Lachlan Audas a écrit :
> > Hi  JP,
> >
> > Try Vertical  alignment,   ie +90 and -90 .. when you on the B.SilkS
> > also so note it come's back with  -0.0   IE it prefix's the deg's with  a
> > minus sing.. in some cases.
> > try 0.0 and 0.1 deg's,  and also jumps the text to new X,Y position,  in
> > some case's   try importing   from Eagle pcb file..  and see how it gets
> it
> > wrong...
> > works fine on the top layer  IE   F.SilkS
> > if  you like I can make a screen cast all all the bugs.
> >
> > Lachlan
> >
>
> No, I do not see any issue.
> Are you using the legacy canvas or the opengl canvas ?
>
> Send us a screen copy.
>
>
> --
> Jean-Pierre CHARRAS
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Debian and Ubuntu packaging.

[Nick Østergaard]

2016-05-02 21:09 GMT+02:00 Wayne Stambaugh :
> Do we have any Debian developers on our mailing list?  I though I saw a
> Simon Richter on Planet Debian.  Is that you Simon?  Can someone tell me
> why the Debian package devs decided to build KiCad with the GitHub
> plugin disabled?  Is it a build issue or a licensing issue?

Because of OpenSSL licensing stuff...

Citing the debian packager:

"I had to remove the Github plugin from the build process, because this
plugins needed to compile a binary which is linked to GPLed libraries
and to OpenSSL at the same time, which triggers a fata Lintian error
about license incompatibility. However as the package kicad-common
provides all the know pretty libraies, and as the default template
declares those libraries, there is no immediate drawback.

Best regards, Georges."

-- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794311

> Avhttp is
> licensed under the boost license so it shouldn't be due to licensing
> issues.  A warning would have been nice before we were blind sided by a
> bunch of bug reports.  I don't have time to look it up right now so if
> someone has time to do some digging I would appreciate it.

I think this has been mentioned on the list before. Part of the goal
with the curl instead of avhttp was to remove the dependency on
openssl, which debian rejects... Because libcurl can use gnutls in
debian.

I know it is hard to remeber everything, but people tried to warn us
in https://lists.launchpad.net/kicad-developers/msg22543.html

I got so confused with all the agressive reverts of the curl stuff
that I don't even know if we use that now.

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

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

Re: [Kicad-developers] Missing features in GAL

[Nick Østergaard]

2016-05-02 18:38 GMT+02:00 Chris Pavlina :
> On Mon, May 02, 2016 at 05:29:06PM +0200, Maciej Sumiński wrote:
>> Now we plan to fill the remaining gaps between the legacy and GAL
>> canvases. I think it is a good opportunity to either improve or remove
>> certain tools, therefore I am asking for your input.
>>
>> What do you think about porting the following features? Do you find them
>> useful, maybe would you change them somehow?
>>
>> - autorouter
>
> I say kill it. The one in pcbnew is utterly useless. I assume we can keep the
> integration with external autorouter?
>
>> - microwave tools
>
> I don't see them being useful in the current implementation and I doubt they
> get any use. I have not once heard anybody talking about using them, only 
> about
> how they wish they could if only they were better... I'd like to see some
> microwave tools in GAL, but I think making a simple port of what we have now
> is a waste of good developer time.

It might indeed be a good choice to skip porting the microwave tools
as is. But I definitely think some better concept for the microwave
tools is needed. Like being able to specify an antenna trace impedance
and just draw it would be nice. Sort of like it is done with the diff
pairs. But getting "proper" microwave tools is not an easy task, I
think.

>> - footprint/local ratsnest
>
> Useful as is, I'd like to see this kept.
>
>> - dragging footprints (i.e. moving footprints while keeping tracks
>> connected)
>
> This is a very popular request in the IRC channel, we'll make a lot of people
> happy if we can implement this, possibly integrated with PNS? :)
>
>>
>> Regards,
>> Orson
>>
>
>
>
> ___
> Mailing list: https://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] Missing features in GAL

[Nick Østergaard]

2016-05-02 17:29 GMT+02:00 Maciej Sumiński :
> Now we plan to fill the remaining gaps between the legacy and GAL
> canvases. I think it is a good opportunity to either improve or remove
> certain tools, therefore I am asking for your input.
>
> What do you think about porting the following features? Do you find them
> useful, maybe would you change them somehow?
>
> - autorouter

I don't think it is worth porting built in autorouter, the one that is
hidden behind "that stupid button." The move button.

> - microwave tools

I think the microwave tools are a bit strange to use as of now, but I
definitely think that we should port them, at least for making the
stubs and such. Or at least have some alternative to them to easily
create those copper features. But I admit that I have not seen many
designs using those, but maybe that is simply because the three
options are not overly useful. I am sure someone else could elaborate
on this.

> - footprint/local ratsnest

I have seen multiple people ask for this on IRC.

> - dragging footprints (i.e. moving footprints while keeping tracks
> connected)

Maybe not in the sense that it works in legacy with straight segments
being rubber-band-like. Could the PNS be used to make this more smart?

>
> Regards,
> Orson
>
>
> ___
> Mailing list: https://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] Net Ties

[Nick Østergaard]

2016-04-22 15:04 GMT+02:00 Wayne Stambaugh :
> On 4/20/2016 4:00 PM, Simon Richter wrote:
>> Hi,
>>
>> as wxWidgets is getting on my nerves with editing widgets in the pin
>> table not rendering properly, I've started on support for net ties.
>>
>> In the current iteration, they would be placed the same way as junctions.
>>
>> Rules:
>>
>>  - Any wire or pin connected to a net tie is in a separate net (unless
>> connected elsewhere).
>>  - The net tie maps to a pseudo-pad that all three nets need to be
>> connected to.
>>  - Connecting the nets there does not give a DRC error -- anywhere else
>> will.
>>  - The pseudo-pad can be placed on a regular pad if it is on one of the
>> nets connected to the net tie.
>>
>> Use cases:
>>
>>  - Analog and digital supply planes connected with a trace, but
>> otherwise separate
>
> I'm going to put my EE hat on and say that if you connect two power
> planes with a trace then they are the same plane no matter what you
> called them in your schematic.  A more typical solution in this case
> would be to physically separate them by some type of component or
> components.  Usually inductors or 0 ohm resistors (aka jumpers) are used
> in this situation depending on what you are trying to accomplish.

Think current loops. This is just an enhancement on helping the
validate the layout and be able to make DRC identify this. Why use a
component when you can use free copper?

>>  - Current sense resistors between a supply rail and a load
>>  - Decoupling capacitors.
>
> I can see the decoupling capacitor use case where you want to tie a cap
> to a specific component power pin.
>
>>
>> I've added UI[1] and save support in eeschema already, still needs
>> mapping to the netlist and pcbnew support.
>
> Are you aware that changes to the current schematic file format are
> forbidden until we (I) finish implementing the new file format?  This
> was discussed fairly recently so everyone should be aware of this.  In
> any event, you should have gotten input from the development team before
> heading down this path.  This is good advice for any developer.  Even I
> solicit input on new features or large changes because other devs always
> seem to think of things I didn't.
>
> I don't have a strong opinion one way or the other about this feature.
> On the surface it does seem useful but I've never seen any EDA product
> support this so board designers may not understand why they would want
> to use it.  Any one else have any thoughts on this?  You may also want
> to check with the users to see if it's something that they would even use.
>
>>
>> There doesn't appear to be a real standard on how to represent net ties
>> in the schematic, though. A design note[2] from Linear Technologies uses
>> 45 degree angles on wires to make it look really intentional that the
>> wires should meet in the same spot, but that would be a major hassle
>> both to implement and use.
>>
>> For now I've gone with a larger dot, but that is very unintuitive.
>> Printing net names next to wires is difficult, because these are still
>> wires only. Numbers next to the wires might be doable, but confusing, so
>> if anyone has a good idea how to represent them, please speak up.
>
> How about a different color dot or a different shape.  A different shape
> may be better for users who are color blind.
>
>>
>>Simon
>>
>> [1] http://psi5.com/~geier/net-tie.ogv
>> [2] http://cds.linear.com/docs/en/design-note/dn434f.pdf
>>
>>
>>
>> ___
>> Mailing list: https://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] libkicad_3dsg.so.2.0.0

[Nick Østergaard]

But in the case of binary plugins, theu would be installed to the same
search location where kicad is already looking so the ldconfig should not
be problem, should it?
Den 20/04/2016 16.04 skrev "Bernhard Stegmaier" :

> ... these dynamic linked library issues will be really fun when/if we
> start with user-plugins, especially if they are distributed as a binary and
> maybe not distributed by any official package maintainer of a distribution
> ...
>
>
> Regards,
> Bernhard
>
> On 2016-04-20 10:11, Mário Luzeiro wrote:
>
>> I experienced that also but, for some reason that I dont understand
>> how it works, it starts to work again.
>> So maybe just need a reboot to make that "ldconfig update its cache".
>> 
>> From: Kicad-developers
>> [kicad-developers-bounces+mrluzeiro=ua...@lists.launchpad.net] on
>> behalf of Cirilo Bernardo [cirilo.berna...@gmail.com]
>> Sent: 20 April 2016 04:46
>> To: Tiger12506
>> Cc: KiCad Developers
>> Subject: Re: [Kicad-developers] libkicad_3dsg.so.2.0.0
>>
>> This issue is due to a required shared library being installed to
>> a path which is not currently checked by ldconfig. In your case
>> the path is /usr/local/lib.  You will need to configure ldconfig to
>> look for shared libraries in /usr/local/lib, then run ldconfig to
>> update its cache.  This is not a bug, it is an issue that needs to
>> be addressed by package maintainers and users who build and
>> install from source. Since different Linux systems manage the
>> ldconfig configuration in different ways it makes no sense for
>> KiCad developers to attempt to manage this configuration via the
>> CMake install scripts.
>>
>> - Cirilo
>>
>>
>> On Wed, Apr 20, 2016 at 1:20 PM, Tiger12506
>> > wrote:
>> A little problem when I compiled the latest bazaar revision.
>>
>> A kicad that runs, but trying to open pcbnew results in error. Also
>> occurs when trying to run pcbnew standalone.
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] 3D filename resolution

[Nick Østergaard]

Den 20/04/2016 14.31 skrev "Wayne Stambaugh" <stambau...@gmail.com>:
>
> On 4/20/2016 8:27 AM, Nick Østergaard wrote:
> >
> > Den 20/04/2016 14.16 skrev "Wayne Stambaugh" <stambau...@gmail.com
> > <mailto:stambau...@gmail.com>>:
> >>
> >> Mario,
> >>
> >> That's not going to happen.  I specifically designed the environment
> >> variable behavior for development purposes.  That's why the environment
> >> variables defined externally to kicad take precedence.  This allows me
> >> to keep my test libraries separate from my normal working libraries.
> >> This allows me to do:
> >>
> >> export KISYSMOD=/path/to/test/footprint/libraries
> >> pcbnew
> >>
> >> which is really useful for debugging and testing.  Entries in the
> >> environment variable configuration table in kicad are highlighted in
> >> grey to inform the user that a given variable was defined externally.
> >
> > So does it show the external env var or the config one? If it shows the
> > external one, that is what Mario expects.
>
> The internally defined environment variable is shown.  I suppose I can
> show the external one and make the greyed out table entries read only so
> they cannot be edited but that may be confusing as well.

I have not seen the help text, but I think it would be less confusing of ot
showed the external env var when that is what is being used by kicad,
instead of the unused config var, in the case an external env var is
defined.

> >
> >> We even have a help dialog that explains this which if I am not
mistaken
> >> is the *only* help button provided by any dialog in kicad.  On clean
> >> installs this should not be an issue because it's highly unlikely that
> >> users will have any of environment variable defined that are used by
> > kicad.
> >>
> >> Wayne
> >>
> >> On 4/20/2016 4:04 AM, Mário Luzeiro wrote:
> >> > Hi Cirilo,
> >> >
> >> > Thinking as a regular user perspective, I vote for "WYSIWYG", i.e:
> > the one defined in the GUI.
> >> > Users will get puzzled if something that they don't see is change
> > the variable path.
> >> >
> >> > Mario
> >> > 
> >> > From: Kicad-developers
> > [kicad-developers-bounces+mrluzeiro=ua...@lists.launchpad.net
> > <mailto:ua...@lists.launchpad.net>] on behalf of Cirilo Bernardo
> > [cirilo.berna...@gmail.com <mailto:cirilo.berna...@gmail.com>]
> >> > Sent: 20 April 2016 01:19
> >> > To: KiCad Developers
> >> > Subject: [Kicad-developers] 3D filename resolution
> >> >
> >> > Hi folks,
> >> >
> >> >  I'm cleaning up the new 3D filename resolution code, removing some
> >> > redundant code and fixing corner-case bugs which break with legacy
> >> > behavior. I'd just like some input on one item: if a ENV_VAR path has
> >> > been defined via "Preferences->Configure Paths" and that ENV_VAR
> >> > already exists on the system, which one has preference? For most
> >> > UNIX applications the behavior is to use the ENV_VAR defined within
> >> > the shell rather than the locally defined values.
> >> >
> >> > - Cirilo
> >> >
> >> >
> >> > ___
> >> > Mailing list: https://launchpad.net/~kicad-developers
> >> > Post to : kicad-developers@lists.launchpad.net
> > <mailto:kicad-developers@lists.launchpad.net>
> >> > Unsubscribe : https://launchpad.net/~kicad-developers
> >> > More help   : https://help.launchpad.net/ListHelp
> >> >
> >>
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to : kicad-developers@lists.launchpad.net
> > <mailto:kicad-developers@lists.launchpad.net>
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> More help   : https://help.launchpad.net/ListHelp
> >
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] 3D filename resolution

[Nick Østergaard]

Den 20/04/2016 14.16 skrev "Wayne Stambaugh" :
>
> Mario,
>
> That's not going to happen.  I specifically designed the environment
> variable behavior for development purposes.  That's why the environment
> variables defined externally to kicad take precedence.  This allows me
> to keep my test libraries separate from my normal working libraries.
> This allows me to do:
>
> export KISYSMOD=/path/to/test/footprint/libraries
> pcbnew
>
> which is really useful for debugging and testing.  Entries in the
> environment variable configuration table in kicad are highlighted in
> grey to inform the user that a given variable was defined externally.

So does it show the external env var or the config one? If it shows the
external one, that is what Mario expects.

> We even have a help dialog that explains this which if I am not mistaken
> is the *only* help button provided by any dialog in kicad.  On clean
> installs this should not be an issue because it's highly unlikely that
> users will have any of environment variable defined that are used by
kicad.
>
> Wayne
>
> On 4/20/2016 4:04 AM, Mário Luzeiro wrote:
> > Hi Cirilo,
> >
> > Thinking as a regular user perspective, I vote for "WYSIWYG", i.e: the
one defined in the GUI.
> > Users will get puzzled if something that they don't see is change the
variable path.
> >
> > Mario
> > 
> > From: Kicad-developers [kicad-developers-bounces+mrluzeiro=
ua...@lists.launchpad.net] on behalf of Cirilo Bernardo [
cirilo.berna...@gmail.com]
> > Sent: 20 April 2016 01:19
> > To: KiCad Developers
> > Subject: [Kicad-developers] 3D filename resolution
> >
> > Hi folks,
> >
> >  I'm cleaning up the new 3D filename resolution code, removing some
> > redundant code and fixing corner-case bugs which break with legacy
> > behavior. I'd just like some input on one item: if a ENV_VAR path has
> > been defined via "Preferences->Configure Paths" and that ENV_VAR
> > already exists on the system, which one has preference? For most
> > UNIX applications the behavior is to use the ENV_VAR defined within
> > the shell rather than the locally defined values.
> >
> > - Cirilo
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] i18n little problem

[Nick Østergaard]

2016-04-19 7:54 GMT+02:00 Marco Ciampa <ciam...@libero.it>:
>> 2016-04-18 21:43 GMT+02:00 Marco Ciampa <ciam...@libero.it>:
>> > I just a little problem I discovered.
>> >
>> > Under Linux, if you manage to change the language using the menu, some
>> > wxwindows related features (name on the buttons "cancel" and "Ok" on the
>> > 3D path settings for example) are determined from the "locale" language
>> > environment (that you can change from the command line with: "export
>> > LANGUAGE it_IT.UFT-8; kicad") only, independently of the kicad language
>> > setting.
>> >
>> On Tue, Apr 19, 2016 at 01:26:02AM +0200, Nick Østergaard wrote:
>> It is a little unclear what exactly you select in the language. But
>> this is expected when you click the default and not english or any
>> other language.
>
> Sorry for being unclear. I'll give you an example.
> My Locale settings is Italian (of course ... :-).
> In these days I am producing some screenshots in english so I switched to 
> English in the menu.
> If I open the footprint editor->path configuration I see as buttos: "Aiuto" 
> "Annulla" "Ok".
> I think this is wrong.

Are you sure that you didn't select the "default" language instead of "English"?

___
Mailing list: https://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] i18n little problem

[Nick Østergaard]

It is a little unclear what exactly you select in the language. But
this is expected when you click the default and not english or any
other language.

2016-04-18 21:43 GMT+02:00 Marco Ciampa :
> I just a little problem I discovered.
>
> Under Linux, if you manage to change the language using the menu, some
> wxwindows related features (name on the buttons "cancel" and "Ok" on the
> 3D path settings for example) are determined from the "locale" language
> environment (that you can change from the command line with: "export
> LANGUAGE it_IT.UFT-8; kicad") only, independently of the kicad language
> setting.
>
> TIA
>
> --
>
>
> Marco Ciampa
>
> I know a joke about UDP, but you might not get it.
>
> 
>
>  GNU/Linux User #78271
>  FSFE fellow #364
>
> 
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://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] 0.1 degrees

[Nick Østergaard]

2016-04-12 8:34 GMT+02:00 Lorenzo Marcantonio :
> On Tue, Apr 12, 2016 at 07:58:05AM +1000, Cirilo Bernardo wrote:
>
>> a) ability to use "." or "," regardless of the language setting - assuming
>> no sensible person ever enters a thousands separator in CAD software
>> (I don't know any CAD software which accepts thousands separators).
>
> Already doing this :D
>
>> b) ability to specify a unit as a suffix:  0.001m, 1mm, 0.03937in,
>> also 'mil' and for the Australians 'thou'.
>
> Already doind that, too :D

Remember that this already works for linear units, although semi buggy
as Cirilo mentioned earlier. (if for example you write a432mm it will
silently be zero)

> IIRC it's a couple of function, not a validator-thingie, it was
> literally years ago. But I suppose it's easily convertible.
>
>> People have also been asking to have angle suffixes: rad/deg/mrad
>
> Seriously... *what use* are radians in a pcb layout? The only thing that
> comes to mind are arc stub for impedance match...
>
>> but in my opinion such a thing would have to be implemented in
>> a different validator - maybe an AngleFloatValidator vs a
>> UnitFloatValidator  - or else the validator will need to be able to
>> change its behavior based on some kind of flag.
>
> Please please no flag. Two different functions/classes/whatever.
>
>> The current input text boxes in my opinion have a number of bugs:
>> 1. you can put alphabetic characters anywhere
>> 2. if the unit is not known or a mistake is made then the conversion
>> result is "0" which is obviously wrong. In such a case the validator
>> should prevent the user from changing the value at all and somehow
>> signal the user of the mistake so the user can correct it. Naturally it
>> is impossible to tell if there is a mistake with "m" vs "mm".
>
> OK, from memory, the current value conversion (as you said it's *not* a
> validation) occurs at data transfer time, i.e. from variable to control
> and back. It's a conversion since the variables are in internal units
> (mils in eeschema and 10 nanos in pcbnew). That's probably one of the
> reason for the tenth-degree input, there is no *conversion* pair for
> them.
>
> If the idea is to move these feature in a while-type validation, I think
> it's good (but be careful at the 'intermediate' stages while people is
> editing the content).
>
> --
> Lorenzo Marcantonio
> CZ Srl - Parma
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>

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

Re: [Kicad-developers] KiCad daily PPA for Trusty not building

[Nick Østergaard]

Easyw, remember that in a full MSYS2 installation you sort of that three
environments, msys, mingw32 and mingw64. The swig you used was the one from
the "barebones" msys environment, while you need the one for mingw.
Den 15/04/2016 08.56 skrev "jp charras" :

> Le 14/04/2016 23:07, easyw a écrit :
> > Hi,
> > I'm having the same prob in windows 8-64b mingw64...
> > I could build with
> > KICAD_SCRIPTING=ON, KICAD_SCRIPTING_MODULES=ON,
> KICAD_SCRIPTING_WXPYTHON=ON
> > till few release before
> > now I can build only with this option off
> >
> > I tried both the path and -DSWIG_EXECUTABLE=/usr/bin/swig3.0 (after
> having installed swig 3.0.6 with
> > pacman -S swig)
> > these are the errors:
> > CMake Error at
> C:/kicad-wb-1602/msys64/mingw64/share/cmake-3.4/Modules/FindSWIG.cmake:50
> (message):
> >   Command "C:/kicad-wb-1602/msys64/usr/bin/swig3.0 -swiglib" failed with
> >   output:
> > Call Stack (most recent call first):
> >   pcbnew/CMakeLists.txt:11 (find_package)
> > CMake Error at pcbnew/CMakeLists.txt:12 (include):
> >   include called with wrong number of arguments.  include() only takes
> one file.
> > CMake Error at pcbnew/CMakeLists.txt:411 (swig_add_module):
> >   Unknown CMake command "swig_add_module".
> > -- Configuring incomplete, errors occurred!
> >
> > my cmake options are:
> >  cmake -G "MSYS Makefiles" -DCMAKE_BUILD_TYPE=Release
> > -DwxWidgets_ROOT_DIR=../../../../mingw64/include/wx-3.0/
> -DKICAD_SCRIPTING=ON
> > -DKICAD_SCRIPTING_MODULES=ON -DKICAD_SCRIPTING_WXPYTHON=ON
> > -DPYTHON_ROOT_DIR=../../../../mingw64/include/python2.7
> -DUSE_FP_LIB_TABLE=ON
> > -DBUILD_GITHUB_PLUGIN=ON -DSWIG_EXECUTABLE=/usr/bin/swig3.0
> -DKICAD_REPO_NAME=dev
> > -DKICAD_BUILD_VERSION=6691 ../kicad_main_branch
> >
> > Regards
> > Maurice
> >
>
> I do not understand very well your command line.
> I am using W3 32 bits + msys2, but I believe it does not make difference.
>
> On my msys2 the default is swig 3.0.6, and the executable is swig (in fact
> swig.exe), not swig3.0
> and it is in /mingw32/bin (or /mingw64/bin for you)
> Use command "type swig" or "type swig3.0" to know the actual path (and if
> file exists)
> here is the result on my install:
> jpc@jpc MINGW32 ~
> $ type swig
> swig est haché (/mingw32/bin/swig)
> $ type swig3.0
> bash: type: swig3.0 : non trouvé
>
>
> Because swig3.0 is the default, adding -DSWIG_EXECUTABLE is useless
> (currently, your define is
> perhaps incorrect and it explains the cmake errors)).
>
> You are using the wxWidgets coming from msys2. So define
> wxWidgets_ROOT_DIR should be not necessary.
>
> --
> Jean-Pierre CHARRAS
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DIALOG_ORIENT_FOOTPRINTS

[Nick Østergaard]

You can achieve exactly this with the move exact and array tools.

2016-04-13 8:16 GMT+02:00 David Godfrey :
> Hi Chris,
>
> A rotation of the selection is not the same as a rotation of the
> individual components.
> Consider you already have the components roughly in a grid, and you need
> to rotate them by 20 degrees.
> Rotating the selection means you have to do major repositioning of every
> component to get them back in the correct area.
>
> However rotating the components within the selection means they are
> still in about the right position, so only minor placement adjustments
> are required.
> These minor adjustments can likely be made using the align and
> distribute tools
>
> I Agree half-implemented features are bad, better to update them and
> properly implement.
>
> Regards
> David G
>
> On 13/04/16 08:53, Chris Pavlina wrote:
>> GAL already has this. Block or multi select, Ctrl-M for "move exactly" (or 
>> use
>> the context menu), and type an angle. Just rotates the whole selection, then
>> you can place your rotated resistors.
>>
>> Considering legacy is on its way out, I'd rather not keep crusty old
>> half-implemented legacy features around to require maintenance.
>>
>>
>> On Wed, Apr 13, 2016 at 08:50:38AM +0800, David Godfrey wrote:
>>> Hmm,
>>>
>>> I'v not used it on Kicad but the ability to change the orientation of an
>>> arbitrary selection of footprints is something I've used many times in
>>> Altium.
>>>
>>> Ideally you want to be able to set an absolute orientation, and also a
>>> relative (to current) angle adjustment.
>>>
>>> This is especially useful when designing boards like LED matrices and
>>> wanting to put all resisters on a specific angle (eg: 21.3deg).
>>> You can then do an array alignment with the same outer limit you used
>>> for your LED alignment.
>>> Then move the group of resistors into position relative to the LED's.
>>>
>>> Now running your tracks becomes trivial.
>>>
>>> Without the ability to auto adjust the orientation on a selection of
>>> parts the job becomes long and tedious.
>>> Some of the PCB's I've done this on have over 1000 LED's and resistors,
>>> and generally you need to orient both the resistors and the LED's
>>>
>>> So in summary, I'd like to keep the ability to do this, but on a
>>> selection instead of globally.
>>> And being able to alter it as an absolute angle, or as a relative to
>>> current (prefix the new angle with + or - to get relative movement)
>>> would be beneficial.
>>>
>>> Regards
>>> David G
>>>
>>> On 13/04/16 06:40, Chris Pavlina wrote:
 I wonder how many of you are even aware of DIALOG_ORIENT_FOOTPRINTS. It's
 hidden in the Secret Menu in pcbnew (the spread-and-place) one, menu item
 Orient All Footprints. The code hasn't been touched since 2010 except a few
 cleanups, and it seems really simplistic and useless to me. I was going to
 upgrade it to floating-point angle entry like everything else, but

 Does _anybody_ even use this? It seems utterly useless. I have no idea when
 you'd want to globally apply an orientation to footprints. Can I just tear 
 it
 out?  :P

>>>
>>>
>>> ___
>>> Mailing list: https://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] Silk on pads

[Nick Østergaard]

Yeah, Peter, this suggestion is not to remove the possibility to have
the silk, just to not enable the silk on through holes by default,
which rarely makes sense anyway.

I have been wondering about this default option many times and always
find myself correcting the footprint when I realize that it is
enabled, which can become a bit tedious. So I vote for default silk on
pad off too.

2016-04-13 1:39 GMT+02:00 Chris Pavlina :
> Yeah, I can think of edge cases where it might be desirable. I'm just having
> trouble imagining why it would be *default*. You can enable that layer 
> manually
> on these touch pads in this case.
>
> On Wed, Apr 13, 2016 at 09:07:16AM +0930, Peter Wintulich wrote:
>> Hello,
>> I had been court by this.
>> There is one scenario where it may be use full, though SMT pads would more
>> likely be used.
>> This is for touch panels where the solder mask and Silk screen are over the
>> pad area with no exposed metal.
>>
>> Regards Peter
>>
>> On 13/04/16 08:57, Wayne Stambaugh wrote:
>> >On 4/12/2016 5:53 PM, Chris Pavlina wrote:
>> >>Quick question... does anybody know why we are putting silkscreen over PTH 
>> >>pads
>> >>by default? And can we change this? Obviously they shouldn't be 
>> >>manufactured
>> >>this way, so we're depending on either the user to remember to choose 
>> >>"Subtract
>> >>soldermask from silkscreen" or on the fab to do it, both of which aren't
>> >>necessary dependable...
>> >>
>> >I would give users and devs a few days to respond and if no one
>> >complains too loudly go ahead and remove the offending code.
>> >
>> >___
>> >Mailing list: https://launchpad.net/~kicad-developers
>> >Post to : kicad-developers@lists.launchpad.net
>> >Unsubscribe : https://launchpad.net/~kicad-developers
>> >More help   : https://help.launchpad.net/ListHelp
>> >
>>
>>
>> --
>>
>> Peter Wintulich
>>
>> Voicetronix Pty. Ltd.
>> Suite 6, Level 1, 977 North East Road,
>> MODBURY  5092
>> South Australia
>> AUSTRALIA
>> +61 8 8264 2005
>>
>>
>> ___
>> Mailing list: https://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