Re: [Kicad-developers] Back annotate references from PCB

[jp charras]

Le 24/11/2019 à 07:58, Alexander Shuklin a écrit :
> Hi Eeli and Brian,
> Sorry for delay, unfortunately I cannot answer too often.
> 
>> It has occurred to me (Alexander please chime in) that once back annotation 
>> has been solved subject to all the issues raised by Wayne and others that it 
>> would be a general solution.
> 
> Unfortunately no. All stuff mentioned by Wayne is has to be
> implemented in back-annotation, that's situations which back
> annotation will have to care about, otherwise it will be crap. I meant
> I see some general tool as geometrical (geographical?) re-annotation
> in pcbnew, which do left->right top->down or opposite directions being
> in C++ GUI, but if you want re-annotate in some different manner, you
> are free to use python scripts, as you could easily back annotate
> after that.
> 
>> Can this do other kinds of changes than just annotation? I'm thinking of 
>> changing the footprint or value
> 
> Of course that's possible, and not a big deal to add this into
> back-annotation algorithm. I just think how to do it better. I would
> say we will need to have some GUI for that then. I mean, you probably
> want to choose what do you want to back-annotate... or maybe not. And
> unfortunately at this point you cannot do that with python, as there
> no python scripts in schematic editor. If it will be useful, I can do
> that of course. Eeli, what I would suggest, I believe in few days I
> will make draft commit and mark it (Work In Progress) to show how It
> works, and we could discuss how it's gonna work with values and
> footprints it will not be a big deal to change it.

Back annotation imply undo/redo feature.
It locks like it will be not trivial.

> 
> On Sat, 23 Nov 2019 at 21:03, Brian Piccioni
>  wrote:
>>
>> It has occurred to me (Alexander please chime in) that once back annotation 
>> has been solved subject to all the issues raised by Wayne and others that it 
>> would be a general solution.
>>
>>
>>
>> Of course, this would end up being a sizeable change to Kicad since the 
>> various edit functions, etc., who have to be modified to incorporate the 
>> feature.
>>
>>
>>
>> Like you I often fiddle with different packages and values and I typically 
>> switch to eeSchema, make the change, then hit F8 to update the PCB. It seems 
>> to me it would be easier for the appropriate changes to simply be reflected 
>> back to the schematic.
>>
>>
>>
>> Brian
>>
>>
>>
>> From: Eeli Kaikkonen
>> Sent: November 23, 2019 12:56 PM
>> To: kicad-developers
>> Subject: Re: [Kicad-developers] Back annotate references from PCB
>>
>>
>>
>>
>>
>>
>>
>> la 23. marrask. 2019 klo 14.52 Brian Piccioni (br...@documenteddesigns.com) 
>> kirjoitti:
>>
>> By having a single integrated tool analogous to “Update PCB From Schematic” 
>> can ensure coherency.
>>
>> Can this do other kinds of changes than just annotation? I'm thinking of 
>> changing the footprint or value. For example I could use Change Footprint 
>> feature in pcbnew and propagate that change to eeschema. That's not so 
>> difficult to do in eeshcema and update the board, but often it would feel 
>> much more natural to e.g. test if 0402 R package would be physically better 
>> for some situation than 0603 and then update the shcematic based on the 
>> board if it fits.
>>
>>
>>
>> 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
> 


-- 
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] Back annotate references from PCB

[Alexander Shuklin]

Hi Eeli and Brian,
Sorry for delay, unfortunately I cannot answer too often.

> It has occurred to me (Alexander please chime in) that once back annotation 
> has been solved subject to all the issues raised by Wayne and others that it 
> would be a general solution.

Unfortunately no. All stuff mentioned by Wayne is has to be
implemented in back-annotation, that's situations which back
annotation will have to care about, otherwise it will be crap. I meant
I see some general tool as geometrical (geographical?) re-annotation
in pcbnew, which do left->right top->down or opposite directions being
in C++ GUI, but if you want re-annotate in some different manner, you
are free to use python scripts, as you could easily back annotate
after that.

> Can this do other kinds of changes than just annotation? I'm thinking of 
> changing the footprint or value

Of course that's possible, and not a big deal to add this into
back-annotation algorithm. I just think how to do it better. I would
say we will need to have some GUI for that then. I mean, you probably
want to choose what do you want to back-annotate... or maybe not. And
unfortunately at this point you cannot do that with python, as there
no python scripts in schematic editor. If it will be useful, I can do
that of course. Eeli, what I would suggest, I believe in few days I
will make draft commit and mark it (Work In Progress) to show how It
works, and we could discuss how it's gonna work with values and
footprints it will not be a big deal to change it.

On Sat, 23 Nov 2019 at 21:03, Brian Piccioni
 wrote:
>
> It has occurred to me (Alexander please chime in) that once back annotation 
> has been solved subject to all the issues raised by Wayne and others that it 
> would be a general solution.
>
>
>
> Of course, this would end up being a sizeable change to Kicad since the 
> various edit functions, etc., who have to be modified to incorporate the 
> feature.
>
>
>
> Like you I often fiddle with different packages and values and I typically 
> switch to eeSchema, make the change, then hit F8 to update the PCB. It seems 
> to me it would be easier for the appropriate changes to simply be reflected 
> back to the schematic.
>
>
>
> Brian
>
>
>
> From: Eeli Kaikkonen
> Sent: November 23, 2019 12:56 PM
> To: kicad-developers
> Subject: Re: [Kicad-developers] Back annotate references from PCB
>
>
>
>
>
>
>
> la 23. marrask. 2019 klo 14.52 Brian Piccioni (br...@documenteddesigns.com) 
> kirjoitti:
>
> By having a single integrated tool analogous to “Update PCB From Schematic” 
> can ensure coherency.
>
> Can this do other kinds of changes than just annotation? I'm thinking of 
> changing the footprint or value. For example I could use Change Footprint 
> feature in pcbnew and propagate that change to eeschema. That's not so 
> difficult to do in eeshcema and update the board, but often it would feel 
> much more natural to e.g. test if 0402 R package would be physically better 
> for some situation than 0603 and then update the shcematic based on the board 
> if it fits.
>
>
>
> 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] KiCad joins the Linux Foundation

