Re: [Kicad-developers] C++14 (redux)

[Seth Hillbrand]

Hi Wayne-

Sounds good.  I've removed the libglm hold.  This will make building on 
Buster easier going forward.


-Seth

On 2019-08-06 16:28, Wayne Stambaugh wrote:

Ian,

We have had our own make_unique implementation for quite some time (see
include/make_unique.h) so even without c++14, you can use make_unique.
This includes the 5.1 branch.  The master branch is c++14 where the 5.1
branch is c++11 so as long as you are not fixing anything that would
need cherry picked to the 5.1 branch, then c++14 is acceptable.

Cheers,

Wayne

On 8/6/19 4:21 PM, Ian McInerney wrote:

Is the master branch now open for C++14-based code submissions, or are
we still waiting some before allowing them? (I have a change that 
would
benefit greatly from make_unique, but I can hold off on it until we 
are

open).

-Ian

On Fri, Jul 12, 2019 at 4:16 PM Nick Østergaard mailto:oe.n...@gmail.com>> wrote:

Yes, using gnu+14 on windows

fre. 12. jul. 2019 15.34 skrev Seth Hillbrand mailto:s...@hillbrand.org>>:

Thanks Nick!  I pushed the patch to the master branch on
Wednesday. 
Ubunutu, Mac and Windows all appear to have built their 
nightlies
without problem.  I was going to check in on Fedora this 
weekend

but
this seems like a quiet transition so far.  :)

-Seth

On 2019-07-12 05:00, Nick Østergaard wrote:
> Just for the record, I did build test it on msys2/mingw on
windows, I
> added these args to cmake.
>
> -DCMAKE_CXX_STANDARD=14 \
> -DCMAKE_CXX_STANDARD_REQUIRED=ON \
> -DCMAKE_CXX_EXTENSIONS=OFF \
> -DCMAKE_CXX_FLAGS=-U__STRICT_ANSI__ \
>
> The __STRICT_ANSI__ is required because of using wx 3.0 as 
far

as I
> understand it, Simon shared below patch to me.
>
> http://psi5.com/~geier/extensions.diff
>
> I did not runtime test it, but it built just fine for x86_64
at least.
>
> On Wed, 10 Jul 2019 at 21:03, Wayne Stambaugh
mailto:stambau...@gmail.com>>
> wrote:
>>
>> Seth,
>>
>> That's fine but we might want to give it more than a week 
or

two.  I
>> was
>> thinking more like a month or two.
>>
>> Wayne
>>
>> On 7/10/19 2:06 PM, Seth Hillbrand wrote:
>> > Hi Wayne-
>> >
>> > No worries!
>> >
>> > How about this:  We bump the C++ version in cmake but not
put any C++14
>> > code into the codebase for a week or two to see if there
are any issues
>> > with supported platform packagers.  If there are issues
with supported
>> > platforms, we revert and wait for v7.  If not, we start
allow C++14 code.
>> >
>> > -Seth
>> >
>> >
>> > On 2019-07-10 13:00, Wayne Stambaugh wrote:
>> >> Hey Seth,
>> >>
>> >> Sorry for the delayed response, this got lost in my
inbox.  I'm on the
>> >> fence about this.  My gut says push it v7 development
given the amount
>> >> of work we have to do for v6 but I'm not opposed to it 
as

long as we can
>> >> build it on all of our supported platforms.
>> >>
>> >> Cheers,
>> >>
>> >> Wayne
>> >>
>> >> On 7/5/19 3:52 PM, Seth Hillbrand wrote:
>> >>> Hi Wayne-
>> >>>
>> >>> This shouldn't affect users, only developers.  Once the
binary is built,
>> >>> there are no differences in requirements for running 
KiCad.

