[Kicad-developers] No hotkey for "Set Bus Entry Shape"

[Andy Peters]

In 5.1.6 schematics on macOS Catalina, which is what I’m using, and this may be 
older …

When you choose “place wire to bus entry” (or the ‘z’ key) or “place bus to bus 
entry” (or ‘/‘), you don’t see the entry until you click the mouse on the 
schematic. And there’s no way to change the angle of the entry at placement 
time. There is no hotkey entry for that option, and the only way I can see to 
change it is to place the entry, get out of the place mode, right-click select 
then entry and then choose “set bus entry shape” from the context menu, and 
them move the entry to where you actually want it.

Yeah, that’s not good.

Am I missing something?

-a


___
Mailing list: https://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 much do we care about small memory leaks?

[Simon Richter]

Hi,

FWIW, I've been running the tests with memory checking enabled on both
Linux and Windows (MSVC), and we have several leaks there already, some
from us, some from wxWidgets, some from Gtk, some from Python, and
apparently some from Boost.Test. I don't exactly trust DrMemory yet, it
seems to sometimes show false positives, but I couldn't yet create
simple test cases that have the same false positives.

Since the test cases are low-level stuff with shallow call stacks, those
should give excellent inroads into getting rid of a lot of memory
checker noise.

I've gotten a bit of pushback from the Gtk people on cleaning up their
singletons, apparently they prefer to suppress valgrind messages after
verifying that a particular object is supposed to leak.

What is a bit annoying is that Jenkins seems to be unable to generate
reports for this. We have summary information for our test cases in XML
form, as well as log files from valgrind and DrMemory for individual
cases, but these aren't yet archived or postprocessed.

For report files (but only if no build is currently running :/)

Linux:
https://jenkins.simonrichter.eu/job/linux-kicad-head/ws/build/Testing/Temporary/
(MemoryChecker.*.log)

Windows:
https://jenkins.simonrichter.eu/job/windows-kicad-msvc-head/build=release,cpu=amd64,label=msvc/ws/build/Testing/Temporary/DrMemory/

Debug builds on Windows often run into timeouts because memory error
report generation takes close to an hour for some tests. :/

   Simon



signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://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] Configure dialog shim in eeschema to be modeless instead of modal.

[Jeff Young]

No.  The dialogs would all have to be beefed up to listen to changes in the 
document and update their values, pointers, etc.

We do have some work in progress for an Inspector, which would be modeless and 
show the selected items’ properties.

Cheers,
Jeff.


> On 29 May 2020, at 19:31, Andrea Martí  wrote:
> 
> Hi,
> Is there any way to configure the file “dialogshim” in eeschema to be 
> modeless instead of modal? 
> Cheers, 
> Andrea
> ___
> Mailing list: https://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] Configure dialog shim in eeschema to be modeless instead of modal.

[Wayne Stambaugh]

Dialog modality has nothing to do with DIALOG_SHIM.  It depends on how
you show the dialog.  See the documentation for wxDialog.

I will warn you up front that modeless dialogs are not trivial to
implement.  I will expect bidirectional data updating between objects in
the main frame window and the dialog using events (take a look and the
find/replace dialog in Eeschema for an example).  Having dialogs
directly access parent window objects and parent windows access dialog
objects directly is not an acceptable solution.

Cheers,

Wayne

On 5/29/20 2:31 PM, Andrea Martí wrote:
> Hi,
> Is there any way to configure the file “dialogshim” in eeschema to be
> modeless instead of modal?
> Cheers,
> Andrea
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

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

[Kicad-developers] Configure dialog shim in eeschema to be modeless instead of modal.

[Andrea Martí]

 Hi,
Is there any way to configure the file “dialogshim” in eeschema to be
modeless instead of modal?
Cheers,
Andrea
___
Mailing list: https://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] Request to merge support of python 3.9

[Steven A. Falco]

On 5/29/20 11:36 AM, Ian McInerney wrote:

Steve,

Thanks for the update to it, and it looks good, so I have set it to merge to 
master when the CI build completes. I will then manually cherry-pick this to 
the 5.1 branch.


Thanks Ian.  I appreciate your help.  I'm glad we don't need two merge requests 
for the two branches.

I do wonder if there is a better way for us to structure this search so that we 
don't have to touch the file every time a new Python version is released.


I wonder that too, but I don't know enough about cmake to judge.

Steve



-Ian

On Fri, May 29, 2020 at 4:22 PM Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:

I pushed a change to my KiCad code repo to add python 3.9 as a supported 
version, because Fedora is actively rebuilding everything for python 3.9.

As this is my first contribution via gitlab, please let me know if I 
created the merge request properly.

In particular, this should go into both master and 5.1 - do I need to make 
a separate merge request for 5.1, or can/will it be cherry-picked by whomever 
does the merge?

         Steve