[Mark Roszko]

The attempt I took on adding TLF is live.

On Sat, Nov 23, 2019 at 8:45 AM Wayne Stambaugh 
wrote:

> Hi Sujith,
>
> I got it.  Thank you.
>
> Cheers,
>
> Wayne
>
> On 11/22/19 10:09 PM, Sujith Anandan wrote:
> > Hello Wayne,
> >
> > I have already added you as page admin, please accept the request you
> > will get in facebook.
> >
> > Thanks.
> > Sujith
> >
> > On Sat, Nov 23, 2019 at 5:15 AM Wayne Stambaugh  > > wrote:
> >
> > I was wondering about that myself.  We can try a donate page and see
> how
> > it works.  We can always change it if we don't like it.
> >
> > On 11/22/19 3:53 PM, Mark Roszko wrote:
> > > I'm not sure about adding a second button in the header.
> > >
> > > I am envisioning creating a "Donate" page with both CERN and Linux
> > > foundation options presented clearly with one big button for each
> > and a
> > > small blurb for what each does. The header will go to this
> > intermediate
> > > page.
> > >
> > > On Fri, Nov 22, 2019 at 2:50 PM Wayne Stambaugh
> > mailto:stambau...@gmail.com>
> > > >>
> wrote:
> > >
> > >
> > >
> > > On 11/22/19 2:39 PM, Mark Roszko wrote:
> > > >> I need to add a "Donate via Linux Foundation" button to the
> > KiCad
> > > > website main page.
> > > >
> > > > But is it in addition to or to replace CERN?
> > >
> > > In addition to.
> > >
> > > >
> > > >
> > > >
> > > > On Fri, Nov 22, 2019 at 12:03 PM Wayne Stambaugh
> > > mailto:stambau...@gmail.com>
> > >
> > > > 
> >  > > >
> > > > I just pushed a blog post to the KiCad website that
> > KiCad has
> > > joined the
> > > > Linux Foundation so consider this the official
> > announcement.  The
> > > > project did this to give donors a choice of how they
> want to
> > > donate to
> > > > KiCad and it gives us some more flexibility on how we can
> > > spend donation
> > > > money.  This does not in any way change our relationship
> > with
> > > CERN and
> > > > you can continue to donate via CERN if that is your
> > > preference.  You
> > > > should be seeing announcements from the Linux Foundation
> > shortly.
> > > >
> > > > I need to add a "Donate via Linux Foundation" button to
> > the KiCad
> > > > website main page.  If someone would please point me to
> the
> > > correct
> > > > place in the website source where I need to do this, I
> would
> > > appreciate
> > > > it.  If you would rather do it yourself, the KiCad LF
> > donation
> > > link is
> > > > https://funding.communitybridge.org/projects/kicad.
> > > >
> > > > Who has the account login information for the KiCad
> Facebook
> > > page?  I
> > > > didn't create this so it would be nice if I had edit
> > access so
> > > I could
> > > > post announcements there instead of asking someone else
> > to do it.
> > > >
> > > > I hope joining the Linux Foundation will improve our
> > potential
> > > donor
> > > > visibility so we can continue to grow the KiCad project.
> > > Thank you all
> > > > for your continued support.
> > > >
> > > > 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
> > > >
> > > >
> > > >
> > > > --
> > > > Mark
> > >
> > >
> > >
> > > --
> > > Mark
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > 

Re: [Kicad-developers] Back annotate references from PCB

[Brian Piccioni]

It has occurred to me (Alexander please chime in) that once back annotation has been solved subject to all the issues raised by Wayne and others that it would be a general solution. Of course, this would end up being a sizeable change to Kicad since the various edit functions, etc., who have to be modified to incorporate the feature. Like you I often fiddle with different packages and values and I typically switch to eeSchema, make the change, then hit F8 to update the PCB. It seems to me it would be easier for the appropriate changes to simply be reflected back to the schematic. Brian From: Eeli KaikkonenSent: November 23, 2019 12:56 PMTo: kicad-developersSubject: Re: [Kicad-developers] Back annotate references from PCB   la 23. marrask. 2019 klo 14.52 Brian Piccioni (br...@documenteddesigns.com) kirjoitti:By having a single integrated tool analogous to “Update PCB From Schematic” can ensure coherency.Can this do other kinds of changes than just annotation? I'm thinking of changing the footprint or value. For example I could use Change Footprint feature in pcbnew and propagate that change to eeschema. That's not so difficult to do in eeshcema and update the board, but often it would feel much more natural to e.g. test if 0402 R package would be physically better for some situation than 0603 and then update the shcematic based on the board if it fits. 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] Back annotate references from PCB

[Eeli Kaikkonen]

la 23. marrask. 2019 klo 14.52 Brian Piccioni (br...@documenteddesigns.com)
kirjoitti:

> By having a single integrated tool analogous to “Update PCB From
> Schematic” can ensure coherency.
>
Can this do other kinds of changes than just annotation? I'm thinking of
changing the footprint or value. For example I could use Change Footprint
feature in pcbnew and propagate that change to eeschema. That's not so
difficult to do in eeshcema and update the board, but often it would feel
much more natural to e.g. test if 0402 R package would be physically better
for some situation than 0603 and then update the shcematic based on the
board if it fits.

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] INFO: added a enhancement: schematic pin function stored in pads.

[jp charras]

I just added a enhancement in Pcbnew:
After updating the PCB from schematic, the pin names (pin functions) are
now stored in Pads.

When not empty, they are shown in the message panel (bottom of the pcb
editor frame) among other pad settings (like netname).

This enhancement is due to the fact Gerber files can use (in the
metadata parameters) this info (it is shown by Gerbview) and Pick and
Place files in Gerber format also use this info.
In P files it is especially useful to help to verify is some
components (like diodes, polarized capacitor) are correctly oriented.

However, because storing pin function in pads modify the .kicad_pcb file
format, currently this new info is saved in files *only* if the line
UsePinFunction=1
is added to the "kicad_advanced" config file, in the folder where other
kicad config files are stored.
(until this enhancement is fully tested and fully defined)
If stored, the .kicad_pcb file is no longer readable by "old" versions.

.kicad_mod files do not store this info, as it is closely linked to the
net info, so no change for them.


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

[Kicad-developers] [PATCH 0/1] Experimental code for running tests separately

[Simon Richter]

Hi,

this is not meant for immediate merging, but maybe of interest to some:
this patch splits the test cases inside the Boost.Test based tests in a way
that is visible to CTest.

The downside is that running the tests now takes ages because Boost.Test
setup is really slow, the upside is that individual test cases show up in
the log, and no trickery with logfiles is needed. Running valgrind on
individual tests is also possible in theory, but useless in practice
because glib doesn't have an equivalent to __libc_freeres(), so we get 294
false positives from glib for every test.

If someone wants to pursue this further, here is the code.

   Simon

Simon Richter (1):
  Split Boost.Test based tests

 CMakeModules/BoostTest.cmake | 204 +++
 CMakeModules/BoostTestAddTests.cmake | 138 ++
 qa/CMakeLists.txt|   1 +
 qa/common/CMakeLists.txt |   6 +-
 qa/eeschema/CMakeLists.txt   |   2 +-
 qa/libs/sexpr/CMakeLists.txt |   2 +-
 qa/pcbnew/CMakeLists.txt |   2 +-
 qa/utils/kicad2step/CMakeLists.txt   |   2 +-
 8 files changed, 350 insertions(+), 7 deletions(-)
 create mode 100644 CMakeModules/BoostTest.cmake
 create mode 100644 CMakeModules/BoostTestAddTests.cmake

-- 
2.24.0


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

[Kicad-developers] [PATCH 1/1] Split Boost.Test based tests

[Simon Richter]

---
 CMakeModules/BoostTest.cmake | 204 +++
 CMakeModules/BoostTestAddTests.cmake | 138 ++
 qa/CMakeLists.txt|   1 +
 qa/common/CMakeLists.txt |   6 +-
 qa/eeschema/CMakeLists.txt   |   2 +-
 qa/libs/sexpr/CMakeLists.txt |   2 +-
 qa/pcbnew/CMakeLists.txt |   2 +-
 qa/utils/kicad2step/CMakeLists.txt   |   2 +-
 8 files changed, 350 insertions(+), 7 deletions(-)
 create mode 100644 CMakeModules/BoostTest.cmake
 create mode 100644 CMakeModules/BoostTestAddTests.cmake