>> >>>
>> >>> I would only push this to master and not 5.1, so that
5.1.3+ bug fixes
>> >>> will still build for 14.04 (which was supported when 
5.1

was released).
>> >>>
>> >>> -Seth
>> >>>
>> >>>
>> >>> On 2019-07-05 14:30, Wayne Stambaugh wrote:
>>  Hey Seth,
>> 
>>  Sorry about the delay.  I've been wrestling (and
loosing) with
>>  restoring
>>  a broken boot manager on my desktop after a bios 
update

stepped all
>>  over
>>  my uefi boot configuration (thank you HP).  I would 
like

to hold off on
>>  C++14 for a while.  I suspect there are users who 
prefer

running older
>>  linux distros for stability purposes.  I would rather
not throw those
>>  users under a bus just yet unless we have enough
credible evidence that
>>  it wont be an issue.  I suppose we could always put it
out there and
>>  see
>>  who screams and undo the changes as needed.
>> 
>>  Cheers,
>> 
>>  Wayne
>> 
>>  On 7/1/19 7:20 PM, Seth Hillbrand 

Re: [Kicad-developers] C++14 (redux)

[Wayne Stambaugh]

Ian,

We have had our own make_unique implementation for quite some time (see
include/make_unique.h) so even without c++14, you can use make_unique.
This includes the 5.1 branch.  The master branch is c++14 where the 5.1
branch is c++11 so as long as you are not fixing anything that would
need cherry picked to the 5.1 branch, then c++14 is acceptable.

Cheers,

Wayne

On 8/6/19 4:21 PM, Ian McInerney wrote:
> Is the master branch now open for C++14-based code submissions, or are
> we still waiting some before allowing them? (I have a change that would
> benefit greatly from make_unique, but I can hold off on it until we are
> open).
> 
> -Ian
> 
> On Fri, Jul 12, 2019 at 4:16 PM Nick Østergaard  > wrote:
> 
> Yes, using gnu+14 on windows
> 
> fre. 12. jul. 2019 15.34 skrev Seth Hillbrand  >:
> 
> Thanks Nick!  I pushed the patch to the master branch on
> Wednesday. 
> Ubunutu, Mac and Windows all appear to have built their nightlies
> without problem.  I was going to check in on Fedora this weekend
> but
> this seems like a quiet transition so far.  :)
> 
> -Seth
> 
> On 2019-07-12 05:00, Nick Østergaard wrote:
> > Just for the record, I did build test it on msys2/mingw on
> windows, I
> > added these args to cmake.
> >
> > -DCMAKE_CXX_STANDARD=14 \
> > -DCMAKE_CXX_STANDARD_REQUIRED=ON \
> > -DCMAKE_CXX_EXTENSIONS=OFF \
> > -DCMAKE_CXX_FLAGS=-U__STRICT_ANSI__ \
> >
> > The __STRICT_ANSI__ is required because of using wx 3.0 as far
> as I
> > understand it, Simon shared below patch to me.
> >
> > http://psi5.com/~geier/extensions.diff
> >
> > I did not runtime test it, but it built just fine for x86_64
> at least.
> >
> > On Wed, 10 Jul 2019 at 21:03, Wayne Stambaugh
> mailto:stambau...@gmail.com>>
> > wrote:
> >>
> >> Seth,
> >>
> >> That's fine but we might want to give it more than a week or
> two.  I
> >> was
> >> thinking more like a month or two.
> >>
> >> Wayne
> >>
> >> On 7/10/19 2:06 PM, Seth Hillbrand wrote:
> >> > Hi Wayne-
> >> >
> >> > No worries!
> >> >
> >> > How about this:  We bump the C++ version in cmake but not
> put any C++14
> >> > code into the codebase for a week or two to see if there
> are any issues
> >> > with supported platform packagers.  If there are issues
> with supported
> >> > platforms, we revert and wait for v7.  If not, we start
> allow C++14 code.
> >> >
> >> > -Seth
> >> >
> >> >
> >> > On 2019-07-10 13:00, Wayne Stambaugh wrote:
> >> >> Hey Seth,
> >> >>
> >> >> Sorry for the delayed response, this got lost in my
> inbox.  I'm on the
> >> >> fence about this.  My gut says push it v7 development
> given the amount
> >> >> of work we have to do for v6 but I'm not opposed to it as
> long as we can
> >> >> build it on all of our supported platforms.
> >> >>
> >> >> Cheers,
> >> >>
> >> >> Wayne
> >> >>
> >> >> On 7/5/19 3:52 PM, Seth Hillbrand wrote:
> >> >>> Hi Wayne-
> >> >>>
> >> >>> This shouldn't affect users, only developers.  Once the
> binary is built,
> >> >>> there are no differences in requirements for running KiCad.
> >> >>>
> >> >>> I would only push this to master and not 5.1, so that
> 5.1.3+ bug fixes
> >> >>> will still build for 14.04 (which was supported when 5.1
> was released).
> >> >>>
> >> >>> -Seth
> >> >>>
> >> >>>
> >> >>> On 2019-07-05 14:30, Wayne Stambaugh wrote:
> >>  Hey Seth,
> >> 
> >>  Sorry about the delay.  I've been wrestling (and
> loosing) with
> >>  restoring
> >>  a broken boot manager on my desktop after a bios update
> stepped all
> >>  over
> >>  my uefi boot configuration (thank you HP).  I would like
> to hold off on
> >>  C++14 for a while.  I suspect there are users who prefer
> running older
> >>  linux distros for stability purposes.  I would rather
> not throw those
> >>  users under a bus just yet unless we have enough
> credible evidence that
> >>  it wont be an issue.  I suppose we could always put it
> out there and
> >>  see
> >>  who screams and undo the changes as needed.
> >> 
> >>  Cheers,
> >> 
> >>  Wayne
> 

