[Kicad-developers] v6 roadmap and schedule (was: Re: 5.1.5 released.)

[Eeli Kaikkonen]

pe 29. marrask. 2019 klo 15.56 Wayne Stambaugh (stambau...@gmail.com)
kirjoitti:
>
> It's not as up to date as it should be but it's pretty close
>
> https://docs.kicad-pcb.org/doxygen/v6_road_map.html


As you surely know, everybody is very interested about not only the
features but also the schedule. In the recent interview you said:

"With Version 6 – due next year – it aims to close the feature parity gap
with the most popular commercial tools in the market."

How realistic this schedule looks right now? I expect you meant the end of
the year.

It would be also interesting to know the order in which the major features
are coming in, and what is coming for sure and what is less sure. For
example, the donation campaign video showed that there are some major parts
more or less ready, waiting to be included. But there has been complete
silence since then. I have been anxiously waiting to be able to test them
in action :)

Eeli Kaikkonen
___
Mailing list: https://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] v6 roadmap and schedule (was Re: 5.1.5 released.)

[Ruth Ivimey-Cook]

Hi,

On 29/11/2019 13:56, Wayne Stambaugh wrote:

It's not as up to date as it should be but it's pretty close

https://docs.kicad-pcb.org/doxygen/v6_road_map.html


I'm hoping some feedback on these goals would be welcomed:



User Interface Modernization

*Goal:*

Give KiCad a more modern user interface with dockable tool bars and 
windows. Create perspectives to allow users to arrange dockable 
windows as they prefer.



Even though v5.1 is better than v5, and v5 better than v4, this is welcomed.


*Task:*

  * Take advantage of the advanced UI features in wxAui such as
detaching and hiding.

The Adobe tools (Photoshop, InDesign et al) have the idea of preset 
workspaces, which are not prescriptive and do not imply anything about 
the way the product works, but are simply arrangements of windows, etc, 
that make sense for the named tasks. I find them helpful when I want to 
"switch mode", whereas I'm happy to do manual changes inline as I work. 
I would encourage KiCad to explore this idea too.



  * Develop a global shortcut manager that allows the user assign
arbitrary shortcuts for any tool or action.

Definitely looking forward to this as well. Can I suggest, as for 
workspaces, that keymaps can be grouped and labelled and easily switched 
between, so that we can have the legacy keymap for those who don't want 
to change, the new keymap, and named custom keymaps. This will make life 
so much easier for users and devs alike.


I would most *definitely recommend* anyone doing UI work on either of 
these topics to explore the JetBrains tools, some of which (e.g. 
PyCharm) have free editions. I very much like their way of setting up 
Keymaps (Preferences), and of being able to search for an action by name 
and invoke it immediately and/or see where it is in the menu (Help 
menu). I also really like the "search for setting" implementation in the 
Preferences window.


I'm not so keen on the JetBrains implementation of floating / docked etc 
windows, which I think was much better done in Visual Studio 
(traditional version). Adobe does several things right in this area as 
well, and IMO it's not clear whether Visual Studio or Photoshop has the 
better "docking window" implementation.


See:

 * https://www.jetbrains.com/pycharm/download/  (PyCharm Community ed.
   is free to use).
 * https://visualstudio.microsoft.com/  (Visual Studio Community 2019)
 * https://www.adobe.com/uk/products/photoshop/free-trial-download.html
   (Adobe Photoshop CC free trial download)



Implement Sweet (S-Expression) Symbol Libraries  / + /
S-Expression File Format

*Goal:*

Make schematic file format more readable, add new features, and take 
advantage of the s-expression parser and formatter capability used in 
Pcbnew.


Just a comment about the file format: *please*, please ensure that there 
is a defined order for writing 'things' in a collection to file.


This is so that loading a project, making some change, and then saving 
it again only changes lines in the output file(s) directly related to to 
change. This so that source control tools like git can track actual 
differences, without being obscured by other, inconsequential ones.