___
Mailing list: https://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] Request to merge support of python 3.9

[Ian McInerney]

Steve,

Thanks for the update to it, and it looks good, so I have set it to merge
to master when the CI build completes. I will then manually cherry-pick
this to the 5.1 branch.

I do wonder if there is a better way for us to structure this search so
that we don't have to touch the file every time a new Python version is
released.

-Ian

On Fri, May 29, 2020 at 4:22 PM Steven A. Falco 
wrote:

> I pushed a change to my KiCad code repo to add python 3.9 as a supported
> version, because Fedora is actively rebuilding everything for python 3.9.
>
> As this is my first contribution via gitlab, please let me know if I
> created the merge request properly.
>
> In particular, this should go into both master and 5.1 - do I need to make
> a separate merge request for 5.1, or can/will it be cherry-picked by
> whomever does the merge?
>
> Steve
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Request to merge support of python 3.9

[Steven A. Falco]

I pushed a change to my KiCad code repo to add python 3.9 as a supported 
version, because Fedora is actively rebuilding everything for python 3.9.

As this is my first contribution via gitlab, please let me know if I created 
the merge request properly.

In particular, this should go into both master and 5.1 - do I need to make a 
separate merge request for 5.1, or can/will it be cherry-picked by whomever 
does the merge?

Steve

___
Mailing list: https://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] Legacy schematic and symbol library writing deprecated.

[Kevin Cozens]

On 2020-05-29 10:24 a.m., Wayne Stambaugh wrote:

They also have all of the features planned for V6 which haven't been
implemented yet so they are actually ahead of the current file formats.
I don't know how motivated I am to rip out all of the new stuff and then
add it back in later.


Where the doc is ahead of what has been implemented just add a marker of 
some kind to say Future, or NIY (Not Implemented Yet). Add a note/warning at 
the start of the doc stating that areas of the doc so marked may or may not 
get implemented as documented and that the actual implemenation is subject 
to change.


While you are at it, would you please add in a revision date, file version 
number, and some mention of which version of Kicad is covered by the doc? It 
really helps those of us doing work on external projects related to Kicad.


--
Cheers!

Kevin.

http://www.ve3syb.ca/   | "Nerds make the shiny things that
https://www.patreon.com/KevinCozens | distract the mouth-breathers, and
| that's why we're powerful"
Owner of Elecraft K2 #2172  |
#include  | --Chris Hardwick

___
Mailing list: https://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 much do we care about small memory leaks?

[Wayne Stambaugh]

I would prefer a single MR for each leak just in case we need to revert
something that gets broken.  I'm fine with grouping related leaks in a
single MR.  There is no need to file an issue report.

On 5/29/20 10:51 AM, Johannes Pfister wrote:
> At least one leak is not in this issues. I made a MR for the one i
> found https://gitlab.com/kicad/code/kicad/-/merge_requests/231
> Question, when i see multiple ones but have only fixed one of them,
> while the others will take a few days, should i make a MR for each one
> of them or is it better to have a single MR for all of them?
> And should I also create an issue or only a MR?
> 
> I found them with valgrind.
> 
> Am Fr., 29. Mai 2020 um 14:43 Uhr schrieb Ian McInerney
> :
>>
>> There are quite a few leaks in the code at present, and every now and then I 
>> go through and try to plug some of them (but I don't find all of them, that 
>> is for sure). My suggestion is that you can either propose a patch in a 
>> merge request if you think you know where the memory should be freed and who 
>> owns it, or file some issues with the details of the memory leaks if you 
>> aren't sure about the memory management. I usually find these when I run 
>> under ASAN, and there are several open already (and some more I am needing 
>> to open issues for):
>>
>> https://gitlab.com/kicad/code/kicad/-/issues/4070
>> https://gitlab.com/kicad/code/kicad/-/issues/3882
>>
>> -Ian
>>
>>
>> On Fri, May 29, 2020 at 3:23 PM Johannes Pfister 
>>  wrote:
>>>
>>> As an example, if opening and closing the plot window would leak 3 kB
>>> each time, would we care about that? And is it justified to increase
>>> code complexity to avoid this leak?
>>> If yes, what about "leaks" that alloc memory only once, use the same
>>> memory till the application is closed and don't free it. Should we
>>> increase code complexity to avoid this "leaks" too?
>>>
>>> The reason for this question: There are some of this kind of leaks in the 
>>> code.
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 

___
Mailing list: https://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 much do we care about small memory leaks?

[Johannes Pfister]

> If the memory is allocated at startup and doesn't grow in size, I
> wouldn't be too worried about not freeing it at shutdown.

But removing them can help remove real leaks since the output of
valgrind / ASan will be shorter and therefore clearer.