Re: [Kicad-developers] C++14 (redux)

[Ian McInerney]

Is the master branch now open for C++14-based code submissions, or are we
still waiting some before allowing them? (I have a change that would
benefit greatly from make_unique, but I can hold off on it until we are
open).

-Ian

On Fri, Jul 12, 2019 at 4:16 PM Nick Østergaard  wrote:

> Yes, using gnu+14 on windows
>
> fre. 12. jul. 2019 15.34 skrev Seth Hillbrand :
>
>> Thanks Nick!  I pushed the patch to the master branch on Wednesday.
>> Ubunutu, Mac and Windows all appear to have built their nightlies
>> without problem.  I was going to check in on Fedora this weekend but
>> this seems like a quiet transition so far.  :)
>>
>> -Seth
>>
>> On 2019-07-12 05:00, Nick Østergaard wrote:
>> > Just for the record, I did build test it on msys2/mingw on windows, I
>> > added these args to cmake.
>> >
>> > -DCMAKE_CXX_STANDARD=14 \
>> > -DCMAKE_CXX_STANDARD_REQUIRED=ON \
>> > -DCMAKE_CXX_EXTENSIONS=OFF \
>> > -DCMAKE_CXX_FLAGS=-U__STRICT_ANSI__ \
>> >
>> > The __STRICT_ANSI__ is required because of using wx 3.0 as far as I
>> > understand it, Simon shared below patch to me.
>> >
>> > http://psi5.com/~geier/extensions.diff
>> >
>> > I did not runtime test it, but it built just fine for x86_64 at least.
>> >
>> > On Wed, 10 Jul 2019 at 21:03, Wayne Stambaugh 
>> > wrote:
>> >>
>> >> Seth,
>> >>
>> >> That's fine but we might want to give it more than a week or two.  I
>> >> was
>> >> thinking more like a month or two.
>> >>
>> >> Wayne
>> >>
>> >> On 7/10/19 2:06 PM, Seth Hillbrand wrote:
>> >> > Hi Wayne-
>> >> >
>> >> > No worries!
>> >> >
>> >> > How about this:  We bump the C++ version in cmake but not put any
>> C++14
>> >> > code into the codebase for a week or two to see if there are any
>> issues
>> >> > with supported platform packagers.  If there are issues with
>> supported
>> >> > platforms, we revert and wait for v7.  If not, we start allow C++14
>> code.
>> >> >
>> >> > -Seth
>> >> >
>> >> >
>> >> > On 2019-07-10 13:00, Wayne Stambaugh wrote:
>> >> >> Hey Seth,
>> >> >>
>> >> >> Sorry for the delayed response, this got lost in my inbox.  I'm on
>> the
>> >> >> fence about this.  My gut says push it v7 development given the
>> amount
>> >> >> of work we have to do for v6 but I'm not opposed to it as long as
>> we can
>> >> >> build it on all of our supported platforms.
>> >> >>
>> >> >> Cheers,
>> >> >>
>> >> >> Wayne
>> >> >>
>> >> >> On 7/5/19 3:52 PM, Seth Hillbrand wrote:
>> >> >>> Hi Wayne-
>> >> >>>
>> >> >>> This shouldn't affect users, only developers.  Once the binary is
>> built,
>> >> >>> there are no differences in requirements for running KiCad.
>> >> >>>
>> >> >>> I would only push this to master and not 5.1, so that 5.1.3+ bug
>> fixes
>> >> >>> will still build for 14.04 (which was supported when 5.1 was
>> released).
>> >> >>>
>> >> >>> -Seth
>> >> >>>
>> >> >>>
>> >> >>> On 2019-07-05 14:30, Wayne Stambaugh wrote:
>> >>  Hey Seth,
>> >> 
>> >>  Sorry about the delay.  I've been wrestling (and loosing) with
>> >>  restoring
>> >>  a broken boot manager on my desktop after a bios update stepped
>> all
>> >>  over
>> >>  my uefi boot configuration (thank you HP).  I would like to hold
>> off on
>> >>  C++14 for a while.  I suspect there are users who prefer running
>> older
>> >>  linux distros for stability purposes.  I would rather not throw
>> those
>> >>  users under a bus just yet unless we have enough credible
>> evidence that
>> >>  it wont be an issue.  I suppose we could always put it out there
>> and
>> >>  see
>> >>  who screams and undo the changes as needed.
>> >> 
>> >>  Cheers,
>> >> 
>> >>  Wayne
>> >> 
>> >>  On 7/1/19 7:20 PM, Seth Hillbrand wrote:
>> >> > Hi Devs-
>> >> >
>> >> > Now that Ubuntu 14.04LTS support has ended, are we building any
>> >> > platforms that do not support C++14 (gcc prior to version 5)?
>> >> >
>> >> > If not, can we bump our compiler language support to C++14?  This
>> >> > would
>> >> > allow us to drop the ban on certain version of GLM as well as our
>> >> > custom-rolled std::make_unique.  There are a few language
>> features
>> >> > (generalized lambda captures!) that would tighten up quite a bit
>> of
>> >> > code
>> >> > if available.
>> >> >
>> >> > Obviously if we are still supporting a C++11 only system, this
>> >> > should be
>> >> > delayed.
>> >> >
>> >> > Best-
>> >> > Seth
>> >> >
>> >> > ___
>> >> > Mailing list: https://launchpad.net/~kicad-developers
>> >> > Post to : kicad-developers@lists.launchpad.net
>> >> > Unsubscribe : https://launchpad.net/~kicad-developers
>> >> > More help   : https://help.launchpad.net/ListHelp
>> >> 
>> >>  ___
>> >>  Mailing list: https://launchpad.net/~kicad-developers
>> >>  Post to : 