I say this because it seems to me that v5 reads into an unordered 
collection and therefore writes it out unordered, so writing the "same" 
file again may change 90% of it by "chance".


To do this, I think the various file writer implementations must:

  - for every collection/list/set/group, the order of things read in 
from a file must be retained when written out.


  - even when there is flexibility in the file format to reorder data 
chunks, that once a file is read in this order does not change when 
written again (of course, it could be the same order every time).


  - items in the file should not be labelled with transient IDs (e.g. 
the component reference numbers are ok, but a number that is just a 
sequence number for this save is not). This so that inserting something 
doesn't result in every item after that being "changed" because its 
sequence number is now incremented. User-visible changes (reference 
numbers) would be ok: you really are changing lots of things from the 
user perspective.


  - where possible, line breaks should be inserted so that user-visible 
properties that change can be diffed showing just that change and not 
the whole entity. E.g. if the type of a component changes but nothing 
else, you see a diff of the form:


   - type: old name

   + type: new name

There may be more, but those are the basics.



Allow Use of System Fonts

*Goal:*

Currently the schematic editor uses the stroke drawn fonts which 
aren't really necessary for accurate printing of schematics. Allow the 
use of system fonts for schematic text.


*Task:*

  * Determine which library for font handling makes the most sense,
wxWidgets or freetype.
  * Add support for selecting text object fonts.

I would suggest freetype2, on the basis that it is widely p

Re: [Kicad-developers] v6 roadmap and schedule (was: Re: 5.1.5 released.)

[Wayne Stambaugh]

On 11/29/2019 9:32 AM, Eeli Kaikkonen wrote:
> 
> 
> pe 29. marrask. 2019 klo 15.56 Wayne Stambaugh (stambau...@gmail.com
> ) kirjoitti:
>>
>> It's not as up to date as it should be but it's pretty close
>>
>> https://docs.kicad-pcb.org/doxygen/v6_road_map.html
> 
> 
> As you surely know, everybody is very interested about not only the
> features but also the schedule. In the recent interview you said:

I'll give you the standard open source project answer, it will be done
when it's done.  It's the most honest and accurate answer I can give.

> 
> "With Version 6 – due next year – it aims to close the feature parity
> gap with the most popular commercial tools in the market."
> 
> How realistic this schedule looks right now? I expect you meant the end
> of the year.

I don't think it's unrealistic to think that we couldn't get most of
this implemented by the end of 2020 but it all depends on manpower
availability.

> 
> It would be also interesting to know the order in which the major
> features are coming in, and what is coming for sure and what is less
> sure. For example, the donation campaign video showed that there are
> some major parts more or less ready, waiting to be included. But there
> has been complete silence since then. I have been anxiously waiting to
> be able to test them in action :)

There is no way I would attempt to determine or mandate the order which
features get merged.  They will get merged based on their readiness to
be merged.

> 
> Eeli Kaikkonen
> 
> ___
> Mailing list: https://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] v6 roadmap and schedule (was: Re: 5.1.5 released.)

[Eeli Kaikkonen]

pe 29. marrask. 2019 klo 16.41 Wayne Stambaugh (stambau...@gmail.com)
kirjoitti:

>
> There is no way I would attempt to determine or mandate the order which
> features get merged.  They will get merged based on their readiness to
> be merged.
>

I thought there might be something else, like waiting for some other large
features (like the new file formats) getting in first. But this being the
case, we'll just wait. Maybe some of the developers (at CERN or others) may
want to share some information about their work if it's getting closer - it
would just be nice to hear.

Eeli Kaikkonen
___
Mailing list: https://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] v6 roadmap and schedule (was Re: 5.1.5 released.)

[Eeli Kaikkonen]

pe 29. marrask. 2019 klo 20.28 Ruth Ivimey-Cook (r...@ivimey.org) kirjoitti:

> I would be interested to know why it is not possible/good to use "normal"
> outline fonts (ttf, otf et al) on a PCB what are the issues?
>