Am Fr., 29. Mai 2020 um 14:33 Uhr schrieb Andrew Zonenberg
:
>
> If the memory is allocated at startup and doesn't grow in size, I
> wouldn't be too worried about not freeing it at shutdown.
>
> True leaks (growing in size over time) are a major problem. I routinely
> leave kicad instances open for weeks or months while working on large
> projects.
>
> On 5/29/20 7:22 AM, Johannes Pfister wrote:
> > As an example, if opening and closing the plot window would leak 3 kB
> > each time, would we care about that? And is it justified to increase
> > code complexity to avoid this leak?
> > If yes, what about "leaks" that alloc memory only once, use the same
> > memory till the application is closed and don't free it. Should we
> > increase code complexity to avoid this "leaks" too?
> >
> > The reason for this question: There are some of this kind of leaks in the 
> > code.
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >



-- 
Johannes Pfister
Electronic Engineering
johannes.pfis...@josttech.ch
+41 55 460 22 25

josTTech GmbH
Haemmerli 6
8855 Wangen - Switzerland
+41 55 460 22 25
www.josTTech.ch - i...@josttech.ch
Vending - Engineering - Trading

___
Mailing list: https://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 much do we care about small memory leaks?

[Johannes Pfister]

At least one leak is not in this issues. I made a MR for the one i
found https://gitlab.com/kicad/code/kicad/-/merge_requests/231
Question, when i see multiple ones but have only fixed one of them,
while the others will take a few days, should i make a MR for each one
of them or is it better to have a single MR for all of them?
And should I also create an issue or only a MR?

I found them with valgrind.

Am Fr., 29. Mai 2020 um 14:43 Uhr schrieb Ian McInerney
:
>
> There are quite a few leaks in the code at present, and every now and then I 
> go through and try to plug some of them (but I don't find all of them, that 
> is for sure). My suggestion is that you can either propose a patch in a merge 
> request if you think you know where the memory should be freed and who owns 
> it, or file some issues with the details of the memory leaks if you aren't 
> sure about the memory management. I usually find these when I run under ASAN, 
> and there are several open already (and some more I am needing to open issues 
> for):
>
> https://gitlab.com/kicad/code/kicad/-/issues/4070
> https://gitlab.com/kicad/code/kicad/-/issues/3882
>
> -Ian
>
>
> On Fri, May 29, 2020 at 3:23 PM Johannes Pfister 
>  wrote:
>>
>> As an example, if opening and closing the plot window would leak 3 kB
>> each time, would we care about that? And is it justified to increase
>> code complexity to avoid this leak?
>> If yes, what about "leaks" that alloc memory only once, use the same
>> memory till the application is closed and don't free it. Should we
>> increase code complexity to avoid this "leaks" too?
>>
>> The reason for this question: There are some of this kind of leaks in the 
>> code.
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp



-- 
Johannes Pfister
Electronic Engineering
johannes.pfis...@josttech.ch
+41 55 460 22 25

josTTech GmbH
Haemmerli 6
8855 Wangen - Switzerland
+41 55 460 22 25
www.josTTech.ch - i...@josttech.ch
Vending - Engineering - Trading

___
Mailing list: https://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 much do we care about small memory leaks?

[Ian McInerney]

There are quite a few leaks in the code at present, and every now and then
I go through and try to plug some of them (but I don't find all of them,
that is for sure). My suggestion is that you can either propose a patch in
a merge request if you think you know where the memory should be freed and
who owns it, or file some issues with the details of the memory leaks if
you aren't sure about the memory management. I usually find these when I
run under ASAN, and there are several open already (and some more I am
needing to open issues for):

https://gitlab.com/kicad/code/kicad/-/issues/4070
https://gitlab.com/kicad/code/kicad/-/issues/3882

-Ian


On Fri, May 29, 2020 at 3:23 PM Johannes Pfister <
johannes.pfis...@josttech.ch> wrote:

> As an example, if opening and closing the plot window would leak 3 kB
> each time, would we care about that? And is it justified to increase
> code complexity to avoid this leak?
> If yes, what about "leaks" that alloc memory only once, use the same
> memory till the application is closed and don't free it. Should we
> increase code complexity to avoid this "leaks" too?
>
> The reason for this question: There are some of this kind of leaks in the
> code.
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://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 much do we care about small memory leaks?

[Andrew Zonenberg]

If the memory is allocated at startup and doesn't grow in size, I
wouldn't be too worried about not freeing it at shutdown.

True leaks (growing in size over time) are a major problem. I routinely
leave kicad instances open for weeks or months while working on large
projects.

On 5/29/20 7:22 AM, Johannes Pfister wrote:
> As an example, if opening and closing the plot window would leak 3 kB
> each time, would we care about that? And is it justified to increase
> code complexity to avoid this leak?
> If yes, what about "leaks" that alloc memory only once, use the same
> memory till the application is closed and don't free it. Should we
> increase code complexity to avoid this "leaks" too?
> 
> The reason for this question: There are some of this kind of leaks in the 
> code.
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://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 much do we care about small memory leaks?

[Wayne Stambaugh]

We should not be leaking memory in either case and we should care about it.

Which plot window are you are you talking about?

On 5/29/20 10:22 AM, Johannes Pfister wrote:
> As an example, if opening and closing the plot window would leak 3 kB
> each time, would we care about that? And is it justified to increase
> code complexity to avoid this leak?
> If yes, what about "leaks" that alloc memory only once, use the same
> memory till the application is closed and don't free it. Should we
> increase code complexity to avoid this "leaks" too?
> 
> The reason for this question: There are some of this kind of leaks in the 
> code.
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://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] Legacy schematic and symbol library writing deprecated.

[Wayne Stambaugh]

This will happen at some point but I still haven't decided where I want
to put the file format documentation.  The current documents are in
google docs so they have to be converted to markdown or asciidoc
depending on where they get saved.  They also have all of the features
planned for V6 which haven't been implemented yet so they are actually
ahead of the current file formats.  I don't know how motivated I am to
rip out all of the new stuff and then add it back in later.

On 5/29/20 9:45 AM, Mark Roszko wrote:
> Might I suggest the file format being documented into the repo first?
> That way any new additions to the format should involve adding to said
> documentation.
> 
> On Fri, May 29, 2020 at 9:12 AM Wayne Stambaugh  > wrote:
> 
> As soon as the rebase and CI pipeline completes, the merge request to
> disable writing legacy schematic and symbol library file formats[1] will
> get merged into master.  For those of you still using master to maintain
> legacy symbol libraries, you will have to keep an older version of
> master or 5.1 installed on your system.
> 
> This also means that the new file formats are open for new features once
> the merge takes place.  I have a merge request queued for edting wire
> and bus properties (color, thickness, and style), which will happen as
> soon as this is merged.  When working on new schematic and symbol
> library features that will create a file format version change, please
> coordinate with other developers to prevent file format version clashes.
>  I have several changes that I will be working on in the next few months
> including support for excluding symbols from bill of materials and from
> boards.
> 
> Cheers,
> 
> Wayne
> 
> [1]: https://gitlab.com/kicad/code/kicad/-/merge_requests/217
> 
> ___
> Mailing list: https://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

___
Mailing list: https://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] How much do we care about small memory leaks?

[Johannes Pfister]

As an example, if opening and closing the plot window would leak 3 kB
each time, would we care about that? And is it justified to increase
code complexity to avoid this leak?
If yes, what about "leaks" that alloc memory only once, use the same
memory till the application is closed and don't free it. Should we
increase code complexity to avoid this "leaks" too?

The reason for this question: There are some of this kind of leaks in the code.

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

Re: [Kicad-developers] Legacy schematic and symbol library writing deprecated.

[Mark Roszko]

Might I suggest the file format being documented into the repo first?
That way any new additions to the format should involve adding to said
documentation.

On Fri, May 29, 2020 at 9:12 AM Wayne Stambaugh 
wrote:

> As soon as the rebase and CI pipeline completes, the merge request to
> disable writing legacy schematic and symbol library file formats[1] will
> get merged into master.  For those of you still using master to maintain
> legacy symbol libraries, you will have to keep an older version of
> master or 5.1 installed on your system.
>
> This also means that the new file formats are open for new features once
> the merge takes place.  I have a merge request queued for edting wire
> and bus properties (color, thickness, and style), which will happen as
> soon as this is merged.  When working on new schematic and symbol
> library features that will create a file format version change, please
> coordinate with other developers to prevent file format version clashes.
>  I have several changes that I will be working on in the next few months
> including support for excluding symbols from bill of materials and from
> boards.
>
> Cheers,
>
> Wayne
>
> [1]: https://gitlab.com/kicad/code/kicad/-/merge_requests/217
>
> ___
> Mailing list: https://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
___
Mailing list: https://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] Legacy schematic and symbol library writing deprecated.

[Wayne Stambaugh]

As soon as the rebase and CI pipeline completes, the merge request to
disable writing legacy schematic and symbol library file formats[1] will
get merged into master.  For those of you still using master to maintain
legacy symbol libraries, you will have to keep an older version of
master or 5.1 installed on your system.

This also means that the new file formats are open for new features once
the merge takes place.  I have a merge request queued for edting wire
and bus properties (color, thickness, and style), which will happen as
soon as this is merged.  When working on new schematic and symbol
library features that will create a file format version change, please
coordinate with other developers to prevent file format version clashes.
 I have several changes that I will be working on in the next few months
including support for excluding symbols from bill of materials and from
boards.

Cheers,

Wayne

[1]: https://gitlab.com/kicad/code/kicad/-/merge_requests/217

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