Re: [Kicad-developers] How to make single-plane .cpp from .png?

[Jeff Young]

Hi guys,

I just needed to add a current-probe cursor for spice (which meant re-authoring 
the voltage-probe to match).  I ended up authoring them in Gimp (because 
anything converted from SVG to a 1-bit-per-pixel bitmap looks awful).

Since Gimp can save as XBM I didn’t bother to use the PNG2cpp script — it’s 
easy enough to just copy/paste the text from the XBM file.

Cheers,
Jeff.


> On 6 Aug 2019, at 11:39, Seth Hillbrand  wrote:
> 
> On 2019-08-05 15:22, Jeff Young wrote:
>> Our PNG2cpp.cmake script makes a 3 or 4 plane (ie: colour) char array.
>> wxWidgets’ wxBitmap() constructor needs a single plane char array.
>> John Beard created a couple for the SPICE cursors, but I’m not sure
>> how he did it.
> 
> 
> I'm pretty sure that John just moved the cursors that Orson built.  The 
> PNG2cpp puts raw PNG data into cpp arrays.
> 
> Are you looking to build a new cursor library?
> 
> If you want to generate binary (white or black) cursors, you can save the 
> icon as an XBM file from gimp.  Then 0=white and 1=black.  You can use the 
> same PNG2cpp script to convert the file from XBM to a cpp array.
> 
> -Seth