That's an easy one to answer, at least partially. PCB needs graphics which
can be exported to gerber graphics. In practice this means that font
characters (I think the correct word is "glyph") should be converted to
polygonal outlines. It wouldn't be impossible, but would require writing a
conversion library (or finding an existing one) and integrating into KiCad.
I guess it would be quite resource heavy run time because each character
would be one or several complex polygons. Using a simple font like Arial
would be most realistic - it has lots of straight lines instead of curves.
Serif fonts like Times aren't so fitting for a PCB board anyways because
they wouldn't be so clear in small sizes and because of bad resolution (I
mean the resolution of the physical board, especially silk).

Another option would be to pre-convert some font to polygons and use them,
a bit like the current font system in pcbnew. It now has a font where each
character is a bunch of segments. Only handling polygons instead of
segments would be required.

However, it's not quite that simple. For good results the characters must
be kerned, i.e. the space between any two characters must be decided case
by case bases. Otherwise non-monospace fonts don't look good. That's one
reason why complex font engines are needed in the first place. Just drawing
characters would be relatively easy (except for antialiasing etc. but KiCad
doesn't need to worry about that). So, either the characters should be
drawn without kerning or there should be some way to do the kerning. Maybe
adding kerning to text handling code wouldn't be impossible. I don't know
how the font engines work, but maybe it could be possible to let an
external font engine do the layout to a dummy backend without it knowing
about the actual visual output and then find the locations of characters.

Another thing to think of is the physical quality of the manufactured board
which should be the greatest concern. Silk screen resolution is bad. That
means that the text would look decent only in large size, especially when
made by cheap technologies. Text in copper or mask is better. But in any
case it would be much work which would benefit little.

Still I think it would great to have it in KiCad. Maybe someone could write
a python plugin? It would be possible to create text as graphic polygons,
although it wouldn't be possible to handle it as normal native text. But it
would help if someone needs nice text for end users of a board.

Eeli Kaikkonen
___
Mailing list: https://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] v6 roadmap and schedule (was Re: 5.1.5 released.)

[Eeli Kaikkonen]

pe 29. marrask. 2019 klo 20.28 Ruth Ivimey-Cook (r...@ivimey.org) kirjoitti:

>
> I'm not sure if it's been dealt with already but one of the issues I
> struggle with is that component boundaries are the enclosing box, and
> components cannot (AFAIK) be marked as not selectable. For example, I have
> a "component" which is the outline of a daughterboard (for a BB Black). The
> component ensures the relation between the edge cuts and the connector
> footprint is maintained. However, on more than one occasion I have messed
> up the board badly by moving the board component without realizing it.
>
> I have two requests from this situation:
>
> 1.  I would *really* like to be able to lock components in place,
> preventing them from being moved (or even selected) until unlocked. Lock =
> select and "Lock", Unlocking might be done with a separate list of locked
> items, or with a UI action that unlocks anything in a drawn area, or by an
> Unlock All action.
>
> 2.  I would like the selection code to prefer selecting items by visible
> artefact, e.g. a line or some text, and only if there is no such artefact
> under the cursor to consider things nearby. I'm particularly thinking here
> of clicking on an component placed beside e.g. an IC footprint, though not
> on it. If the component is under the cursor then that should be selected
> directly even if the cursor is also within the bounding box of the IC.
>
>
https://bugs.launchpad.net/kicad/+bug/1832986
https://bugs.launchpad.net/kicad/+bug/1745627
___
Mailing list: https://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] v6 roadmap and schedule (was Re: 5.1.5 released.)

[Wayne Stambaugh]

Hi Ruth,

Feedback is always welcome.  For V6, I'm trying to keep us on track for
the road map items as they stand.  Rehashing these goals at the moment
would be counter productive but I'm certainly willing to entertain your
suggestion once we've released V6.  For future reference, please post
one email per topic.  I know this is more work from your perspective but
there is no way to manage an email thread covering every topic you
mentioned.

Thanks,

Wayne

On 11/29/19 1:28 PM, Ruth Ivimey-Cook wrote:
> Hi,
> 
> On 29/11/2019 13:56, Wayne Stambaugh wrote:
>> It's not as up to date as it should be but it's pretty close
>>
>> https://docs.kicad-pcb.org/doxygen/v6_road_map.html
> 
> I'm hoping some feedback on these goals would be welcomed:
> 
> 
>> User Interface Modernization
>>
>> *Goal:*
>>
>> Give KiCad a more modern user interface with dockable tool bars and
>> windows. Create perspectives to allow users to arrange dockable
>> windows as they prefer.
>>
> Even though v5.1 is better than v5, and v5 better than v4, this is welcomed.
> 
>> *Task:*
>>
>>   * Take advantage of the advanced UI features in wxAui such as
>> detaching and hiding.
>>
> The Adobe tools (Photoshop, InDesign et al) have the idea of preset
> workspaces, which are not prescriptive and do not imply anything about
> the way the product works, but are simply arrangements of windows, etc,
> that make sense for the named tasks. I find them helpful when I want to
> "switch mode", whereas I'm happy to do manual changes inline as I work.
> I would encourage KiCad to explore this idea too.
> 
>>   * Develop a global shortcut manager that allows the user assign
>> arbitrary shortcuts for any tool or action.
>>
> Definitely looking forward to this as well. Can I suggest, as for
> workspaces, that keymaps can be grouped and labelled and easily switched
> between, so that we can have the legacy keymap for those who don't want
> to change, the new keymap, and named custom keymaps. This will make life
> so much easier for users and devs alike.
> 
> I would most *definitely recommend* anyone doing UI work on either of
> these topics to explore the JetBrains tools, some of which (e.g.
> PyCharm) have free editions. I very much like their way of setting up
> Keymaps (Preferences), and of being able to search for an action by name
> and invoke it immediately and/or see where it is in the menu (Help
> menu). I also really like the "search for setting" implementation in the
> Preferences window.
> 
> I'm not so keen on the JetBrains implementation of floating / docked etc
> windows, which I think was much better done in Visual Studio
> (traditional version). Adobe does several things right in this area as
> well, and IMO it's not clear whether Visual Studio or Photoshop has the
> better "docking window" implementation.
> 
> See:
> 
>   * https://www.jetbrains.com/pycharm/download/  (PyCharm Community ed.
> is free to use).
>   * https://visualstudio.microsoft.com/  (Visual Studio Community 2019)
>   * https://www.adobe.com/uk/products/photoshop/free-trial-download.html  
> (Adobe
> Photoshop CC free trial download)
> 
> 
>> Implement Sweet (S-Expression) Symbol Libraries  / + / 
>> S-Expression File Format
>>
>> *Goal:*
>>
>> Make schematic file format more readable, add new features, and take
>> advantage of the s-expression parser and formatter capability used in
>> Pcbnew.
>>
> Just a comment about the file format: *please*, please ensure that there
> is a defined order for writing 'things' in a collection to file.
> 
> This is so that loading a project, making some change, and then saving
> it again only changes lines in the output file(s) directly related to to
> change. This so that source control tools like git can track actual
> differences, without being obscured by other, inconsequential ones.
> 
> I say this because it seems to me that v5 reads into an unordered
> collection and therefore writes it out unordered, so writing the "same"
> file again may change 90% of it by "chance".
> 
> To do this, I think the various file writer implementations must:
> 
>   - for every collection/list/set/group, the order of things read in
> from a file must be retained when written out.
> 
>   - even when there is flexibility in the file format to reorder data
> chunks, that once a file is read in this order does not change when
> written again (of course, it could be the same order every time).
> 
>   - items in the file should not be labelled with transient IDs (e.g.
> the component reference numbers are ok, but a number that is just a
> sequence number for this save is not). This so that inserting something
> doesn't result in every item after that being "changed" because its
> sequence number is now incremented. User-visible changes (reference
> numbers) would be ok: you really are changing lots of things from the
> user perspective.
> 
>   - where possible, line breaks should be inserted so that user-visible
> properties that 