diff --git a/CMakeModules/BoostTest.cmake b/CMakeModules/BoostTest.cmake
new file mode 100644
index 0..ec3419694
--- /dev/null
+++ b/CMakeModules/BoostTest.cmake
@@ -0,0 +1,204 @@
+# Distributed under the OSI-approved BSD 3-Clause License.  See accompanying
+# file Copyright.txt or https://cmake.org/licensing for details.
+
+#[===[.rst:
+BoostTest
+--
+
+This module defines functions to help use the Boost.Test infrastructure.
+
+The :command:`boost_test_discover_tests` discovers tests by asking the
+compiled test executable to enumerate its tests.
+
+This commands is intended to replace use of :command:`add_test` to register
+tests, and will create a separate CTest test for each Boost.Test test case.
+Note that this is in some cases less efficient, as common set-up and tear-down
+logic cannot be shared by multiple test cases executing in the same instance.
+However, it provides more fine-grained pass/fail information to CTest, which is
+usually considered as more beneficial.  By default, the CTest test name is the
+same as the Boost.Test name (i.e. ``suite.testcase``); see also
+``TEST_PREFIX`` and ``TEST_SUFFIX``.
+
+.. command:: boost_test_discover_tests
+
+  Automatically add tests with CTest by querying the compiled test executable
+  for available tests::
+
+boost_test_discover_tests(target
+  [EXTRA_ARGS arg1...]
+  [WORKING_DIRECTORY dir]
+  [TEST_PREFIX prefix]
+  [TEST_SUFFIX suffix]
+  [PROPERTIES name1 value1...]
+  [TEST_LIST var]
+  [DISCOVERY_TIMEOUT seconds]
+)
+
+  ``boost_test_discover_tests`` sets up a post-build command on the test executable
+  that generates the list of tests by parsing the output from running the test
+  with the ``--boost_test_list_tests`` argument.  This ensures that the full list of
+  tests, including instantiations of parameterized tests, is obtained.  Since
+  test discovery occurs at build time, it is not necessary to re-run CMake when
+  the list of tests changes.
+  However, it requires that :prop_tgt:`CROSSCOMPILING_EMULATOR` is properly set
+  in order to function in a cross-compiling environment.
+
+  Additionally, setting properties on tests is somewhat less convenient, since
+  the tests are not available at CMake time.  Additional test properties may be
+  assigned to the set of tests as a whole using the ``PROPERTIES`` option.  If
+  more fine-grained test control is needed, custom content may be provided
+  through an external CTest script using the :prop_dir:`TEST_INCLUDE_FILES`
+  directory property.  The set of discovered tests is made accessible to such a
+  script via the ``_TESTS`` variable.
+
+  The options are:
+
+  ``target``
+Specifies the Boost.Test executable, which must be a known CMake
+executable target.  CMake will substitute the location of the built
+executable when running the test.
+
+  ``EXTRA_ARGS arg1...``
+Any extra arguments to pass on the command line to each test case.
+
+  ``WORKING_DIRECTORY dir``
+Specifies the directory in which to run the discovered test cases.  If this
+option is not provided, the current binary directory is used.
+
+  ``TEST_PREFIX prefix``
+Specifies a ``prefix`` to be prepended to the name of each discovered test
+case.  This can be useful when the same test executable is being used in
+multiple calls to ``boost_test_discover_tests()`` but with different
+``EXTRA_ARGS``.
+
+  ``TEST_SUFFIX suffix``
+Similar to ``TEST_PREFIX`` except the ``suffix`` is appended to the name of
+every discovered test case.  Both ``TEST_PREFIX`` and ``TEST_SUFFIX`` may
+be specified.
+
+  ``PROPERTIES name1 value1...``
+Specifies additional properties to be set on all tests discovered by this
+invocation of ``boost_test_discover_tests``.
+
+  ``TEST_LIST var``
+Make the list of tests available in the variable ``var``, rather than the
+default ``_TESTS``.  This can be useful when the same test
+executable is being used in multiple calls to ``boost_test_discover_tests()``.
+Note that this variable is only available in CTest.
+
+  ``DISCOVERY_TIMEOUT num``
+Specifies how long (in seconds) CMake 

Re: [Kicad-developers] [PATCH] Selection appearance options

[Jonatan Liljedahl]

Thanks Seth,

I'm on Mac only (my linux box hasn't been powered on since 5 years or so).
The code I touched should not look different depending on platform. I guess
any difference would rather be in how colors are presented (considering the
#ifdef MAC around default selection-highlight color), but even in that case
I strongly suspect this is rather about the monitor rather than operating
system!

Cheers

On Fri, Nov 22, 2019 at 6:25 PM Seth Hillbrand  wrote:

> On 11/21/19 8:01 AM, Jonatan Liljedahl wrote:
>
> Hi,
>
> Here comes two patches regarding the selection appearance.
>
> Patch #1: Adds three new options in the settings dialog:
>
> - Draw selected text items as box
> Instead of drawing a stroked shadow behind the text, a rounded
> rectangle is drawn according to the text boundary box.
>
> - Draw selected child items
> When disabled, only the main selected item is drawn with the selection
> shadow, not the various fields and pin names etc. Default is enabled
> (current behaviour)
>
> - Fill selected shapes
> Any selected shapes has their selection shadow filled, instead of just
> drawing along the lines.
>
> See attached screenshots for a demonstration of some various
> combinations of these settings.
>
> Patch #2: Tweaks the amount of zoom-level impact on the selection
> shadow thickness, to get a more coherent look while zooming. You need
> to try this in action to know if it's good (I think it is).
>
> Cheers
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
> Hi Jonatan-
>
> Thanks for this patch.  I'll give this a test run this weekend.  I know
> that the Mac display of highlight was always a bit different than Linux, so
> it would be good if one of our Mac devs also tested for issues.
>
> Best-
> Seth
>
> --
> KiCad Services Corporation [image: KiCad Services Corporation Logo]
> Seth Hillbrand
> *Lead Developer*
> +1-530-302-5483‬ <+12126039372>
> Davis, CA
> www.kipro-pcb.comi...@kipro-pcb.com
> https://twitter.com/KiProEDA 
> https://www.linkedin.com/company/kicad
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>


-- 
/Jonatan
http://kymatica.com
___
Mailing list: https://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 joins the Linux Foundation

[Wayne Stambaugh]

Hi Sujith,

I got it.  Thank you.

Cheers,

Wayne

On 11/22/19 10:09 PM, Sujith Anandan wrote:
> Hello Wayne,
> 
> I have already added you as page admin, please accept the request you
> will get in facebook.
> 
> Thanks.
> Sujith
> 
> On Sat, Nov 23, 2019 at 5:15 AM Wayne Stambaugh  > wrote:
> 
> I was wondering about that myself.  We can try a donate page and see how
> it works.  We can always change it if we don't like it.
> 
> On 11/22/19 3:53 PM, Mark Roszko wrote:
> > I'm not sure about adding a second button in the header.
> >
> > I am envisioning creating a "Donate" page with both CERN and Linux
> > foundation options presented clearly with one big button for each
> and a
> > small blurb for what each does. The header will go to this
> intermediate
> > page.
> >
> > On Fri, Nov 22, 2019 at 2:50 PM Wayne Stambaugh
> mailto:stambau...@gmail.com>
> > >> wrote:
> >
> >
> >
> >     On 11/22/19 2:39 PM, Mark Roszko wrote:
> >     >> I need to add a "Donate via Linux Foundation" button to the
> KiCad
> >     > website main page. 
> >     >
> >     > But is it in addition to or to replace CERN?
> >
> >     In addition to.
> >
> >     >
> >     >
> >     >
> >     > On Fri, Nov 22, 2019 at 12:03 PM Wayne Stambaugh
> >     mailto:stambau...@gmail.com>
> >
> >     > 
>  >     >
> >     >     I just pushed a blog post to the KiCad website that
> KiCad has
> >     joined the
> >     >     Linux Foundation so consider this the official
> announcement.  The
> >     >     project did this to give donors a choice of how they want to
> >     donate to
> >     >     KiCad and it gives us some more flexibility on how we can
> >     spend donation
> >     >     money.  This does not in any way change our relationship
> with
> >     CERN and
> >     >     you can continue to donate via CERN if that is your
> >     preference.  You
> >     >     should be seeing announcements from the Linux Foundation
> shortly.
> >     >
> >     >     I need to add a "Donate via Linux Foundation" button to
> the KiCad
> >     >     website main page.  If someone would please point me to the
> >     correct
> >     >     place in the website source where I need to do this, I would
> >     appreciate
> >     >     it.  If you would rather do it yourself, the KiCad LF
> donation
> >     link is
> >     >     https://funding.communitybridge.org/projects/kicad.
> >     >
> >     >     Who has the account login information for the KiCad Facebook
> >     page?  I
> >     >     didn't create this so it would be nice if I had edit
> access so
> >     I could
> >     >     post announcements there instead of asking someone else
> to do it.
> >     >
> >     >     I hope joining the Linux Foundation will improve our
> potential
> >     donor
> >     >     visibility so we can continue to grow the KiCad project. 
> >     Thank you all
> >     >     for your continued support.
> >     >
> >     >     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
> >     >
> >     >
> >     >
> >     > --
> >     > Mark
> >
> >
> >
> > --
> > Mark
> 
> ___
> Mailing list: https://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   : 

Re: [Kicad-developers] Back annotate references from PCB

[Brian Piccioni]

Indeed. I’ve had geographical annotation in c++ working for some time now. Having different commands in PCBNew and eeSchema could lead to all sorts of nightmares. During testing I found myself with “half done” projects where I had inadvertently got the annotation on the PCB and schematics out of synch. This is a complete nightmare to fix even on a small board. In fact the reason I started the work was because geographic annotation is a huge amount of work manually and back annotation is not just a lot of work but really easy to screw up. By having a single integrated tool analogous to “Update PCB From Schematic” can ensure coherency. From: Alexander ShuklinSent: November 23, 2019 5:44 AMTo: Dino GhilardiCc: kicad-developersSubject: Re: [Kicad-developers] Back annotate references from PCB Well,I cannot make back annotation in python, it has to be c++. Actuallythat's why I jumped on that problem. Because once it's done you canuse python for geometrical annotation. Actually I've seen pythonscript to do that, but it parses sch file like plain text, which isbad.Python scripts can do powerful job, and as I see, some very uncommonstuff better to have as python plugins, and something general instandard GUI. I would say that geometrical annotation is more or lesscommon stuff, and I would like to see it integrated in KiCad itself.But I'm not the person who supposed to decide that. Anyway, Brianalready busy with doing that in C++, so I believe that's alright.If there will be some dialog with just common geometrical annotation,you still can use python scripts to do some specific one. On Sat, 23 Nov 2019 at 13:30, Dino Ghilardi  wrote:> > On 23/11/19 10:05, Alexander Shuklin wrote:> > Hi Dino,> > I would say "back annotation" and "geographical annotation" are just> > different things. We with Brian plan to implement both of them.> > Basically when you want to get references from board and apply them to> > corresponding schematic, that back annotation. If you re-annotate> > footprints in PCB according it's position that's geographical> > annotation. I think we will do geographical annotation, which will> > call back annotation straight away.> > Sometimes there's a reason to have back-annotation without> > geographical annotation: once I was asked by our designer "to rename> > that, that and that one connector", for it would correspond his wires> > numbers and documentation. Of course you can still do it manually, but> > if back annotation will be implemented, why not to let user call it> > alone?> >> > Good point. Having two tools at the price of one would be better than> have one tool only (and having back annotation function exported to> python would open the door to user's personal custom back-annotate scripts).> By the way: How about implementing back annotation in kicad itself and> the "geographical annotation" as a python action-plugin (that calls back> annotation on all selected components)? That would enable users to> create their custom back-annotation scripts with different> "unconventional geometries" easily, just modifying the original script> source.> Drawback: I don't know which of the two  methods ("all in c++" or "core> functions in c++ and higher level as a script") will be easier to> implement/debug.> > Cheers,> Dino.> > > > > > >  ___Mailing list: https://launchpad.net/~kicad-developersPost to : kicad-developers@lists.launchpad.netUnsubscribe : https://launchpad.net/~kicad-developersMore 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] Building Kicad on Windows 10/Eclipse/Msys2

[Brian Piccioni]

Eeli and Carsten Thanks for the additional info.  The reason I was working of the git information was in response to Simon earlier in this thread who suggested it. If git was the way to go I wanted to include it because people like me find that there is typically plenty of instructions regarding the use of developmentTools on things like Linux but very little on Windows/msys. Moreover, accomplished developers know this stuff implicitly whereas the rest of us do not. Same goes for things like cmake, etc.. Brian From: Eeli KaikkonenSent: November 23, 2019 4:35 AMTo: Carsten SchoenertCc: KiCad DevelopersSubject: Re: [Kicad-developers] Building Kicad on Windows 10/Eclipse/Msys2   la 23. marrask. 2019 klo 11.11 Carsten Schoenert (c.schoen...@t-online.de) kirjoitti:Hello Eli,Am 23.11.19 um 10:03 schrieb Eeli Kaikkonen:> BTW, it's unnecessarily verbose to say "git pull origin master". Just> "git pull" is enough when you are in the local master branch.no it's not.Your statement is only true if the user hasn't added one ore moreremotes. If you have only one remote configured git tries to be smartand is substitute the rest for the command by the obviously logical value.So, if you want to be safe than the full command line is correct. Oh yeah. I took a shortcut and thought about my normal situation when I have checked out a branch (master), although I added " when you are in the local master branch". Anyways it's best to give as simple instructions for getting the source code as possible and leave everything else for homework for the user. Eeli (with 2 e's) 

___
Mailing list: https://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] Back annotate references from PCB

[Alexander Shuklin]

Well,
I cannot make back annotation in python, it has to be c++. Actually
that's why I jumped on that problem. Because once it's done you can
use python for geometrical annotation. Actually I've seen python
script to do that, but it parses sch file like plain text, which is
bad.
Python scripts can do powerful job, and as I see, some very uncommon
stuff better to have as python plugins, and something general in
standard GUI. I would say that geometrical annotation is more or less
common stuff, and I would like to see it integrated in KiCad itself.
But I'm not the person who supposed to decide that. Anyway, Brian
already busy with doing that in C++, so I believe that's alright.
If there will be some dialog with just common geometrical annotation,
you still can use python scripts to do some specific one.

On Sat, 23 Nov 2019 at 13:30, Dino Ghilardi  wrote:
>
> On 23/11/19 10:05, Alexander Shuklin wrote:
> > Hi Dino,
> > I would say "back annotation" and "geographical annotation" are just
> > different things. We with Brian plan to implement both of them.
> > Basically when you want to get references from board and apply them to
> > corresponding schematic, that back annotation. If you re-annotate
> > footprints in PCB according it's position that's geographical
> > annotation. I think we will do geographical annotation, which will
> > call back annotation straight away.
> > Sometimes there's a reason to have back-annotation without
> > geographical annotation: once I was asked by our designer "to rename
> > that, that and that one connector", for it would correspond his wires
> > numbers and documentation. Of course you can still do it manually, but
> > if back annotation will be implemented, why not to let user call it
> > alone?
> >
>
> Good point. Having two tools at the price of one would be better than
> have one tool only (and having back annotation function exported to
> python would open the door to user's personal custom back-annotate scripts).
> By the way: How about implementing back annotation in kicad itself and
> the "geographical annotation" as a python action-plugin (that calls back
> annotation on all selected components)? That would enable users to
> create their custom back-annotation scripts with different
> "unconventional geometries" easily, just modifying the original script
> source.
> Drawback: I don't know which of the two  methods ("all in c++" or "core
> functions in c++ and higher level as a script") will be easier to
> implement/debug.
>
> Cheers,
> Dino.
>
>
>
>
>
>
>

___
Mailing list: https://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] Back annotate references from PCB

[Dino Ghilardi]

On 23/11/19 10:05, Alexander Shuklin wrote:

Hi Dino,
I would say "back annotation" and "geographical annotation" are just
different things. We with Brian plan to implement both of them.
Basically when you want to get references from board and apply them to
corresponding schematic, that back annotation. If you re-annotate
footprints in PCB according it's position that's geographical
annotation. I think we will do geographical annotation, which will
call back annotation straight away.
Sometimes there's a reason to have back-annotation without
geographical annotation: once I was asked by our designer "to rename
that, that and that one connector", for it would correspond his wires
numbers and documentation. Of course you can still do it manually, but
if back annotation will be implemented, why not to let user call it
alone?



Good point. Having two tools at the price of one would be better than 
have one tool only (and having back annotation function exported to 
python would open the door to user's personal custom back-annotate scripts).
By the way: How about implementing back annotation in kicad itself and 
the "geographical annotation" as a python action-plugin (that calls back 
annotation on all selected components)? That would enable users to 
create their custom back-annotation scripts with different 
"unconventional geometries" easily, just modifying the original script 
source.
Drawback: I don't know which of the two  methods ("all in c++" or "core 
functions in c++ and higher level as a script") will be easier to 
implement/debug.


Cheers,
Dino.








___
Mailing list: https://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] Building Kicad on Windows 10/Eclipse/Msys2

[Eeli Kaikkonen]

la 23. marrask. 2019 klo 11.11 Carsten Schoenert (c.schoen...@t-online.de)
kirjoitti:

> Hello Eli,
>
> Am 23.11.19 um 10:03 schrieb Eeli Kaikkonen:
> > BTW, it's unnecessarily verbose to say "git pull origin master". Just
> > "git pull" is enough when you are in the local master branch.
>
> no it's not.
> Your statement is only true if the user hasn't added one ore more
> remotes. If you have only one remote configured git tries to be smart
> and is substitute the rest for the command by the obviously logical value.
>
> So, if you want to be safe than the full command line is correct.
>
>
>
Oh yeah. I took a shortcut and thought about my normal situation when I
have checked out a branch (master), although I added " when you are in the
local master branch". Anyways it's best to give as simple instructions for
getting the source code as possible and leave everything else for homework
for the user.

Eeli (with 2 e's)
___
Mailing list: https://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] Building Kicad on Windows 10/Eclipse/Msys2

[Carsten Schoenert]

Hello Eli,

Am 23.11.19 um 10:03 schrieb Eeli Kaikkonen:
> BTW, it's unnecessarily verbose to say "git pull origin master". Just
> "git pull" is enough when you are in the local master branch.

no it's not.
Your statement is only true if the user hasn't added one ore more
remotes. If you have only one remote configured git tries to be smart
and is substitute the rest for the command by the obviously logical value.

So, if you want to be safe than the full command line is correct.

-- 
Regards
Carsten Schoenert

___
Mailing list: https://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] Back annotate references from PCB

[Alexander Shuklin]

Hi Wayne,
thanks, now I think I understood all that cases. I'll go back to code
and will take care of them.

On Fri, 22 Nov 2019 at 20:00, Wayne Stambaugh  wrote:
>
> I would prefer that you did ask questions rather than spending a lot of
> development time on a solution that would not be accepted because it
> breaks things.  This is not a trivial problem although it may appear
> that way.  There are plenty of ways to implement back annotation that
> will break things in unexpected ways.  There are a very few ways to not
> break things.  This is why I'm telling you this.  If you don't care
> about the schematic and the board references being synchronized, then
> back-annotation isn't really necessary.  As soon as you attempt to
> back-annotated the schematic from the board, all of the issues that I
> have previously discussed come in to play and have to be addressed.
>
> On 11/22/19 9:53 AM, Alexander Shuklin wrote:
> > Excuse me for so much questions. There's plenty of ways how it can be
> > done, and I'm quite new, maybe I don't see some simple way.
> > I can back up data from pcbnew which is not up to date to schematics,
> > after that I call update pcb dialog. Somebody will want to update pcb
> > by references and after that I will have pcbnew old data which is not
> > up to date either to schematics or layout anymore. I don't think there
> > will be straight forward solution how to solve it.
> > May I just open update pcb dialog and ask user to care about schematic
> > and layout being up to date?
> >
> > On Fri, 22 Nov 2019 at 17:16, Wayne Stambaugh  wrote:
> >>
> >> There is no need to create your own dialog.  Just call the update board
> >> from schematic function before you back annotate.  You will have to make
> >> a temporary copy of your board reference changes because updating from
> >> the schematic will clobber any reference changes in the board.
> >>
> >> On 11/22/19 9:13 AM, Alexander Shuklin wrote:
> >>> Hi Wayne,
> >>>
> >>> I don't want to start PCB update from eeschema straight away, because
> >>> if you run back-annotation, you already changed some references in
> >>> layout and you gonna lose it. And probably you can get some footprints
> >>> which are not connected to any of components in schematics as there's
> >>> possibility in pcbnew to create them. What I almost done is reporting
> >>> about all errors in dialog (I currently use annotation dialog in
> >>> eeschema, but I can create my own if it necessary), and if there's any
> >>> errors, it will not allow you to back-annotate. It will ask you to fix
> >>> them first.
> >>> But if you want, I can run "update pcb from schematic" dialog.
> >>>
> >>> On Fri, 22 Nov 2019 at 16:30, Wayne Stambaugh  
> >>> wrote:
> 
>  Hi Alexander,
> 
>  You must ensure that all of the reference paths are up to date with the
>  schematic before you attempt to back annotate from the board.  Schematic
>  changes can result in the footprint paths in the board being out of sync
>  so you have to perform and update board from schematic (this code
>  already exists) before you attempt to run the back annotation process
>  from the board editor to ensure all of the paths are up to date.  This
>  will ensure when you back annotate that there is a one to one
>  correlation between board footprint sheet paths and schematic symbol
>  sheet paths.
> 
>  Cheers,
> 
>  Wayne
> 
>  On 11/22/19 1:18 AM, Alexander Shuklin wrote:
> > Hi Wayne,
> > thanks for answer.
> > Hopefully I will show you commit soon, so team could look, check and
> > suggest something about that. I'm aware about differences between
> > PCBnew and eeschema and just now I'm writing algorithm that will check
> > it.
> > Do you mean that some schematic file(.sch) can be used in more than
> > one projects? So, I don't plan to change the unique IDs and those
> > components will still be linked to each other, but if references will
> > be changed it will make a mess in another project.
> > I have 3 ideas how I can deal with that:
> > 1) create a dialog, which will say something like "please make sure,
> > that your schematic files are not shared between different projects"
> > 2) I can go by recently opened projects, parse schematics in each of
> > them and look if any schematic uses sheet, which already in use in
> > current project. I'm now sure, but I would presume, that it will be
> > quite slow.
> > 3) To hold information in what project this particular schematics was
> > used. So that's should be saved in .sch file then. But I don't think
> > that information will be very valuable.
> >
> >
> > On Thu, 21 Nov 2019 at 00:07, Wayne Stambaugh  
> > wrote:
> >>
> >> On 11/7/19 5:06 AM, Alexander Shuklin wrote:
> >>> Hi,
> >>> is it alright to answer anybody in one letter?
> >>> First of all, don't take amiss if I 

Re: [Kicad-developers] Back annotate references from PCB

[Alexander Shuklin]

Hi Dino,
I would say "back annotation" and "geographical annotation" are just
different things. We with Brian plan to implement both of them.
Basically when you want to get references from board and apply them to
corresponding schematic, that back annotation. If you re-annotate
footprints in PCB according it's position that's geographical
annotation. I think we will do geographical annotation, which will
call back annotation straight away.
Sometimes there's a reason to have back-annotation without
geographical annotation: once I was asked by our designer "to rename
that, that and that one connector", for it would correspond his wires
numbers and documentation. Of course you can still do it manually, but
if back annotation will be implemented, why not to let user call it
alone?

On Sat, 23 Nov 2019 at 01:33, Dino Ghilardi  wrote:
>
> On 22/11/19 23:14, Andy Peters wrote:
> >
> >> On Nov 22, 2019, at 2:30 PM, Dino Ghilardi  wrote:
> >>
> >> Just my two cents on this.
> >>
> >> Considering that the actual "manual work-around" to do the "back 
> >> annotation" now can be:
> >>
> >> -Open pcbnew and eeschema at the same time
> >> -Select the component you want to rename on pcbnew
> >> -the right symbol gets highlighted (but not selected) automatically in 
> >> eeschema
> >> -select the highlighted component in eeschema, press "U" shortcut (edit 
> >> reference)
> >> -change the reference in the dialog
> >> -press F8 to update the pcb
> >>
> >> A possible approach is to use this sequence of operations (...future 
> >> python script?).
> >>
> >> Since the mechanism to find the correct symbol on eeschema seems yet 
> >> implemented, probably the only missing parts would be to implement is
> >>
> >> Enable from pcbnew the command "select the highlighted component and/or 
> >> open the "edit reference" dialog.
> >>
> >> Drawbacks:
> >> -Requires eeschema and pcbnew open at the same time (may be this is not a  
> >> a problem since we also have DRC that opens eeschema when run).
> >> -Requires to check that schematic and layout are synchronized before 
> >> starting the back-annotation (probably needed also for all the other 
> >> implementations).
> >> -For bigger schematics the full-update via F8 can become slow, so as a 
> >> future improvement, after a first working implementation could be a way to 
> >> update only the modified field.
> >
> > I have done manual back-annotation because automated back-annotation (what 
> > Brian Piccioni is doing) didn’t exist.
> >
> > I’m in the habit of doing “geographical re-annotation” after a layout has 
> > completed. This is where the layout is scanned and, say, the resistor most 
> > near the upper left is numbered R1, the resistor to its right is then R2, 
> > and so on. This is purely an aid for the human assembler and the human 
> > debugging the design. It’s not really interesting for automated assembly.
> >
> > You can do this manually, on a small design, using the approach you 
> > suggest, but for anything complex (my last board was 165 mm x 125 mm with 
> > about 150 capacitors, a hundred resistors, and a bunch of ICs) it’s 
> > impossible.
> >
> > So it really needs to be automated. The options, as I see them, are few and 
> > simple: origin, direction (increasing in X or increasing in Y) and an 
> > option to not re-annotate a part (maybe don’t change the reference 
> > designators for connectors). The logic of the sorting is straightforward, 
> > but it’s a task best left to the machines.
> >
> > -a
> --
>
>
> I agree,
> my comment was more "low level": to automate the high level
> "origin-direction-etc... the first step would be having the lower part
> "up-and-running", then build the fully automated part on that.
>
> P.S.: I like the term "geographical annotation" more than "back
> annotation" for this feature.
>
> Another possible approach I can think about is adding "board
> geographical (re)annotation in eeschema "annotate schematic" tool: if
> eeschema can "ask" the position to pcbnew it also can re-annotate the
> components according to position.
> Since pcbnew does not move components if only the reference changes in
> eeschema, this could be also a solution.
>
> Drawback: probably this approach is less intuitive to the user that
> expects to be able to change references in pcbnew.
>
> Cheers,
> Dino.
>
>
> ___
> Mailing list: https://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] Building Kicad on Windows 10/Eclipse/Msys2

[Eeli Kaikkonen]

la 23. marrask. 2019 klo 4.05 Brian Piccioni (br...@documenteddesigns.com)
kirjoitti:

> Can Simon or somebody who understands such things verify that the
> following is correct so I can update my recipe?
>
>
>
> Thanks
>
>
>
> ==
>
>
>
> In Mingw64
>
>
>
> git clone https://github.com/KiCad/kicad-source-mirror.git
>
>
>
> This will create a local repository directory called kicad-source-mirror
>
>
>
> At any time you can update the repository by
>
>
>
> cd kicad-source-mirror
>
> git pull origin master
>
>
>
> Note that this will leave files which are in kicad-source-mirror but not
> in the kicad source repository unaffected.
>
> *** However *** they will over write your versions of those files! So if
> you edit cmakelists.txt or any other Kicad source file those edits will be
> lost.
>
>
>
Git pull tries to merge the upstream changes to your files. If there are no
conflicts the upstream changes and your own changes will both be in your
local files.

I don't think it's necessary to teach people how to use git in these
instructions. Just simple "download the source zip package and unzip it or
use git clone so that the sources are in such and such directory, for
example:..." and the simple unzip command line and the simple git clone
command line. You don't give further instructions about using unzip, either.

BTW, it's unnecessarily verbose to say "git pull origin master". Just "git
pull" is enough when you are in the local master branch. It's a shortcut
for "git fetch" + "git merge"; for details see e.g.
https://stackoverflow.com/questions/292357/what-is-the-difference-between-git-pull-and-git-fetch
or a git tutorial. (Now you can see why you shouldn't try to give extra
information about git in these instructions. Those who want to use git can
read a git tutorial.)

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