___
Mailing list: https://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] How to make single-plane .cpp from .png?

[Seth Hillbrand]

On 2019-08-05 15:22, Jeff Young wrote:

Our PNG2cpp.cmake script makes a 3 or 4 plane (ie: colour) char array.

wxWidgets’ wxBitmap() constructor needs a single plane char array.
John Beard created a couple for the SPICE cursors, but I’m not sure
how he did it.



I'm pretty sure that John just moved the cursors that Orson built.  The 
PNG2cpp puts raw PNG data into cpp arrays.


Are you looking to build a new cursor library?

If you want to generate binary (white or black) cursors, you can save 
the icon as an XBM file from gimp.  Then 0=white and 1=black.  You can 
use the same PNG2cpp script to convert the file from XBM to a cpp array.


-Seth

___
Mailing list: https://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 initialization order for COLOR4D statics

[Seth Hillbrand]

Thanks Ian.  This looks good.  Patch merged.

-Seth

On 2019-08-05 10:39, Ian McInerney wrote:

The updated patch using constexpr (which now only affects the color4d
files) is attached.

Simon, thanks for the suggestion to use constexpr. It ended up working
by just declaring the variables constexpr and also making one of the
constructors constexpr. Definitely much simpler.

-Ian

On Mon, Aug 5, 2019 at 2:10 PM Wayne Stambaugh 
wrote:


On 8/5/19 5:03 AM, Simon Richter wrote:

Hi,

On Mon, Aug 05, 2019 at 10:58:44AM +0200, Ian McInerney wrote:


I tracked it down to the fact that COLOR4D has some static colors

that were

being used to initialize some other static variables in pcbnew's

layer

widgets. I have moved all the static colors to an initialize on

first use

paradigm (so now we just call them like a function, e.g.
COLOR4D::UNSPECIFIED() ) to fix it.


Can that be solved by constexpr?

Simon



I would prefer the constexpr solution if it resolves the issue.  It
certainly would be a much simpler patch.

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] Eeschema - Bus definitions: make hints translatable.

[Seth Hillbrand]

On 2019-08-02 13:58, Konstantin Baranovskiy wrote:

From: Baranovskiy Konstantin 

---
 eeschema/dialogs/dialog_bus_manager.cpp | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/eeschema/dialogs/dialog_bus_manager.cpp
b/eeschema/dialogs/dialog_bus_manager.cpp
index 4144d1bc3..608b34178 100644
--- a/eeschema/dialogs/dialog_bus_manager.cpp
+++ b/eeschema/dialogs/dialog_bus_manager.cpp
@@ -175,8 +175,8 @@ DIALOG_BUS_MANAGER::DIALOG_BUS_MANAGER(
SCH_EDIT_FRAME* aParent )
 m_btn_rename_signal->Disable();
 m_btn_remove_signal->Disable();

-m_bus_edit->SetHint( _T( "Bus Alias Name" ) );
-m_signal_edit->SetHint( _T( "Net or Bus Name" ) );
+m_bus_edit->SetHint( _( "Bus Alias Name" ) );
+m_signal_edit->SetHint( _( "Net or Bus Name" ) );

 FinishDialogSettings();
 }