Re: [Kicad-developers] v6 roadmap and schedule (was Re: 5.1.5 released.)

[Jeff Young]

There’s some great stuff in here though on some of the topics we are doing.  
I’m not sure how best to work in to the email discussions that are bound to 
come up, but I’ve flagged it in my email inbox.

Cheers,
Jeff.

Oh, and for what it’s worth, our main UI guy spent 25 years at Adobe, and uses 
JetBrains for Kicad development. ;)

> On 2 Dec 2019, at 18:56, Wayne Stambaugh  wrote:
> 
> Hi Ruth,
> 
> Feedback is always welcome.  For V6, I'm trying to keep us on track for
> the road map items as they stand.  Rehashing these goals at the moment
> would be counter productive but I'm certainly willing to entertain your
> suggestion once we've released V6.  For future reference, please post
> one email per topic.  I know this is more work from your perspective but
> there is no way to manage an email thread covering every topic you
> mentioned.
> 
> Thanks,
> 
> Wayne
> 
> On 11/29/19 1:28 PM, Ruth Ivimey-Cook wrote:
>> Hi,
>> 
>> On 29/11/2019 13:56, Wayne Stambaugh wrote:
>>> It's not as up to date as it should be but it's pretty close
>>> 
>>> https://docs.kicad-pcb.org/doxygen/v6_road_map.html
>> 
>> I'm hoping some feedback on these goals would be welcomed:
>> 
>> 
>>>User Interface Modernization
>>> 
>>> *Goal:*
>>> 
>>> Give KiCad a more modern user interface with dockable tool bars and
>>> windows. Create perspectives to allow users to arrange dockable
>>> windows as they prefer.
>>> 
>> Even though v5.1 is better than v5, and v5 better than v4, this is welcomed.
>> 
>>> *Task:*
>>> 
>>>  * Take advantage of the advanced UI features in wxAui such as
>>>detaching and hiding.
>>> 
>> The Adobe tools (Photoshop, InDesign et al) have the idea of preset
>> workspaces, which are not prescriptive and do not imply anything about
>> the way the product works, but are simply arrangements of windows, etc,
>> that make sense for the named tasks. I find them helpful when I want to
>> "switch mode", whereas I'm happy to do manual changes inline as I work.
>> I would encourage KiCad to explore this idea too.
>> 
>>>  * Develop a global shortcut manager that allows the user assign
>>>arbitrary shortcuts for any tool or action.
>>> 
>> Definitely looking forward to this as well. Can I suggest, as for
>> workspaces, that keymaps can be grouped and labelled and easily switched
>> between, so that we can have the legacy keymap for those who don't want
>> to change, the new keymap, and named custom keymaps. This will make life
>> so much easier for users and devs alike.
>> 
>> I would most *definitely recommend* anyone doing UI work on either of
>> these topics to explore the JetBrains tools, some of which (e.g.
>> PyCharm) have free editions. I very much like their way of setting up
>> Keymaps (Preferences), and of being able to search for an action by name
>> and invoke it immediately and/or see where it is in the menu (Help
>> menu). I also really like the "search for setting" implementation in the
>> Preferences window.
>> 
>> I'm not so keen on the JetBrains implementation of floating / docked etc
>> windows, which I think was much better done in Visual Studio
>> (traditional version). Adobe does several things right in this area as
>> well, and IMO it's not clear whether Visual Studio or Photoshop has the
>> better "docking window" implementation.
>> 
>> See:
>> 
>>  * https://www.jetbrains.com/pycharm/download/  (PyCharm Community ed.
>>is free to use).
>>  * https://visualstudio.microsoft.com/  (Visual Studio Community 2019)
>>  * https://www.adobe.com/uk/products/photoshop/free-trial-download.html  
>> (Adobe
>>Photoshop CC free trial download)
>> 
>> 
>>>Implement Sweet (S-Expression) Symbol Libraries  / + / 
>>>S-Expression File Format
>>> 
>>> *Goal:*
>>> 
>>> Make schematic file format more readable, add new features, and take
>>> advantage of the s-expression parser and formatter capability used in
>>> Pcbnew.
>>> 
>> Just a comment about the file format: *please*, please ensure that there
>> is a defined order for writing 'things' in a collection to file.
>> 
>> This is so that loading a project, making some change, and then saving
>> it again only changes lines in the output file(s) directly related to to
>> change. This so that source control tools like git can track actual
>> differences, without being obscured by other, inconsequential ones.
>> 
>> I say this because it seems to me that v5 reads into an unordered
>> collection and therefore writes it out unordered, so writing the "same"
>> file again may change 90% of it by "chance".
>> 
>> To do this, I think the various file writer implementations must:
>> 
>>   - for every collection/list/set/group, the order of things read in
>> from a file must be retained when written out.
>> 
>>   - even when there is flexibility in the file format to reorder data
>> chunks, that once a file is read in this order does not change when
>> written again (of course, it could be the same order every time).
>> 
>>   - items in the file shoul

Re: [Kicad-developers] v6 roadmap and schedule (was Re: 5.1.5 released.)

[Ruth Ivimey-Cook]

Thanks Jeff, and others, for your appreciation.

I'll go back into Lurk now :-)

Regards

Ruth


On 02/12/2019 19:04, Jeff Young wrote:
There’s some great stuff in here though on some of the topics we /are/ 
doing.  I’m not sure how best to work in to the email discussions that 
are bound to come up, but I’ve flagged it in my email inbox.


Cheers,
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

Re: [Kicad-developers] v6 roadmap and schedule (was Re: 5.1.5 released.)

[Eeli Kaikkonen]

It might be good to add links to relevant issues (bug/wishlist reports) to
the roadmap. Readers would find more details and take part into
discussions. Now when the document is in gitlab it's easy to add some and
make a merge request. Is it OK if I do that?

Eeli Kaikkonen

ma 2. jouluk. 2019 klo 20.56 Wayne Stambaugh (stambau...@gmail.com)
kirjoitti:

> Hi Ruth,
>
> Feedback is always welcome.  For V6, I'm trying to keep us on track for
> the road map items as they stand.  Rehashing these goals at the moment
> would be counter productive but I'm certainly willing to entertain your
> suggestion once we've released V6.  For future reference, please post
> one email per topic.  I know this is more work from your perspective but
> there is no way to manage an email thread covering every topic you
> mentioned.
>
> 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

Re: [Kicad-developers] v6 roadmap and schedule (was Re: 5.1.5 released.)

[Wayne Stambaugh]

Moving forward, I'm seriously considering dropping the current road map
for a different system.  I can never find the time to keep it up to date
and it's not a good format for commenting or tracking.  Once the dust
has settled from the GitLab migration, the lead development team will
put together a strategy for road mapping that make more sense than what
we are currently doing.  It might be a while before this happens as we
all have lot's of work to do for V6.

Cheers,

Wayne

On 12/2/19 2:49 PM, Eeli Kaikkonen wrote:
> It might be good to add links to relevant issues (bug/wishlist reports)
> to the roadmap. Readers would find more details and take part into
> discussions. Now when the document is in gitlab it's easy to add some
> and make a merge request. Is it OK if I do that?
> 
> Eeli Kaikkonen
> 
> ma 2. jouluk. 2019 klo 20.56 Wayne Stambaugh (stambau...@gmail.com
> ) kirjoitti:
> 
> Hi Ruth,
> 
> Feedback is always welcome.  For V6, I'm trying to keep us on track for
> the road map items as they stand.  Rehashing these goals at the moment
> would be counter productive but I'm certainly willing to entertain your
> suggestion once we've released V6.  For future reference, please post
> one email per topic.  I know this is more work from your perspective but
> there is no way to manage an email thread covering every topic you
> mentioned.
> 
> 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