Hi Konstantin-

Thank you for the patch.  It looks like JP already took care of this in 
120637bd9bdc1d1d836d3c8172a88a47e2f12e1d


Best-
Seth

___
Mailing list: https://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] repetitive string...

[Seth Hillbrand]

On 2019-07-30 10:40, Marco Ciampa wrote:

Hi devs,
a (possible, as usual) silly question...

Is it possible to parameterize this string?

pcb_actions.cpp

...
TOOL_ACTION PCB_ACTIONS::layerInner28( "pcbnew.Control.layerInner28",
AS_GLOBAL, 0, "",
_( "Switch to Inner layer 28" ), "",
nullptr, AF_NONE, (void*) In28_Cu );
...

to avoid to have translate some 32 completely similar strings X all
languages just for the inner layer number?

If the answer is "no", please just delete this message...



Hi Marco-

Sorry for the delay in response.  In the current setup, we can't 
parameterize these.  But we're going to be implementing a sequence-based 
hotkey structure during v6.  I imagine that this set of actions will be 
prime candidates, so the hotkey string will only be something like 
"Switch to layer number..." and the second key in the sequence will 
represent the layer number and not need a translation.


Best-
Seth

___
Mailing list: https://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] How to make single-plane .cpp from .png?

[Nick Østergaard]

Maybe I am off here, butnis there any reason why you can just enable the
MAINTAIN_PNGS option to make it convert the svg to cpp?

tir. 6. aug. 2019 06.01 skrev Johannes Sprigode :

> If I may chip in.
>
> The new symbols (16x16) I created for the horizontal text are done in
> inkscape and exported as png.
>
> Post processed in gimp to an 8-bit grey scale with alpha which reduced
> them from ~300 to ~170 something bytes.
>
> They still appear to have the same quality as you have seen. Settings
> attached.
>
> The same should be doable for those cursors, or anything alike.
>
> Cheers
>
> Johannes
>
> On 6/08/19 9:51 AM, Jeff Young wrote:
> > If you open the PNG in Gimp and then export as XBM it works.  (Note that
> while wxBitmap’s constructor purports to support sizes, if you pass
> anything under 32x32 you’ll get garbage.)
> >
> > However, the cursors aren’t greyscale (they’re true black-and-white), so
> the whole SVG source idea produces some pretty ugly cursors.  I think we’ll
> have to specify them as bitmaps.
> >
> >> On 5 Aug 2019, at 15:25, Jeff Young  wrote:
> >>
> >> I also tried online converters for PNG -> XBM and directly from the
> source (SVG -> XBM), but they all give me black images….
> >>
> >>
> >>> On 5 Aug 2019, at 15:15, Jeff Young  wrote:
> >>>
> >>> I found doc on the colour modes; 0 is monochrome without alpha, 2 is
> RGB, 4 is monochrome with alpha and 6 is RGBA.
> >>>
> >>> So -c 0 should be correct.
> >>>
> >>> But it appears wxBitmap is expecting XBM data rather than PNG data.
> Hm…..
> >>>
> >>>
>  On 5 Aug 2019, at 14:46, Jeff Young  wrote:
> 
>  pngcrush -c 0 makes a single-plane char array, but it appears to be
> in a different order or something (the array is the right size, but
> produces a garbage cursor).
> 
>  Anyone know what the other colour modes are?  (0, 2, 4, 6)
> 
> > On 5 Aug 2019, at 13:22, Jeff Young  wrote:
> >
> > Our PNG2cpp.cmake script makes a 3 or 4 plane (ie: colour) char
> array.
> >
> > wxWidgets’ wxBitmap() constructor needs a single plane char array.
> John Beard created a couple for the SPICE cursors, but I’m not sure how he
> did it.
> >
> > Thanks,
> > Jeff.
> >
> >
> > ___
> > Mailing list: https://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
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp