Re: [Kicad-developers] Icon for 3D Mouse center of rotation

[Jon Evans]

Hi Markus,

Adding a new icon is certainly possible.  There are some guidelines here:
https://dev-docs.kicad.org/en/rules-guidelines/icon-design/

In particular, the icon must be added with an appropriate SVG source file
authored in Inkscape and with the appropriate (CC-BY-SA) license attribute
embedded in the file.
You can inspect any of the current icon source files to see what this looks
like.

Best,
Jon

On Wed, Apr 6, 2022 at 8:13 AM Markus Bonk 
wrote:

> Hi Bevan,
>
>
>
> Thanks, that was helpful: the 3DPivot.png is off the table. The request
> has been modified to use a small sphere (a neutral shape), probably the
> same blue color.
>
>
>
> Regards
>
> Markus
>
>
>
> *From:* bevan.we...@gmail.com 
> *Sent:* Wednesday, April 6, 2022 10:32 AM
> *To:* Markus Bonk 
> *Cc:* kicad-developers@lists.launchpad.net
> *Subject:* RE: [Kicad-developers] Icon for 3D Mouse center of rotation
>
>
>
> Hi Mark,
>
>
>
> That image appears to be a version of the 3d Connexion corporate logo
> (which I expect you would anticipate on being a Trademark item).
>
> As such I don’t think it would be appropriate to have it within an
> open-source software package, it would be troublesome to get it across the
> line on licencing, and how that licencing would be inclusive to other
> contributors.
>
> i.e. would you accept someone to modify the logo to include a funny face,
> or a emoticon poo symbol or similar?  If it were my logo I would not want
> that, and hence would not want it to be licenced under an open source
> licence… I would want it to remain as a defensible trademark under an ‘all
> rights reserved’ licence.
>
>
>
> Perhaps Wayne or the other Kicad members might have a different opinion on
> this (or legal advice contradicting my statements), but I think it would be
> something that 3d Connexion would likely want to have their legal team
> consider also.
>
>
>
>
>
> Regards,
>
> Bevan Weiss
>
>
>
> *From:* Kicad-developers <
> kicad-developers-bounces+bevan.weiss=gmail@lists.launchpad.net> *On
> Behalf Of *Markus Bonk
> *Sent:* Wednesday, 6 April 2022 4:54 PM
> *To:* Wayne Stambaugh 
> *Cc:* kicad-developers@lists.launchpad.net
> *Subject:* [Kicad-developers] Icon for 3D Mouse center of rotation
>
>
>
> Hi,
>
>
>
> I have a request to change the icon used to represent the center of
> rotation when using a 3D Mouse to 3DPivot.png (see attachment). Before I
> investigate what needs doing to implement this while keeping the current
> solution for the 2D Mouse, I wanted to query you if such a merge request
> could be accepted.
>
>
>
> Markus
> --
>
> *Markus Bonk*
> Senior Software Engineer
>
> Clarita-Bernhard-Str. 18
> 81249 München
> Germany
>
> markus_b...@3dconnexion.com
>
> www.3dconnexion.com
>
> Geschäftsführer: Antonio Pascucci
> Sitz der Gesellschaft: München
> Registergericht: München HRB 99232
>
> This email and any files transmitted with are from 3Dconnexion GmbH. The
> contents of this email and any attachments are confidential to the intended
> recipient. They may not be disclosed to or used by or copied in any way by
> anyone other than the intended recipient. If this email is received in
> error, please contact 3Dconnexion GmbH by calling +49 89 8974542-0 and then
> delete it. Please note that neither 3Dconnexion GmbH nor the sender accepts
> any responsibility for viruses and it is your responsibility to scan or
> otherwise check this email and any attachments. Any opinion expressed in
> this email are those of the individual and not necessarily those of
> 3Dconnexion GmbH.
> 3Dconnexion GmbH processes and stores for commercial purposes your
> personal data, collected upon your consent, in accordance with its privacy
> policy available at https://www.3dconnexion.eu/privacy.html, which has
> been drafted in accordance with Regulation (EU) no. 679/2016 and all
> applicable local data protection laws and regulations of the countries
> where the company operates. To revoke your consent or exercise all your
> rights with regards to personal data, please contact us at
> priv...@3dconnexion.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
>
___
Mailing list: https://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] Introduction of sentry application monitoring and error tracking

[Jon Evans]

Thanks for putting in the work to get this integrated, Mark!  Having
automated crash dumps will be invaluable to improving KiCad stability.

On Wed, Mar 30, 2022 at 8:32 PM Mark Roszko  wrote:
>
> Hey folks,
>
> We are planning to introduce the use of the Sentry platform into KiCad.
> Sentry https://sentry.io/ is open source platform to capture application 
> events, crash dumps, and other random analytics.
> Both their hosted platform (https://github.com/getsentry/sentry) is open 
> source and the integrated SDK to handle crash handling in C++ is also open 
> source on github under MIT license 
> (https://github.com/getsentry/sentry-native)
> Sentry has given KiCad a sponsored account to use their SaaS platform as the 
> KiCad team does not have the manpower to maintain a self-hosted instance.
>
> The plan going forward is:
> - The primary use in KiCad will be to capture crash reports, but in the 
> future it could also let us gather things like performance metrics of 
> algorithms across the wider user base.
> - The implementation will be and will remain entirely opt-in with a one time 
> prompt on startup, and the ability to turn it off in preferences. This is to 
> maintain privacy regulation compliance and just good manners.
> - No PII is captured, we have no need or desire for it. Only a random GUID 
> generated for your install is used to connect crash reports. This GUID can be 
> reset at any time by the user.
> - To aid in avoiding PII capture, all sentry reports go to a "sentry-relay" 
> server run on KiCad owned infrastructure,
> this relay serves as a proxy to communicate to the main sentry.io platform, 
> this aids in hiding originating IP addresses but we have also turned off the 
> storage of IP addresses in sentry
> - Additionally, the cmake variable KICAD_USE_SENTRY is being added where a 
> value of false will disable the inclusion of the sentry sdk entirely. The 
> current default will be off as only Windows support is tested.
> - Sentry will only store at most 1 raw crash dump (though we can turn it off 
> entirely) for analysis. Sentry will parse out only the relevant crash details 
> such as call stack, and stack frame and discard the rest of the crash dump.
> - This will be deployed for Windows nightly builds first
> - Data in sentry is retained for at max 90 days before it is deleted 
> automatically.
>
>
> This solves a many years long desire of the KiCad team to capture crash dumps 
> without user involvement and sentry offers us a very easy solution to do it 
> and help make KiCad better for everyone.
>
> --
> 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   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] 6.0.2 tagged.

[Jon Evans]

@seth - I think the docs need to be re-packed in the manner Christoph says,
IIRC that is a requirement for the Mac packaging.

On Fri, Feb 11, 2022 at 10:09 AM Christoph Moench-Tegeder <
c...@burggraben.net> wrote:

> Hi,
>
> ## Wayne Stambaugh (stambau...@gmail.com):
>
> > All of the repos have been tagged for 6.0.2 and the documentation
> > archive can be download from
> > https://kicad-downloads.s3.cern.ch/docs/kicad-doc-6.0.2.tar.gz.
>
> That docs archive... Previously (until and including 6.0.1), that
> archive had been breated with kicad-doc-$version as the top level
> directory, but with 6.0.2 the top level directory is "share".
> In practical terms:
>
> cmt@elch:Sources$ tar tzf kicad-doc-6.0.1.tar.gz | sort | head -5
> kicad-doc-6.0.1/share/
> kicad-doc-6.0.1/share/doc/
> kicad-doc-6.0.1/share/doc/kicad/
> kicad-doc-6.0.1/share/doc/kicad/help/
> kicad-doc-6.0.1/share/doc/kicad/help/ca/
>
> cmt@elch:Sources$ tar tzf kicad-doc-6.0.2.tar.gz | sort | head -5
> share/
> share/doc/
> share/doc/kicad/
> share/doc/kicad/help/
> share/doc/kicad/help/ca/
>
> Is that meant to stay this way in 6.0.2? It's easy to handle in packaging
> either way round, but if you plan to reroll the tarball, I'll wait for
> the new package (and the new checksums) before pushing.
>
> Regards,
> Christoph
>
> --
> Spare Space
>
> ___
> Mailing list: https://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 documentation

[Jon Evans]

> THE MAIN PROBLEM ARE THE OUTDATED DOCUMENTS!
> NOT THE WAY THEY ARE DISTRIBUTED.

One reason the documents are outdated is that they are hard to contribute
to.
They are hard to contribute to in part because they use a toolchain that
only works well on Linux, and many of our users who might feel like
contributing use Windows or Mac.
Simplifying the toolchain would enable easy contribution from any platform.

Also, as I mentioned before, the docs and the source code will generally
never be in sync, and there is not much point in trying to make them be in
sync.  This would just needlessly delay releases.  It is better to have a
"rolling" 6.x documentation separate from the 6.0.x bugfix releases of code
(but see below, I don't mind that some distributions "require" a matching
6.0.x release of the docs).

Separately, gettext/po4a is not the best tool for managing translation of
long-form documentation.  Yes, we have a "working" system, but it doesn't
work very well.  Documentation should be translated in large chunks, for
example by reading an entire paragraph or section and then translating it
into the target language with an understanding of the full context.  Doing
it in small chunks as is done today will not result in great translations
as the source (English) documents are updated and rewritten.

I don't have a specific proposal for a different system yet (this problem
is well-solved in the commercial world using commercial tooling, but I'm
not sure the best path for open-source and free tooling), but I do maintain
that we should be looking at improving this system.

> Do not try to "solve" things were distributions already have a process
> for and established rules for that.

If the distributions "need" 6.0.1 tagged documentation because of their
rules, that is fine.  There is no reason to stop providing that.  It is
just obviously not the best way to provide the documentation to users who
have Internet access, so I am talking about ideas to provide more updated
documentation to users that can make use of it.

-Jon

On Thu, Jan 20, 2022 at 10:59 AM Carsten Schoenert 
wrote:

> Hi,
>
> Am 19.01.22 um 23:18 schrieb Eeli Kaikkonen:
>
> > I don't understand why this discussion is so difficult to understand.
>
> sorry but I don't understand what problem you are trying to solve!
> There is no problem within the Linux world and their distros to provide
> packaged documentation, there is no need to develop another new way for
> distributing documentation.
>
> > I agree with Jon and don't see any problem for distros. As far as I
> > can see the point is that the documentation package version shouldn't
> > be logically dependent on the KiCad packages or vice versa. You can
> > have package kicad-v6.0-documentation version, say, 20222001 [date],
> > can't you? You don't have to give it the version number 6.0.x. If a
> > git tag is needed for technical reasons, let's have automatic tagging
> > which adds a tag each day.
>
> To use the words from Marco...
>
> "Are you serious?"
>
> I'm getting a bit disappointed because I become the feeling that you are
> somehow ignorant about the arguments of at least two main packagers of
> KiCad within Linux. And I really think that you want to solve problems
> on the wrong corner.
>
> THE MAIN PROBLEM ARE THE OUTDATED DOCUMENTS!
> NOT THE WAY THEY ARE DISTRIBUTED.
>
> So it's better to think about how the documentation can be updated and
> how a ongoing process can be introduced to make contributions easier
> with a low barrier for one time contributors.
>
> And as Marco did explain, we need to fix the tools if there is something
> missed at the end. Be friendly to the distributions, please do not try
> to ignore them. They are part of the FOSS ecosystem KiCad is depending on.
> Do not try to "solve" things were distributions already have a process
> for and established rules for that.
>
> I stop now reading any new post on this topic.
>
> --
> Regards
> Carsten
>
> ___
> Mailing list: https://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 documentation

[Jon Evans]

> Here's a wild idea: why not make the documentation bundle(s) downloadable
with the PCM?

I'm not sure that would be worth the extra effort, since it wouldn't help
the people that can't use online documentation because Internet access is
restricted.

Yes, you could download a PCM package and then install it via a USB stick
or whatever (but probably not in a secure environment), but you could also
download the docs website.

-Jon

On Wed, Jan 19, 2022 at 5:03 PM Eeli Kaikkonen 
wrote:

> On Wed, Jan 19, 2022 at 6:38 PM Jon Evans  wrote:
> >
> > What I would propose to improve the situation is:
>
> Here's a wild idea: why not make the documentation bundle(s)
> downloadable with the PCM?
>
> 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 documentation

[Jon Evans]

On Wed, Jan 19, 2022 at 2:12 PM Steven A. Falco 
wrote:

>
> Not to put words in your mouth, but it sounds like the code will be
> changed so that when someone clicks on the Help menu, they will get the
> on-line version, if possible.
> And only if the on-line version cannot be accessed, the code would then
> automatically fall back to the off-line (local) version.  Do I have the
> proposal correct?  If so, I like it.
>

Yes, something like that.  But, instead it could be to use the offline
version if present, and fall back to the online version if absent.  Then it
would be up to the packager to decide whether or not to include the offline
docs (I'd propose to drop them from the Windows and Mac packages that we
provide).


> It might also be good to have a warning somewhere, perhaps in the off-line
> version itself, that it is not necessarily current, along with a suggestion
> to go retrieve the on-line version manually.
>

Yes, I think this is important, just have to figure out how to add it to
the generated documentation but not the website.


>
> It would still be helpful if the doc repo could be tagged at the same
> point that everything else is tagged, because every single Fedora package
> needs a correct version in its name.  For example, it would be very strange
> (perhaps "illegal") to package something called the 6.0.1 doc that came
> from some random SHA in an untagged tree.
>

I am not trying to break any distro's packaging requirements for the sake
of making people's lives hard, I am just trying to make it so the average
KiCad user who has access to the online docs finds them first.

Maybe one option would be to not install the documentation package by
default when the user selects the main kicad package.  That way, a user who
just installs kicad will get the online docs redirect, and one who cares
about offline docs can manually install the extra package?
___
Mailing list: https://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 documentation

[Jon Evans]

On Wed, Jan 19, 2022 at 1:05 PM Carsten Schoenert 
wrote:

> [ I'm on this list, no need to address me dedicated. ]
>

My email client does this automatically, but if it bothers you I removed it
manually :)

>
> Am 19.01.22 um 18:45 schrieb Jon Evans:
>
> > I think you misunderstand.  We currently have three rolling releases on
> > docs.kicad.org <http://docs.kicad.org>: V5, V6, and master (nightly).
> > We will continue adding new "rolling release" builds for every major
> > release version.
>
> I think I have understand you. :)
>
> But for me "rolling release" and "stable release" isn't something that
> is working well together as it simply doesn't fit together per definition.
>

It does if you consider that the way KiCad is developed, we have no
requirement (and in practice, a guarantee against) the documentation being
up-to-date to a certain code tag at the time the code tag is made.

The way the project currently works, the docs will generally *never* be
complete for a given tag at the time that tag is made.
Maybe this can be different in the future if we get way more volunteers to
write documentation.


>
> [cut off]
> I stand on my opinion, I'm not convinced that most of the things you
> suggested is the way to go.
>
> > The price is that the average Linux user will get 6.0.1 tagged docs
> > instead of latest V6 docs (and so forth) and won't necessarily think to
> > check for updated ones.
>
> That's the idea behind packages that using a tagged version. I haven't
> seen any professional software is doing that you suggest.
> And the typical experienced Linux user isn't behaving like Windows user.
>

On the other hand, I have seen a lot of professional software going to
online-only documentation.

I think the "typical" Linux user wants up-to-date documentation and has
Internet access.  The kind who does not have Internet access, or cares a
lot about how the documentation is packaged, is not the "mass market" Linux
user.  KiCad is not some software targeted at some narrow segment of Linux
users: probably most of our users are on Windows.


>
> > You are confusing rolling release of binary packages/applications with
> > rolling release of documentation -- they are entirely different in my
> mind.
>
> No, I don't.
> Doing constantly bug fixing for current stable releases of KiCad doesn't
> exclude doing the same for improving the (stable) documentation
> independently from the current development branch.
>

We agree on this!  But, the documentation and the code are decoupled as I
said above, so the time at which code 6.0.2 is tagged might not be the same
time as we want to update the 6.x documentation.


>
> I'm not a native English speaker and I'm not really able to help on this
> part effectively, and also I have given up long time ago trying
> contributing to the KiCad documentation for various reasons.
>
> The main devs are free to do and decide whatever they think is the right
> thing and way for KiCad. I simple don't see why it would be really
> helpful for the users what you are proposing. In my eyes is dropping
> existing formats a loss of well working and usable support.
>

I believe part of the reason we have trouble getting people to help write
the documentation is because the build process is tricky (it is only easy
on Linux; I've spent some time trying to make it run on Windows and Mac but
given up as a waste of time).  We have a lot of active and engaged users on
Windows and Mac who basically cannot contribute to the documentation
because they can't easily build and test it locally.

One thing we could do that would help this is to change the build process
so that the main build is only HTML, and PDF build is an optional extra
generated from the HTML (that can be enabled by a CI job for packaging).
Another thing would be to change the translation system from the existing
gettext/po system (which is not very well suited to long-form text) to a
manual translation system.

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

Re: [Kicad-developers] V6 documentation

[Jon Evans]

On Wed, Jan 19, 2022 at 12:37 PM Carsten Schoenert 
wrote:

> Hello Jon,
>
> Am 19.01.22 um 17:38 schrieb Jon Evans:
> > Carsten,
> >
> > There is no reason to remove the ability to package docs offline, I just
> > don't think it should be a focus of the project.
>
> here start to disagree.
> In my eyes the offline bundled and created documentation IS a strong
> service the project should always have a focus on.
>
> > The majority of users will be served better by keeping a "rolling
> > release" online at docs.kicad.org <http://docs.kicad.org> (with a
> > download button, ideally).
>
> I disagree again, I know several users of KiCad which don't follow a
> rolling release of KiCad valid reasons and even don't update to a new
> main version because the current one ore more big projects is critical.
> Professional users typically don't have the time to follow rolling
> releases as this is lost and unpaid time for them. It's easier to live
> with the know problems and to work around them. And once a new version
> is out and the time has come projects can do and will do the version
> update.
>
> A rolling release only of the online documentation is also counter
> productive in such a case, as it would be probably mostly wrong for the
> old used version potentially.
>

I think you misunderstand.  We currently have three rolling releases on
docs.kicad.org: V5, V6, and master (nightly).
We will continue adding new "rolling release" builds for every major
release version.

So, the V6 documentation is rolling-released to the web, but the nightly is
also (and is separate).

This means that we will continue improving the V6 documentation over the
coming year, and *also* can start documenting the V7 features without any
conflict.

The point I was making is that someone who installs 6.0.1 today should get
the latest V6 branch docs (not the latest master branch) ideally.
Anyone with internet access should be able to get the latest docs, not the
docs at the 6.0.1 tag.


>
> >  > It absolutely doesn't hurt to build completely offline usable
> > documentation.
> >
> > It does hurt the way we do it today, for the following reasons:
> >
> > 1) We currently support multiple formats, which makes the build system
> > and formatting changes complicated
>
> So what?
> Isn't it exact the purpose of the build system to solve all these
> problems for the users?
>

No, a build system can't resolve the fact that publishing to multiple
formats creates a "lowest common denominator" situation, unless a human is
manually converting between formats in a smart way.


> And currently there isn't something special format built, at least I
> don't see why HTML, PDF and ePUB diff that much between, except the way
> they are created.
> If you see a problem within the supporting of the formats the tooling
> for creating needs improvements! But as long nowadays developers (not
> KiCad devs!) thinking that every problem needs to be solved by some
> Node.JS stuff the "solutions" going worse every day.
>

I am not sure what you mean here, but HTML/CSS is the easiest path to a
nice-looking, accessible, searchable and cross-linked set of documentation
today.  There is lots of tooling out there for accomplishing this goal.


>
> > 2) We currently tie the documentation version together with the
> > application version, and don't have good workflows for "rolling release"
> > of documentation for Linux distros that use separate packages.
>
> There is no need to support some sort of rolling release for tagged
> versions, sorry,


Yes there is, see above for my reasoning.


> I don't get what goal is wanted to archive here. The
> problem isn't the rolling release if you want to name it that way. There
> is a toolchain that is building the various formats and this stays the
> same basically.
>

The current toolchain holds us back from improving the HTML/CSS
documentation.


>
> The current problem is simply the current outdated base which requires a
> lot of work to get this updated. Evolving the documentation for the
> current dev branch is something different from supporting the current
> stable released version.
>

Answered above


>
> > 3) The application itself doesn't handle the situation where offline
> > docs are missing very gracefully, or note to users that when offline
> > docs are present that they are probably outdated.
>
> The KiCad application can't do anything about that circumstance. It
> simply just can start some external resource. So it's the responsibility
> of that resource to handle that. Is see no problem in adding some header
> or similar into the current documentation that is saying th

Re: [Kicad-developers] V6 documentation

[Jon Evans]

The way we have split things up now, the nightly docs are not the
appropriate pairing for the V6 stable release -- they may diverge over time.

I think the vast majority of Linux users also have access to the Internet
and so directing them to the most up-to-date docs is the right move.

I am not saying we should remove any way for people in high-security
offline environments to get documentation, but just that it shouldn't be
the default option.

-Jon

On Wed, Jan 19, 2022 at 12:12 PM Steven A. Falco 
wrote:

> On 1/19/22 12:00 PM, Jon Evans wrote:
> > That just doesn't seem that useful to me.  The fact that Fedora forces
> this process means that Fedora offline docs will always be outdated.
>
> I don't disagree, but really, we could say that everything is always
> outdated - the code, the libs etc.  I have to pick a point in time, and
> create packages as of that point - currently that point is when a new
> release is tagged.  I.e., it is a manual process - I have to consciously
> create the packages, and it then takes a week or so for the packages to sit
> in the testing repositories before being released to general users.  I have
> no control over that process.
>
> > If there is no way to work around it for Fedora, I suggest we develop an
> out-of-band way of delivering offline docs to people (not using the Fedora
> packaging system).
>
> People can always download the nightly docs packages via Copr, which will
> correspond to whatever is in the master branch.  There is no process at the
> moment for nightlies to build from any other branch, although I suppose one
> could be added.
>
> Steve
>
> >
> >
> > On Wed, Jan 19, 2022 at 11:52 AM Steven A. Falco  <mailto:stevenfa...@gmail.com>> wrote:
> >
> > Right now, the downstream (official) Fedora builds depend on a
> single tag for all the components - source code, libraries, and docs.
> >
> > I could substitute a SHA for the docs, but I'd have to hard-code the
> SHA in the "spec file" that controls the build, the same way the tag is
> hard-coded in the spec file.
> >
> > Since all the components are built at the same time from the same
> script, it would not be possible to "update every time something is pushed
> to the V6 branch".  I.e., Fedora builds are not a "rolling release" - they
> are tied to tags.
> >
> >  Steve
> >
> > On 1/19/22 11:38 AM, Jon Evans wrote:
> >  > Carsten,
> >  >
> >  > There is no reason to remove the ability to package docs offline,
> I just don't think it should be a focus of the project.
> >  > The majority of users will be served better by keeping a "rolling
> release" online at docs.kicad.org <http://docs.kicad.org> <
> http://docs.kicad.org <http://docs.kicad.org>> (with a download button,
> ideally).
> >  >
> >  >  > It absolutely doesn't hurt to build completely offline usable
> documentation.
> >  >
> >  > It does hurt the way we do it today, for the following reasons:
> >  >
> >  > 1) We currently support multiple formats, which makes the build
> system and formatting changes complicated
> >  >
> >  > 2) We currently tie the documentation version together with the
> application version, and don't have good workflows for "rolling release" of
> documentation for Linux distros that use separate packages.
> >  >
> >  > 3) The application itself doesn't handle the situation where
> offline docs are missing very gracefully, or note to users that when
> offline docs are present that they are probably outdated.
> >  >
> >  > What I would propose to improve the situation is:
> >  >
> >  > 1) Drop all formats except HTML.  HTML is perfectly fine as an
> offline format, and this allows us to make improvements to the build
> workflow and the layout/style of the docs without worrying about doing so
> in a way that also works for PDF.  If you really want a PDF, you can render
> it from HTML pages anyway.
> >  >
> >  > 2) Change the application to gracefully redirect to the online
> docs if offline docs are missing
> >  >
> >  > 3) Make a better "offline docs" build that adds the warning about
> docs being out-of-date.  Have packagers use this if they want to generate
> docs packages, and maybe make it easy for anyone to download these from the
> website.
> >  >
> >  > 4) Stop tagging the kicad-docs repo with every KiCad code
> release.  Instead, continue the new 

Re: [Kicad-developers] V6 documentation

[Jon Evans]

That just doesn't seem that useful to me.  The fact that Fedora forces this
process means that Fedora offline docs will always be outdated.

If there is no way to work around it for Fedora, I suggest we develop an
out-of-band way of delivering offline docs to people (not using the Fedora
packaging system).


On Wed, Jan 19, 2022 at 11:52 AM Steven A. Falco 
wrote:

> Right now, the downstream (official) Fedora builds depend on a single tag
> for all the components - source code, libraries, and docs.
>
> I could substitute a SHA for the docs, but I'd have to hard-code the SHA
> in the "spec file" that controls the build, the same way the tag is
> hard-coded in the spec file.
>
> Since all the components are built at the same time from the same script,
> it would not be possible to "update every time something is pushed to the
> V6 branch".  I.e., Fedora builds are not a "rolling release" - they are
> tied to tags.
>
> Steve
>
> On 1/19/22 11:38 AM, Jon Evans wrote:
> > Carsten,
> >
> > There is no reason to remove the ability to package docs offline, I just
> don't think it should be a focus of the project.
> > The majority of users will be served better by keeping a "rolling
> release" online at docs.kicad.org <http://docs.kicad.org> (with a
> download button, ideally).
> >
> >  > It absolutely doesn't hurt to build completely offline usable
> documentation.
> >
> > It does hurt the way we do it today, for the following reasons:
> >
> > 1) We currently support multiple formats, which makes the build system
> and formatting changes complicated
> >
> > 2) We currently tie the documentation version together with the
> application version, and don't have good workflows for "rolling release" of
> documentation for Linux distros that use separate packages.
> >
> > 3) The application itself doesn't handle the situation where offline
> docs are missing very gracefully, or note to users that when offline docs
> are present that they are probably outdated.
> >
> > What I would propose to improve the situation is:
> >
> > 1) Drop all formats except HTML.  HTML is perfectly fine as an offline
> format, and this allows us to make improvements to the build workflow and
> the layout/style of the docs without worrying about doing so in a way that
> also works for PDF.  If you really want a PDF, you can render it from HTML
> pages anyway.
> >
> > 2) Change the application to gracefully redirect to the online docs if
> offline docs are missing
> >
> > 3) Make a better "offline docs" build that adds the warning about docs
> being out-of-date.  Have packagers use this if they want to generate docs
> packages, and maybe make it easy for anyone to download these from the
> website.
> >
> > 4) Stop tagging the kicad-docs repo with every KiCad code release.
> Instead, continue the new practice we have started of maintaining major
> release branches for the docs (V5, V6, etc) and have packagers start
> packaging the tip of these branches.  I.e. the Ubuntu package for
> kicad-docs will update every time something is pushed to the V6 branch as
> long as V6 is the stable release, and so on.
> >
> > -Jon
> >
> > On Wed, Jan 19, 2022 at 11:29 AM Carsten Schoenert <
> c.schoen...@t-online.de <mailto:c.schoen...@t-online.de>> wrote:
> >
> > Hello,
> >
> > Am 19.01.22 um 17:21 schrieb Gabriel Staples,
> ElectricRCAircraftGuy.com:
> > ...
> >  > In other words, please do make "online documentation" only, as it
> allows
> >  > faster updates to it and better consistency,
> >
> > please don't!
> > It absolutely doesn't hurt to build completely offline usable
> > documentation. It works for years without special requirements.
> >
> > I work often in environments where I have absolutely no access to the
> > internet, but can use packaged software, so I heavily need offline
> > documentation to do some sort of productive work.
> >
> > --
> > Regards
> > Carsten
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers <
> https://launchpad.net/~kicad-developers>
> > Post to : kicad-developers@lists.launchpad.net  kicad-developers@lists.launchpad.net>
> > Unsubscribe : https://launchpad.net/~kicad-developers <
> https://launchpad.net/~kicad-developers>
> > More help   : https://help.launchpad.net/ListHelp <
> https://help.launchpad.net/Lis

Re: [Kicad-developers] V6 documentation

[Jon Evans]

Carsten,

There is no reason to remove the ability to package docs offline, I just
don't think it should be a focus of the project.
The majority of users will be served better by keeping a "rolling release"
online at docs.kicad.org (with a download button, ideally).

> It absolutely doesn't hurt to build completely offline usable
documentation.

It does hurt the way we do it today, for the following reasons:

1) We currently support multiple formats, which makes the build system and
formatting changes complicated

2) We currently tie the documentation version together with the application
version, and don't have good workflows for "rolling release" of
documentation for Linux distros that use separate packages.

3) The application itself doesn't handle the situation where offline docs
are missing very gracefully, or note to users that when offline docs are
present that they are probably outdated.

What I would propose to improve the situation is:

1) Drop all formats except HTML.  HTML is perfectly fine as an offline
format, and this allows us to make improvements to the build workflow and
the layout/style of the docs without worrying about doing so in a way that
also works for PDF.  If you really want a PDF, you can render it from HTML
pages anyway.

2) Change the application to gracefully redirect to the online docs if
offline docs are missing

3) Make a better "offline docs" build that adds the warning about docs
being out-of-date.  Have packagers use this if they want to generate docs
packages, and maybe make it easy for anyone to download these from the
website.

4) Stop tagging the kicad-docs repo with every KiCad code release.
Instead, continue the new practice we have started of maintaining major
release branches for the docs (V5, V6, etc) and have packagers start
packaging the tip of these branches.  I.e. the Ubuntu package for
kicad-docs will update every time something is pushed to the V6 branch as
long as V6 is the stable release, and so on.

-Jon

On Wed, Jan 19, 2022 at 11:29 AM Carsten Schoenert 
wrote:

> Hello,
>
> Am 19.01.22 um 17:21 schrieb Gabriel Staples, ElectricRCAircraftGuy.com:
> ...
> > In other words, please do make "online documentation" only, as it allows
> > faster updates to it and better consistency,
>
> please don't!
> It absolutely doesn't hurt to build completely offline usable
> documentation. It works for years without special requirements.
>
> I work often in environments where I have absolutely no access to the
> internet, but can use packaged software, so I heavily need offline
> documentation to do some sort of productive work.
>
> --
> Regards
> Carsten
>
> ___
> Mailing list: https://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 documentation

[Jon Evans]

I am not saying offline documentation isn't important.

I'm saying offline documentation *bundled with a specific KiCad release*
isn't important.

If someone needs offline documentation, we should make it easy for them to
obtain the latest "snapshot" of any given doc branch from our website.
Just bundling a snapshot with the code release will mean that the docs are
not in sync with the code (because we don't have a team of doc writers who
keep the docs up-to-date at the same rate that we release code changes)

-Jon

On Wed, Jan 19, 2022 at 11:21 AM Gabriel Staples, ElectricRCAircraftGuy.com
 wrote:

> > I'm not sure that this is a very important feature in today's world.
>
> In many parts of the government, and in some research labs, offline
> documentation is still **very important** because they block nearly all of
> the internet. But, a healthy compromise would be to have online
> documentation only, but to have it downloadable as an html website package
> so you can still browse it when offline.
>
> Also, i can see some rural schools and areas not having good internet and
> being in trouble if someone like me wants to get the kids excited about
> KiCad but we can't load the documentation. So, again, it needs to be easily
> downloadable.
>
> In other words, please do make "online documentation" only, as it allows
> faster updates to it and better consistency, but please do also make the
> whole documentation site easily downloadable to be viewed in a browser when
> offline.
>
>
> Thanks!
>
> Gabriel Staples
>
> (sent from my Android)
>
> Le mar. 18 janv. 2022, 11:12 AM, Jon Evans  a écrit :
>
>> We have decided to update the online documentation in a rolling fashion,
>> meaning that new changes go "live" pretty quickly after being approved and
>> merged.
>>
>> The version that is bundled with the application is a snapshot in time
>> (at the point that software release was made).
>>
>> I think moving to an online-only help system is actually a good idea and
>> I've talked about this before some -- it would also make it easier to
>> improve the formatting of the documentation, since we would have only one
>> output format (HTML/CSS) to deal with.
>>
>> The main reason to include offline documentation (other than "because
>> that's how it's always been done with KiCad") is to provide documentation
>> that is accessible if the user's computer doesn't have an internet
>> connection.  I'm not sure that this is a very important feature in today's
>> world.
>>
>> -Jon
>>
>> On Tue, Jan 18, 2022 at 1:05 PM Tom A.  wrote:
>>
>>> I don't have view at all, not really a software engineer so may take a
>>> bit of spamming with some questions that may be quite obvious to others.
>>>
>>> My first question is why in the software Help section is so dated and
>>> online version much more up to date? It seems you can access online version
>>> from the software, so why to include old (probably no more relevant)
>>> documentation?
>>>
>>> Regards,
>>> Tomas
>>>
>>> On Tue, 18 Jan 2022, 17:17 Jon Evans,  wrote:
>>>
>>>> I don't personally see the point of spamming the list with back and
>>>> forth about setting up Git/Gitlab, installing dependencies, etc.
>>>>
>>>> But, I am not opposed to it if others don't care.
>>>>
>>>> -Jon
>>>>
>>>> On Tue, Jan 18, 2022 at 12:02 PM Marco Ciampa 
>>>> wrote:
>>>>
>>>>> On Tue, Jan 18, 2022 at 09:10:22AM -0500, Jon Evans wrote:
>>>>> > Hi Tomas,
>>>>> >
>>>>> > I've been loosely coordinating documentation updates for V6.  There
>>>>> are not
>>>>> > very many other people working on it.  We'd be happy to have your
>>>>> help.
>>>>> > If you contact me off-list I can help you get set up to make changes
>>>>> and we
>>>>> > can figure out where you'd like to start.
>>>>>
>>>>> I don't want to be rude but I do not understand. This list is almost
>>>>> silent. For sure some docs dev set-up instructions will not hurt
>>>>> anybody
>>>>> and perhaps there is something to learn (I bet I'll learn something
>>>>> anyway ...). So please do not discuss that elsewhere. This list was
>>>>> meant
>>>>> also for this.
>>>>>
>>>>> --
>>>>>
>>>>> Saluton,
>&g

Re: [Kicad-developers] V6 documentation

[Jon Evans]

The documentation lives in this git repo:
https://gitlab.com/kicad/services/kicad-doc

The same sources build the version on the website (docs.kicad.org) and the
offline docs.

If keeping the offline docs is important, I think the next best thing is to
insert some extra text in the offline build that gives a warning that
offline docs are likely to be outdated and links to the website.

-Jon

On Wed, Jan 19, 2022 at 8:28 AM Tom A.  wrote:

> In my opinion it is great to have fall-back plan such as built in
> documentation (which is particularly handy if you lost internet connection)
> but at the moment it is too different from online version which is why I
> raised this question.
>
> Assuming there is a reasonably easy way to export online docs into
> something that can be bundled together with the software I see no harm in
> continuing with both methods of reaching documentation. Obviously my
> personal opinion.
>
> Where is the current online documentation stored, how to access/modify it
> and how revisions are handled? Is there lifecycle process involved
> (draft-under review-approved/released) or pretty much write it and ask
> someone to look over it?
>
>
> Regards,
> Tomas
>
>
> On Wed, 19 Jan 2022, 08:27 Marco Ciampa,  wrote:
>
>> On Wed, Jan 19, 2022 at 08:02:51AM +, Martijn Kuipers wrote:
>> > If separate, you could update it more frequently. Just take care it is
>> > understandable for which lkicad version it applies.
>> >
>> > Local docs is where I look first.
>>
>> Version matching should be handled by the packaging system in use, deb /
>> rpm / etc. ... btw keeping docs as a separate package is a good idea and
>> I think it is already so for most of the linux distributions...
>>
>> --
>>
>> Saluton,
>> Marco Ciampa
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] V6 documentation

[Jon Evans]

We have decided to update the online documentation in a rolling fashion,
meaning that new changes go "live" pretty quickly after being approved and
merged.

The version that is bundled with the application is a snapshot in time (at
the point that software release was made).

I think moving to an online-only help system is actually a good idea and
I've talked about this before some -- it would also make it easier to
improve the formatting of the documentation, since we would have only one
output format (HTML/CSS) to deal with.

The main reason to include offline documentation (other than "because
that's how it's always been done with KiCad") is to provide documentation
that is accessible if the user's computer doesn't have an internet
connection.  I'm not sure that this is a very important feature in today's
world.

-Jon

On Tue, Jan 18, 2022 at 1:05 PM Tom A.  wrote:

> I don't have view at all, not really a software engineer so may take a bit
> of spamming with some questions that may be quite obvious to others.
>
> My first question is why in the software Help section is so dated and
> online version much more up to date? It seems you can access online version
> from the software, so why to include old (probably no more relevant)
> documentation?
>
> Regards,
> Tomas
>
> On Tue, 18 Jan 2022, 17:17 Jon Evans,  wrote:
>
>> I don't personally see the point of spamming the list with back and forth
>> about setting up Git/Gitlab, installing dependencies, etc.
>>
>> But, I am not opposed to it if others don't care.
>>
>> -Jon
>>
>> On Tue, Jan 18, 2022 at 12:02 PM Marco Ciampa  wrote:
>>
>>> On Tue, Jan 18, 2022 at 09:10:22AM -0500, Jon Evans wrote:
>>> > Hi Tomas,
>>> >
>>> > I've been loosely coordinating documentation updates for V6.  There
>>> are not
>>> > very many other people working on it.  We'd be happy to have your help.
>>> > If you contact me off-list I can help you get set up to make changes
>>> and we
>>> > can figure out where you'd like to start.
>>>
>>> I don't want to be rude but I do not understand. This list is almost
>>> silent. For sure some docs dev set-up instructions will not hurt anybody
>>> and perhaps there is something to learn (I bet I'll learn something
>>> anyway ...). So please do not discuss that elsewhere. This list was meant
>>> also for this.
>>>
>>> --
>>>
>>> Saluton,
>>> Marco Ciampa
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] V6 documentation

[Jon Evans]

I don't personally see the point of spamming the list with back and forth
about setting up Git/Gitlab, installing dependencies, etc.

But, I am not opposed to it if others don't care.

-Jon

On Tue, Jan 18, 2022 at 12:02 PM Marco Ciampa  wrote:

> On Tue, Jan 18, 2022 at 09:10:22AM -0500, Jon Evans wrote:
> > Hi Tomas,
> >
> > I've been loosely coordinating documentation updates for V6.  There are
> not
> > very many other people working on it.  We'd be happy to have your help.
> > If you contact me off-list I can help you get set up to make changes and
> we
> > can figure out where you'd like to start.
>
> I don't want to be rude but I do not understand. This list is almost
> silent. For sure some docs dev set-up instructions will not hurt anybody
> and perhaps there is something to learn (I bet I'll learn something
> anyway ...). So please do not discuss that elsewhere. This list was meant
> also for this.
>
> --
>
> Saluton,
> Marco Ciampa
>
> ___
> Mailing list: https://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 documentation

[Jon Evans]

Hi Tomas,

I've been loosely coordinating documentation updates for V6.  There are not
very many other people working on it.  We'd be happy to have your help.
If you contact me off-list I can help you get set up to make changes and we
can figure out where you'd like to start.

Best,
Jon

On Tue, Jan 18, 2022 at 9:03 AM Tom A.  wrote:

> Hi all,
>
> I've been using KiCad daily for last couple of years and I think it's
> great project with a lot of potential.
>
> Congratulations on V6 release to everyone involved.
>
> I had few challenges with new version and found documentation being rather
> weak. Is there someone working on it (dedicated) or its just random effort?
> Since I use a lot of functions and trained few people to use the software,
> I could volunteer to work on it. I've written lots of documentation for OEM
> manufacturer and believe am more than capable of it.
>
> I could also translate package to my native language (LT).
>
> Need directions please :)
>
> Regards,
> Tomas
> ___
> Mailing list: https://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] Was the initial graphics mode screen removed?

[Jon Evans]

> Do you intend to support an new backend on  MacOS and Windows only, and
keep the current OpenGL backend on Linux (can't see a good reason for this)
?

No, if we switched to some abstraction layer such as bgfx, we'd use that on
all platforms.  That layer may then end up using OpenGL as _its_ backend.

> can say that any speed bottleneck is likely NOT in the rendering engine,
but in the rest of the code.

There are certain situations (that don't impact the majority of current
KiCad users) where the rendering engine is indeed a bottleneck in the PCB
editor and Gerber viewer.  As we try to make KiCad applicable to more
high-end designers, it could become an issue for more people.

-Jon

On Tue, Jan 11, 2022 at 4:46 PM pmx  wrote:

>
>
> Le 11/01/2022 à 21:59, Jon Evans a écrit :
>
> The current offerings (e.g. bgfx) are generally multi-platform but without
> the software fallback option.
>
>
> OK, got it.
>
> I just had a look at bgfx, seems neat.
>
> BTW, the bgfx::Init() fuction seems to accept a
> BGFX_PCI_ID_SOFTWARE_RASTERIZER parameter, may be the trick (or not...)
>
> Now, I totally agree that there is no point to develop/support a private,
> updated, fallback rendering engine from scratch in the future.
>
>
>
> Yes, OpenGL will likely remain supported on systems other than Windows/Mac
> for now at least, but we at some point will have to decide if we want to
> bump our minimum OpenGL version to something higher than 2.1.
>
>
> Do you intend to support an new backend on  MacOS and Windows only, and
> keep the current OpenGL backend on Linux (can't see a good reason for this)
> ?
> If it were me, I wouldn't touch the current rendering code (i.e. like
> switching to OpenGL 4.x), and devote all the future effort toward the
> integration of the new graphics backend on all platforms.
>
> From my previous tests (Kicad 5.99), I can say that any speed bottleneck
> is likely NOT in the rendering engine, but in the rest of the code.
> I can't count how many Boost:: containers are scanned, and even
> temporarily created and deleted, when you play with the graphics elements
> in the schematics !
> (The 3D viewer is a different matter).
>
> Pierre.
>
>
>
>
>
>
___
Mailing list: https://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] Was the initial graphics mode screen removed?

[Jon Evans]

The current offerings (e.g. bgfx) are generally multi-platform but without
the software fallback option.

Yes, OpenGL will likely remain supported on systems other than Windows/Mac
for now at least, but we at some point will have to decide if we want to
bump our minimum OpenGL version to something higher than 2.1.

On Tue, Jan 11, 2022 at 3:57 PM pmx  wrote:

>
>
> Le 11/01/2022 à 21:10, Jon Evans a écrit :
> > > IMHO, we shouldn't remove anything that helps to deal gracefully
> > with the diversity of situations (like a virtual machine), graphics
> > hardware and video drivers... and their possible bugs ! (as stated
> > about X11/Mesa).
> > [...]
> > we need to push forward into more modern hardware-accelerated graphics
> > APIs in order to make it possible to implement some desirable
> > features, help performance on large designs, etc.
> >
> > The idea is that instead of being stuck on some "lowest common
> > denominator" OpenGL, we can instead for example use DirectX on Windows
> > and Metal on macOS.
> >
> > -Jon
> >
>
> It would be nice, then, to choose a modern backend that supports
> natively multiple hardware engine, including a pure software rendering
> that could be used as "fallback". Slower, but may save the day to some.
>
>
> These third party graphics layers are usually multi platform/OS, and a
> software only rendering option is reasonable expectation, but I really
> don't know what is the current "offer", in 2021.
>
>
> Anyway, taking this into account from the beginning could make it happen
> with very little development overhead later.
>
>
> (BTW, OpenGL may well still be the hidden engine for Unix-like systems -
> just my guess).
>
> Pierre.
>
> ___
> Mailing list: https://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] Was the initial graphics mode screen removed?

[Jon Evans]

> IMHO, we shouldn't remove anything that helps to deal gracefully with the
diversity of situations (like a virtual machine), graphics hardware and
video drivers... and their possible bugs ! (as stated about X11/Mesa).

The fallback engine we use today does not have feature-parity with the
accelerated engine, and that is not an easily-solvable problem.
Continuing to support it will continue to hold us back.

Putting aside the issue of virtual machines (our stance is that we don't
need to spend effort on supporting VMs because KiCad itself should run fine
on the host OS), we need to push forward into more modern
hardware-accelerated graphics APIs in order to make it possible to
implement some desirable features, help performance on large designs, etc.

The idea is that instead of being stuck on some "lowest common denominator"
OpenGL, we can instead for example use DirectX on Windows and Metal on
macOS.

-Jon

On Tue, Jan 11, 2022 at 3:02 PM Steven A. Falco 
wrote:

> On 1/11/22 02:33 PM, pmx wrote:
> >
> >
> > Le 11/01/2022 à 19:25, Steven A. Falco a écrit :
> >>> I don't think the dialog would help any in the situation you are
> describing with the artifacts on the screen. It was only shown on first
> start, so it wouldn't give the choice in future runs (which would be after
> you notice all the artifacts). You can change the rendering backend in the
> preferences pane though, so you can switch back to the fallback graphics
> that way.
> >>
> >> I'm describing two situations.  One is the artifacts on my desktop, and
> one is the segfault on VMs.  As long as the window opens and is somewhat
> usable, then one can select fallback graphics easily from preferences, as
> you said.  The bigger problem is on the VMs where it crashes before the
> window gets a chance to even open.  I'll look at the issue you linked and
> see if that helps.  I'll also try a test build from the tip of the 6.0
> branch and see how that behaves.
> >>
> >> I'm more concerned that fallback graphics might be removed entirely at
> some point.  Hopefully accelerated mode will be bullet-proof before that
> decision is made.
> >>
> >> Steve
> >
> > Unless there is much work involved to keep both backends working in the
> future, I strongly feel that a fallback graphics engine is a must and
> should be kept alive, even if this requires some (moderate...) effort.
> >
> > IMHO, we shouldn't remove anything that helps to deal gracefully with
> the diversity of situations (like a virtual machine), graphics hardware and
> video drivers... and their possible bugs ! (as stated about X11/Mesa).
> >
> >
> > @ Steven :
> > About the possibility to choose a graphics backend, in any situation,
> and indeed before a segfault  happens  :
> >
> > What about a command line option (when launching Kicad), to force a
> specific graphics backend, including a "safe" fallback ?
> > Should be quite straightforward.
>
> The segfault is fixed in the latest 6.0 code, so I guess there is no
> longer a need for either the dialog or a command.
>
> However, some of the visual artifacts are still happening even with the
> latest 6.0 code, therefore the fallback graphics mode is still essential.
>
> I've added another video showing what it looks like when I resize the
> pcbnew screen.  Please see comment
> https://gitlab.com/kicad/code/kicad/-/issues/10375#note_807446302 and
> https://gitlab.com/kicad/code/kicad/uploads/0aed9475350c1665d0cc200187536121/simplescreenrecorder-2022-01-11_14.29.16.mkv
> for details.
>
> I'm a little concerned that new users seeing these artifacts won't know
> what to do about them, and may give up.
>
> 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] help compliling kicad

[Jon Evans]

It looks like your source directory is dirty (not the build dir)

Try "git clean -fx" or similar.

-Jon

On Fri, Dec 31, 2021 at 1:30 PM Marco Ciampa  wrote:

> Hello devs!
> I need some help.
>
> Sometimes my cmake configuration goes wrong and I get stuck with this
> kind of error:
>
> Built target scripting_kiface
> [ 25%] Building CXX object
> common/CMakeFiles/pcbcommon.dir/__/pcbnew/netlist_reader/kicad_netlist_reader.cpp.o
> /home/marco/git/gitlab/kicad/branch-6.0/pcbnew/netlist_reader/kicad_netlist_reader.cpp:
> In member function ‘void KICAD_NETLIST_PARSER::parseNet()’:
> /home/marco/git/gitlab/kicad/branch-6.0/pcbnew/netlist_reader/kicad_netlist_reader.cpp:241:22:
> error: ‘T_pinfunction’ was not declared in this scope; did you mean
> ‘pin_function’?
>   241 | case T_pinfunction:
>   |  ^
>   |  pin_function
> /home/marco/git/gitlab/kicad/branch-6.0/pcbnew/netlist_reader/kicad_netlist_reader.cpp:247:22:
> error: ‘T_pintype’ was not declared in this scope; did you mean ‘pin_type’?
>   247 | case T_pintype:
>   |  ^
>   |  pin_type
> /home/marco/git/gitlab/kicad/branch-6.0/pcbnew/netlist_reader/kicad_netlist_reader.cpp:
> In member function ‘void KICAD_NETLIST_PARSER::parseComponent()’:
> /home/marco/git/gitlab/kicad/branch-6.0/pcbnew/netlist_reader/kicad_netlist_reader.cpp:371:14:
> error: ‘T_property’ was not declared in this scope
>   371 | case T_property:
>   |  ^~
> make[2]: *** [common/CMakeFiles/pcbcommon.dir/build.make:670:
> common/CMakeFiles/pcbcommon.dir/__/pcbnew/netlist_reader/kicad_netlist_reader.cpp.o]
> Errore 1
> make[1]: *** [CMakeFiles/Makefile2:2290:
> common/CMakeFiles/pcbcommon.dir/all] Errore 2
> make: *** [Makefile:163: all] Errore 2
>
> I was once able to figure out how was wrong but unfortunately I do not
> remember what went wrong in the automatic configuration of cmake.
>
> Deleting the build dir and restarting cmake auto conf unfortunately does
> not help.
>
> Any hint?
>
> My system is Ubuntu 20.04 intel 64...
>
> --
>
> Saluton,
> Marco Ciampa
>
> ___
> Mailing list: https://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] 6.0.0 build flags

[Jon Evans]

I agree, KICAD_PCM can be removed now.

On Sat, Dec 25, 2021 at 7:27 AM Nick Østergaard  wrote:

> Having the unused parameters is no harm, it will only generate a
> warning at configure time.
>
> The KICAD_PCM flag already defaults to ON, but I guess it should just
> be removed as an option?  Are there any reason to keep it as a toggle
> for v6+?
>
> I am not aware of anything new flags for features in v7.
>
> On Fri, 24 Dec 2021 at 18:21, Steven A. Falco 
> wrote:
> >
> > I looked at CMakeLists.txt, and it appears that some of the old 5.x
> build flags have been removed, and some new flags have been added.
> >
> > In particular, the following scripting flags are gone (only
> KICAD_SCRIPTING_WXPYTHON remains):
> >
> > KICAD_SCRIPTING
> > KICAD_SCRIPTING_ACTION_MENU
> > KICAD_SCRIPTING_MODULES
> > KICAD_SCRIPTING_PYTHON3
> > KICAD_SCRIPTING_WXPYTHON_PHOENIX
> >
> > These flags still appear in files like .gitlab/Windows-CI.yml and should
> be removed.  They should also be removed from the Fedora nightly builds,
> and probably from other builds, as well.
> >
> > I can remove the above flags from the Fedora nightly builds, and I can
> create an MR for the .gitlab files, if desired.  Please let me know if you
> want that MR.
> >
> > There are a few new flags that I think should be added to the Fedora
> builds for clarity, even though we don't change the defaults.  In
> particular, I propose to add:
> >
> > KICAD_PCM=ON
> > KICAD_USE_EGL=OFF
> >
> > Are there any other new flags that I should add?  (I could add every
> single flag from CMakeLists.txt, but most seem related to debug, and would
> just clutter the cmake command.)
> >
> > 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
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] New lead developer announcement

[Jon Evans]

Welcome Mikolaj!  Happy to have you in this role :)

-Jon

On Fri, Nov 19, 2021 at 9:15 AM Wayne Stambaugh 
wrote:

> I am happy to announce that Mikolaj Wielgus has accepted an invitation
> to become a member of the KiCad lead development team.  Mikolaj has made
> some significant contributions to the KiCad project and I look forward
> to his contributions as lead developer.  Please join me in
> congratulating Mikolaj in his new role.
>
> Cheers,
>
> Wayne
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Version 6 release candidate 1

[Jon Evans]

Just to be clear, I think it's fine to do this if you are testing your
build/packaging process, but the docs at the rc1 tag are not going to be
that useful to users, as they are in an incomplete and
partially-untranslated state.  We are in the middle of a project to update
the docs for V6, and we are doing this out of sync with the code (so we did
not wait for the rc1 tag until the docs were at a "release candidate"
state, in other words).

On Thu, Nov 18, 2021 at 3:13 PM Steven A. Falco 
wrote:

> On 11/18/21 03:04 PM, Johannes Maibaum wrote:
> > Am Donnerstag, dem 18.11.2021 um 14:58 -0500 schrieb Jon Evans:
> >> When do you need it by?  The docs are nowhere near ready for the
> >> final release, so if this isn't a hard requirement, I would suggest
> >> not bothering to package the docs for now.
> >
> > I hope to get 6.0.0-rc1 added to the flathub-beta channel over the
> > weekend and this was an item still missing on my list.
> >
> > But there is no immediate need at all before the final release. I had
> > included the docs into the flatpak, because this allowed to add a "has
> > (translated) user docs" flag which is one further green box checked in
> > software centers like GNOME Software.
> >
> > It's fine if they don't become ready in time. I will then just remove
> > that box again until they become ready at some later point.
>
> You can download the doc as a tar from the following URL:
>
>
> https://gitlab.com/kicad/services/kicad-doc/-/archive/6.0.0-rc1/kicad-doc-6.0.0-rc1.tar.bz2
>
> You can also change the "bz2" to "gz" if you prefer that format.
>
> BTW, I've made the 6.0.0-rc1 builds for Fedora Rawhide, but they haven't
> been picked up by the mirrors yet.
>
> I will not make 6.0.0 builds for Fedora 34 / 35 etc, because it is against
> policy to have a major version change on those.  Thus Fedora 36 (in about 6
> months) will be the first one that ships a 6.0.0 build.
>
> 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] Version 6 release candidate 1

[Jon Evans]

Well, the new docs are not translated yet either, so there's that :)

On Thu, Nov 18, 2021 at 3:04 PM Johannes Maibaum  wrote:

> Am Donnerstag, dem 18.11.2021 um 14:58 -0500 schrieb Jon Evans:
> > When do you need it by?  The docs are nowhere near ready for the
> > final release, so if this isn't a hard requirement, I would suggest
> > not bothering to package the docs for now.
>
> I hope to get 6.0.0-rc1 added to the flathub-beta channel over the
> weekend and this was an item still missing on my list.
>
> But there is no immediate need at all before the final release. I had
> included the docs into the flatpak, because this allowed to add a "has
> (translated) user docs" flag which is one further green box checked in
> software centers like GNOME Software.
>
> It's fine if they don't become ready in time. I will then just remove
> that box again until they become ready at some later point.
> >
>
___
Mailing list: https://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] Version 6 release candidate 1

[Jon Evans]

When do you need it by?  The docs are nowhere near ready for the final
release, so if this isn't a hard requirement, I would suggest not bothering
to package the docs for now.

On Thu, Nov 18, 2021 at 2:52 PM Johannes Maibaum  wrote:

> Hi Seth & list,
>
> Am Dienstag, dem 16.11.2021 um 12:52 -0800 schrieb Seth Hillbrand:
> > The other 5 repos (docs, symbols, footprints, templates and packages3d)
> > are tagged.  i18n is integrated into the v6 source repository and won't
> > be tagged separately.
>
> Will there be a kicad-doc-6.0.0-rc1.tar.gz uploaded to
> https://kicad-downloads.s3.cern.ch/docs at some point? I used to use
> these tarballs of the ready-built docs for the flatpak user docs, but
> so far it is not available.
>
>
> Cheers,
> Johannes
>
> ___
> Mailing list: https://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] Calling all Python devs - KiCad 6 and plugin repository information

[Jon Evans]

Hi all,

If you develop Python plugins for KiCad, this message is for you!

First of all, as you have probably seen, the new Python API won't be
included in KiCad 6.0.  We still want to support the existing SWIG API that
allows the creation of action plugins in the PCB editor and external
scripts, but there have been some changes to the API between 5.1 and now
due to underlying code changes in KiCad.  We have already been fixing some
regressions in the SWIG API that should make it possible to port your
plugins to 6.0.

We need your help to test out your plugins and make any changes needed for
the 6.0 API, so that we can identify and fix any remaining regressions from
5.1 before the December 15 deadline. If you have any trouble getting your
scripts to work in 6.0 RC1, please open an issue on GitLab and we will
assist.  It is important to us that existing plugins are able to continue
to work.

Second, the new Plugin and Content Manager (PCM) is working and our new
public plugin repository is open for submissions.  If you weren't already
aware, this feature provides an easy way for KiCad users to discover and
install your plugins.  We highly encourage all plugin developers to submit
your plugins to the repository once they are compatible with KiCad 6.0.
More information about this process is documented on the dev-docs site[1].
Please get in touch if you have any questions, we'd like to help.

Best,
Jon

[1] https://dev-docs.kicad.org/en/addons/
___
Mailing list: https://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] Stability drive? [was Re: Version 6 release schedule]

[Jon Evans]

To give another example:  the wxWidgets team knows that better HiDPI
support is needed, and has been working on it.

I don't have access to a system where I would prefer to run at a scaling
factor other than 1, so I'm not sure what issues you see.  If you report
them, we can determine:

- is the issue in wx or kicad?
- if in wx, is the wx team already tracking it?

We usually do not have the resources to fix upstream wxWidgets bugs
ourselves, except for cases where we can make fixes to our fork for macOS
or Windows (the burden is obviously higher to get something upstreamed for
Linux users).  However, if we at least know that a problem exists upstream,
than we can track it and volunteer devs who may have time to work on it can
find it.

-Jon

On Mon, Nov 8, 2021 at 11:49 AM Jon Evans  wrote:

> I certainly agree with a stability drive, I would just caution to not
> assume that the devs see the same issues you do, and therefore are ignoring
> the stability problems you see.
>
> > Finally, I know issues that are GTK or WX based might be hard or even
> impossible for Kicad to fix, but in the past I have often found it best to
> fix them (if possible) anyway because they could be hiding other issues,
> either in a wood-trees way or because of side effects. The same applies to
> warnings from the compiler, etc.
>
> I agree with this in principle, but in practice, some of these issues are
> either inconsequential (such as the GTK warnings), very hard to figure out
> how to fix, or both.
> We always welcome people to work on these issues, but if they don't result
> in an actual impact to KiCad users, and they are hard to fix (or require
> upstream changes to fix), it is hard to prioritize them internally in the
> KiCad dev team.
>
> -Jon
>
> On Mon, Nov 8, 2021 at 11:46 AM Ruth Ivimey-Cook  wrote:
>
>> Jon,
>>
>> I realize there was a lot of content, but I also know that little of it
>> was of very much use, because in most cases the issues seen have not been
>> repeatable. I will see what I can do, though.
>>
>> Mostly, this mail was about making the case for the devs to agree to a
>> stability drive, and go looking for problems.
>>
>> Finally, I know issues that are GTK or WX based might be hard or even
>> impossible for Kicad to fix, but in the past I have often found it best to
>> fix them (if possible) anyway because they could be hiding other issues,
>> either in a wood-trees way or because of side effects. The same applies to
>> warnings from the compiler, etc.
>>
>> Regards,
>>
>> Ruth
>>
>>
>> On 08/11/2021 16:38, Jon Evans wrote:
>>
>> Hi Ruth,
>>
>> Thanks for the notes.  There is a lot of content in your email, and I
>> worry it will get lost if it doesn't get split up into multiple issues on
>> the issue tracker.
>>
>> Some of the issues you mention (GTK warnings, ASan issues related to
>> Python, etc) are known issues and we don't plan to fix them at this time
>> because we don't think they relate to any actual stability issues that
>> KiCad users will experience or observe when running a release build.  Some
>> of these are caused by wxWidgets itself, and some will be fixed when we
>> move away from SWIG for the Python API in V7.
>>
>> Any of the issues you mention that are actually KiCad issues should get
>> addressed if possible.  However, each of them will require its own
>> discussion thread, maybe including more specific reproduction steps,
>> example projects that cause the issue, etc.  We'd really appreciate it if
>> you could report the crashes and other misbehavior you see on GitLab (or
>> via the Report Bug entry in the Help menu) one by one, so that they can be
>> addressed.
>>
>> Best,
>> Jon
>>
>> On Mon, Nov 8, 2021 at 11:12 AM Ruth Ivimey-Cook  wrote:
>>
>>> From my recent experience with self-built flatpak versions of KiCad 5.99
>>> (head), I love the recent changes in the program.
>>>
>>> I also feel there is an amount of work still needed to improve
>>> stability. I would suggest people use the program from a debug build with
>>> address sanitisation enabled, which among other things enables the Wx
>>> assertions. (I would encourage devs to include more assertions in the kicad
>>> code as well!)
>>>
>>> I have had several crashes recently, though only a few repeatably. There
>>> is a bug somewhere in the pcb track drag code when lots of suggested track
>>> segments are being created/deleted, perhaps to do with an out of bounds
>>> (indexing) error; there is a bug that can put "-1" in the Line Style o

Re: [Kicad-developers] Stability drive? [was Re: Version 6 release schedule]

[Jon Evans]

I certainly agree with a stability drive, I would just caution to not
assume that the devs see the same issues you do, and therefore are ignoring
the stability problems you see.

> Finally, I know issues that are GTK or WX based might be hard or even
impossible for Kicad to fix, but in the past I have often found it best to
fix them (if possible) anyway because they could be hiding other issues,
either in a wood-trees way or because of side effects. The same applies to
warnings from the compiler, etc.

I agree with this in principle, but in practice, some of these issues are
either inconsequential (such as the GTK warnings), very hard to figure out
how to fix, or both.
We always welcome people to work on these issues, but if they don't result
in an actual impact to KiCad users, and they are hard to fix (or require
upstream changes to fix), it is hard to prioritize them internally in the
KiCad dev team.

-Jon

On Mon, Nov 8, 2021 at 11:46 AM Ruth Ivimey-Cook  wrote:

> Jon,
>
> I realize there was a lot of content, but I also know that little of it
> was of very much use, because in most cases the issues seen have not been
> repeatable. I will see what I can do, though.
>
> Mostly, this mail was about making the case for the devs to agree to a
> stability drive, and go looking for problems.
>
> Finally, I know issues that are GTK or WX based might be hard or even
> impossible for Kicad to fix, but in the past I have often found it best to
> fix them (if possible) anyway because they could be hiding other issues,
> either in a wood-trees way or because of side effects. The same applies to
> warnings from the compiler, etc.
>
> Regards,
>
> Ruth
>
>
> On 08/11/2021 16:38, Jon Evans wrote:
>
> Hi Ruth,
>
> Thanks for the notes.  There is a lot of content in your email, and I
> worry it will get lost if it doesn't get split up into multiple issues on
> the issue tracker.
>
> Some of the issues you mention (GTK warnings, ASan issues related to
> Python, etc) are known issues and we don't plan to fix them at this time
> because we don't think they relate to any actual stability issues that
> KiCad users will experience or observe when running a release build.  Some
> of these are caused by wxWidgets itself, and some will be fixed when we
> move away from SWIG for the Python API in V7.
>
> Any of the issues you mention that are actually KiCad issues should get
> addressed if possible.  However, each of them will require its own
> discussion thread, maybe including more specific reproduction steps,
> example projects that cause the issue, etc.  We'd really appreciate it if
> you could report the crashes and other misbehavior you see on GitLab (or
> via the Report Bug entry in the Help menu) one by one, so that they can be
> addressed.
>
> Best,
> Jon
>
> On Mon, Nov 8, 2021 at 11:12 AM Ruth Ivimey-Cook  wrote:
>
>> From my recent experience with self-built flatpak versions of KiCad 5.99
>> (head), I love the recent changes in the program.
>>
>> I also feel there is an amount of work still needed to improve stability.
>> I would suggest people use the program from a debug build with address
>> sanitisation enabled, which among other things enables the Wx assertions.
>> (I would encourage devs to include more assertions in the kicad code as
>> well!)
>>
>> I have had several crashes recently, though only a few repeatably. There
>> is a bug somewhere in the pcb track drag code when lots of suggested track
>> segments are being created/deleted, perhaps to do with an out of bounds
>> (indexing) error; there is a bug that can put "-1" in the Line Style of
>> netclasses and perhaps in other properties too (reported elsewhere); there
>> is a bug somewhere that spams the console with "pixman_region32_init_rect:
>> Invalid rectangle passed" when accessing menus; there is another that threw
>> this:
>>
>> /usr/include/c++/11.2.0/bits/stl_vector.h:1063: std::vector<_Tp,
>> _Alloc>::const_reference std::vector<_Tp,
>> _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) const [with _Tp =
>> VECTOR2; _Alloc = std::allocator >; std::vector<_Tp,
>> _Alloc>::const_reference = const VECTOR2&; std::vector<_Tp,
>> _Alloc>::size_type = long unsigned int]: Assertion '__n < this->size()'
>> failed.
>>
>> ... but where from I know not. There is another in eeschema to do with
>> replacing a symbol footprint using the footprint chooser, though I cannot
>> replicate it and the trace (below) is unhelpful.
>>
>> The memory leak detector shows a lot of memory leaks on exit, though
>> mostly related to Python Eval and to Wx fonts / pango. This la

Re: [Kicad-developers] Stability drive? [was Re: Version 6 release schedule]

[Jon Evans]

Hi Ruth,

Thanks for the notes.  There is a lot of content in your email, and I worry
it will get lost if it doesn't get split up into multiple issues on the
issue tracker.

Some of the issues you mention (GTK warnings, ASan issues related to
Python, etc) are known issues and we don't plan to fix them at this time
because we don't think they relate to any actual stability issues that
KiCad users will experience or observe when running a release build.  Some
of these are caused by wxWidgets itself, and some will be fixed when we
move away from SWIG for the Python API in V7.

Any of the issues you mention that are actually KiCad issues should get
addressed if possible.  However, each of them will require its own
discussion thread, maybe including more specific reproduction steps,
example projects that cause the issue, etc.  We'd really appreciate it if
you could report the crashes and other misbehavior you see on GitLab (or
via the Report Bug entry in the Help menu) one by one, so that they can be
addressed.

Best,
Jon

On Mon, Nov 8, 2021 at 11:12 AM Ruth Ivimey-Cook  wrote:

> From my recent experience with self-built flatpak versions of KiCad 5.99
> (head), I love the recent changes in the program.
>
> I also feel there is an amount of work still needed to improve stability.
> I would suggest people use the program from a debug build with address
> sanitisation enabled, which among other things enables the Wx assertions.
> (I would encourage devs to include more assertions in the kicad code as
> well!)
>
> I have had several crashes recently, though only a few repeatably. There
> is a bug somewhere in the pcb track drag code when lots of suggested track
> segments are being created/deleted, perhaps to do with an out of bounds
> (indexing) error; there is a bug that can put "-1" in the Line Style of
> netclasses and perhaps in other properties too (reported elsewhere); there
> is a bug somewhere that spams the console with "pixman_region32_init_rect:
> Invalid rectangle passed" when accessing menus; there is another that threw
> this:
>
> /usr/include/c++/11.2.0/bits/stl_vector.h:1063: std::vector<_Tp,
> _Alloc>::const_reference std::vector<_Tp,
> _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) const [with _Tp =
> VECTOR2; _Alloc = std::allocator >; std::vector<_Tp,
> _Alloc>::const_reference = const VECTOR2&; std::vector<_Tp,
> _Alloc>::size_type = long unsigned int]: Assertion '__n < this->size()'
> failed.
>
> ... but where from I know not. There is another in eeschema to do with
> replacing a symbol footprint using the footprint chooser, though I cannot
> replicate it and the trace (below) is unhelpful.
>
> The memory leak detector shows a lot of memory leaks on exit, though
> mostly related to Python Eval and to Wx fonts / pango. This latter group
> might be all Wx, fontconfig or pango's fault, not kicad --
> wxCairoContext::GetTextExtent is one common denominator,
> wxWindow::GetCharHeight is another. [[ I did attempt to compile with
> wxwindows head, which is significantly advanced over the 3.1.5 currently
> being used, but sadly wxpython doesn't build against head (probably not a
> big thing - there's a patch already which might just need extending).
> Probably worth pursuing a little though. ]]
>
> The python leaks are mostly from dictresize, and I think they result from
> old dict memory, rather than being directly freed on resize, being added to
> the keys_free_list and then never freed from that. See
> https://github.com/python/cpython/blob/9942f42a93ccda047fd3558c47b822e99afe10c0/Objects/dictobject.c#L1281
> . In turn this would suggest _PyDict_ClearFreeList / _PyDict_Fini is
> never called.
>
> I also think there is a regression: when selecting things at a Via, the
> Via itself is always selected and the normal select-what menu list doesn't
> appear. This makes it impossible to select anything within the area of a
> Via unless you move the Via first. The select-what does appear in other
> cases. I'm not 100% sure, but I think I've seen similar behaviour where
> tracks are selected when a graphic line could also have been selected. I
> may be wrong there though.
>
> Relating to Wx and HiDPI displays, even compiled with wx 3.1.5, many of
> the text widgets are too small (by roughly the factor of the DPI adjustment
> my display is using, 1.75) and either in consequence or also, the default
> window sizes are also too small, not encompassing their content.
>
> Finally, I have frequently been surprised by windows being raised or not
> raised. For example, I did a DRC check last night having not started
> eeschema in that session. The previous session had crashed, so when DRC
> started eeschema, eeschema posted an 'oops' message dialog asking to
> recover. All well and good, except the pcbnew window obscured both eeschema
> and its oops dialog, and pcbnew was left hung as if it had died. I did
> eventually realize it hadn't, and why, but it was not at all obvious.
>
> Another weirdness is 

Re: [Kicad-developers] Version 6 release schedule

[Jon Evans]

Hi Jan and José,

Unfortunately I don't have a status update for you on the pybind11 API.
I'm going to investigate fixing the regressions in the SWIG API so that
your plugins can access the board design settings again.

Best,
Jon

On Mon, Nov 1, 2021 at 6:04 AM Jan Mrázek  wrote:

> Hello Wayne and others,
>
> I am really looking forward for the release. As a maintainer of several
> KiCAD plugins, I would like to add support for KiCAD 6 to them  before
> it is released so my users can migrate right away. However, the last
> time I wanted to add the support I run into a problem of missing Python
> API due to the migration from SWIG to Pybind.
>
> Could you (or anyone else)  give me a brief overview (or point me to
> relevant sources) where can I learn how was the API changed so I can
> adapt my plugins? I was trying to learn about it from the commits, but I
> wasn't able to learn anything due to the tremendous commit rate (I
> admire the whole team for that), so this is why I am reaching out to you.
>
> Also, what can we expect in v6? And what will lack? I noticed that some
> of the Python API relevant issues, that I consider as essential, still
> left open and have no updates in them:
>
> - Pbnew Python API: Cannot to set board design settings
>   (https://gitlab.com/kicad/code/kicad/-/issues/6885)
> - Python: Missing API for setting board aux origin
> (https://gitlab.com/kicad/code/kicad/-/issues/8836)
> - Eeschema python library
> (https://gitlab.com/kicad/code/kicad/-/issues/2077)
>
> Jan
>
> On 28. 10. 21 23:09, Wayne Stambaugh wrote:
> > The lead development team has agreed on a version 6 release schedule
> > as follows:
> >
> >
> > - String freeze November 1.
> > - Tag RC1 on November 15.
> > - All repos frozen on December 14.
> > - Tag all repos with 6.0.0 on December 15.
> > - 6.0.0 release announcement December 31 (maybe the day before Christmas
> >   just for fun).
> > - Branch V6 and open master for new feature development on January 1.
> >
> > Our goal is to stick to that as closely as possible so if you have any
> > outstanding work, please use this schedule as a reference to get it done.
> >
> > Going forward, we will be following the new stable release policy[1]
> > which will move us to an annual release schedule.
> >
> > Thank you everyone for your continued support of the KiCad project.
> > Hopefully the version 6 release will go reasonably smoothly and we can
> > get started on version 7 in 2022.
> >
> > Cheers,
> >
> > Wayne
> >
> > [1]: https://dev-docs.kicad.org/en/rules-guidelines/release-policy/
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Note to packagers: new data dependency for KiCad PCM

[Jon Evans]

Hi Carsten,

Sorry I was not clear, yes this is a dependency for the main binaries so it
should go in the main package if you have multiple packages.

Best,
Jon

On Mon, Nov 8, 2021 at 2:53 AM Carsten Schoenert 
wrote:

> Hello Jon,
>
> Am 08.11.21 um 03:30 schrieb Jon Evans:
> > Hi all,
> >
> > We just turned the plugin and content manager (PCM) feature on for all
> > users.
> >
> > To work properly, this feature needs an additional directory packaged:
> >
> > $KICAD_DATA/schemas
> >
> > If your packaging scripts already grab everything inside $KICAD_DATA,
> > you should not need to do anything. If you manually package each
> > subdirectory (resources, scripting, template, etc) then please add the
> > schemas directory to the list.
>
> which package should contain this new folder?
> I guess the KiCad main application, am I right?
>
> --
> Regards
> Carsten
>
> ___
> Mailing list: https://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] Note to packagers: new data dependency for KiCad PCM

[Jon Evans]

Hi all,

We just turned the plugin and content manager (PCM) feature on for all
users.

To work properly, this feature needs an additional directory packaged:

$KICAD_DATA/schemas

If your packaging scripts already grab everything inside $KICAD_DATA, you
should not need to do anything. If you manually package each subdirectory
(resources, scripting, template, etc) then please add the schemas directory
to the list.

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

[Kicad-developers] Ending support for macOS 10.14

[Jon Evans]

Hi all,

As described in more detail in a forum thread[1], Homebrew no longer
packages opencascade for macOS 10.14.  As opencascade is a requirement for
KiCad, this means that we can no longer build on 10.14 and therefore cannot
support 10.14 for the 5.99 nightly builds or the upcoming 6.0 stable
release.

Apple is coincidentally ending support for 10.14 on November 30.  Given
that we don't support KiCad on operating systems that are no longer
supported by their maintainers, we would move 10.14 into the "unsupported,
but may still function" category at that point anyway.

If anyone is motivated to provide continued support for 10.14, you would
need to figure out a way to get kicad-mac-builder to work with opencascade
on 10.14 (either by providing a homebrew bottle, or by building the
opencascade dependency outside homebrew).  At this time, I don't think any
of the lead devs plan to work on this.

Please speak up if anyone wants to take on the effort to continue 10.14
support.  If not, we can update the website accordingly.

-Jon

[1] https://forum.kicad.info/t/macos-nightly-build-situation/30154/8
___
Mailing list: https://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] ngspice-35

[Jon Evans]

Thanks Holger, I tested a fix and it works now (6b48825a)

Updated
https://gitlab.com/kicad/packaging/kicad-mac-builder/-/merge_requests/344
to bump to ngspice-35.
I guess Mark can do the same in vcpkg for the Windows build.

-Jon

On Mon, Aug 9, 2021 at 1:50 PM Holger Vogt  wrote:

> Hi Jon,
>
> this would require a patch in KiCad:
>
> The version info is no longer available in a config.h file. It is now
> defined in sharedspice.h as preprocessor variable NGSPICE_PACKAGE_VERSION.
>
> Holger
>
>
>
> ___
> Mailing list: https://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] ngspice-35

[Jon Evans]

Hi Holger,

Thanks for the notice.  I tested this on macOS and had no trouble compiling
or running, although KiCad does not properly display the ngspice version
anymore (probably a KiCad bug)

-Jon

On Sun, Aug 8, 2021 at 4:14 PM Holger Vogt  wrote:

> ngspice-35 is available.
>
> Please see https://sourceforge.net/p/ngspice/ngspice/ci/master/tree/
>
> Holger
>
> ___
> Mailing list: https://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] old ngspice in 599 macOS nightly

[Jon Evans]

Hi Holger,

Last time Adam and I looked at this, I could not build ngspice-34 and
kicad-nightly on macOS because of the issue with config.h changing.

I have not tried recently; Adam, have you?

-Jon

On Wed, Jul 21, 2021 at 11:14 AM Holger Vogt  wrote:

> The nightly for macOS from July 20th is delivered with ngspice-31.
> (
> https://kicad-downloads.s3.cern.ch/osx/nightly/kicad-unified-20210720-030631-75190370dd.dmg
> )
>
> This ngspice version is fairly outdated, ngspice-34 is the current
> version (with several improvements in the Eeschema/ngspice cooperation).
>
> Might it be possible to upgrade the nigthly version to use ngspice-34?
> Is there any suport from ngspice side required?
>
> Holger
>
>
> ___
> Mailing list: https://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] Any pointers to speed up the build

[Jon Evans]

I think from your screenshots in the issue you're working on that you're on
Windows -- I can second that using Visual Studio / MSVC is significantly
faster than mingw.

Also, if you are testing something over and over in eeschema or pcbnew,
just building that one target and running from the build directory is
faster than running "make install" every time.

This does come with some caveats (see the dev docs about
KICAD_RUN_FROM_BUILD_DIR) but if you are making a minor change and
rebuilding frequently, it's definitely the way to go in my opinion.

-Jon

On Sun, Jul 11, 2021 at 8:59 AM Andrew Lutsenko 
wrote:

> Few things that can help
> 1. Disable qa tests build if you don't need them
> 2. Disable python scripting if you don't need it
> 3. Use MSVC if you are on windows. Their linker is a LOT faster than gcc.
> 4. Use more powerful hardware. Those steps take <10s on my pc but it's a
> 12 core 3900x.
>
> Best,
> Andrew
>
> On Sun, Jul 11, 2021 at 5:35 AM Pradeepa Senanayake <
> pradeepa@gmail.com> wrote:
>
>> Hello Team,
>>
>> I don't know whether this is normal, but even for a small change, the
>> application takes ~ 15 mins to build.
>>
>> $ time make -j 5 install
>> ...
>> ...
>> real14m51.815s
>> user0m8.017s
>> sys 0m15.641s
>>
>> The most time is spent in the linking process. (Following steps)
>>
>> [ 98%] Linking CXX shared module _pcbnew.kiface
>> [ 98%] Built target pcbnew_kiface
>> [ 98%] Creating python's pcbnew native module _pcbnew.pyd for command
>> line use.
>> [ 98%] Built target pcbnew
>> [ 98%] Linking CXX executable qa_pcbnew_tools.exe
>> [ 98%] Linking CXX executable qa_pcbnew.exe
>> [ 98%] Built target pcbnew_python_module
>> [ 98%] Built target qa_pcbnew_tools
>> [100%] Built target qa_pcbnew
>>
>> Is there a way to speed this up?
>>
>> Thanks!
>> Best Regards,
>> Pradeepa Senanayake.
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Help needed to configure gdb

[Jon Evans]

 gdb ./kicad/kicad is starting KiCad from the build directory.

This isn't a fully-supported way of debugging KiCad, but if you want to do
this, you must set the environment variable

KICAD_RUN_FROM_BUILD_DIR=1

Alternatively, since you are running `make install` above, you can use gdb
to debug KiCad at the installed location, rather than inside the build
directory.

This will probably be a more reliable mechanism.

-Jon

On Wed, Jul 7, 2021 at 9:24 AM Pradeepa Senanayake 
wrote:

> Hello All,
>
> Sorry for the long mail.
>
> I'm trying to debug one of my changes using gdb and I've run into a
> roadblock.
>
> This is what I did so far,
>
> >> Built KiCAD using following commands
>
> cmake -DCMAKE_BUILD_TYPE=Debug
>   -G "MSYS Makefiles"
>   -DCMAKE_PREFIX_PATH=/mingw64
>-DCMAKE_INSTALL_PREFIX=/mingw64
>-DDEFAULT_INSTALL_PATH=/mingw64
>-DOCC_INCLUDE_DIR=/mingw64/include/opencascade
>-DPYTHON_INCLUDE_DIR=/mingw64/include/python3.8
>../../
> make -j 4 install
>
> >> Started gdb using the following command
>
> $: gdb ./kicad/kicad
>
> ...
> ...
> Reading symbols from ./kicad/kicad.exe...
> (gdb) run
> Starting program:
> I:\msys64\home\Pradeepa\kicad-source\build\debug\kicad\kicad.exe
> [New Thread 16296.0x41b0]
> [New Thread 16296.0x3e0c]
> [New Thread 16296.0x2130]
> Python path configuration:
>   PYTHONHOME = (not set)
>   PYTHONPATH = (not set)
>   program name = 'python3'
>   isolated = 0
>   environment = 1
>   user site = 1
>   import site = 1
>   sys._base_executable =
> 'I:/msys64/home/Pradeepa/kicad-source/build/debug/kicad/kicad.exe'
>   sys.base_prefix = 'D:/a/_temp/msys/msys64/mingw64'
>   sys.base_exec_prefix = 'D:/a/_temp/msys/msys64/mingw64'
>   sys.executable =
> 'I:/msys64/home/Pradeepa/kicad-source/build/debug/kicad/kicad.exe'
>   sys.prefix = 'D:/a/_temp/msys/msys64/mingw64'
>   sys.exec_prefix = 'D:/a/_temp/msys/msys64/mingw64'
>   sys.path = [
> 'D:/a/_temp/msys/msys64/mingw64/lib/python38.zip',
> 'D:/a/_temp/msys/msys64/mingw64/lib/python3.8',
> 'D:/a/_temp/msys/msys64/mingw64/lib/python3.8',
> 'D:/a/_temp/msys/msys64/mingw64/lib/lib-dynload',
>   ]
> Could not find platform independent libraries 
> Could not find platform dependent libraries 
> Consider setting $PYTHONHOME to [:]
> Fatal Python error: init_fs_encoding: failed to get the Python codec of
> the filesystem encoding
> Python runtime state: core initialized
> ModuleNotFoundError: No module named 'encodings'
>
> Current thread 0x3154 (most recent call first):
> 
> warning: Fatal Python error:
> warning: failed to get the Python codec of the filesystem encoding
> warning:
> [Thread 16296.0x3e0c exited with code 1]
> [Thread 16296.0x2130 exited with code 1]
> [Thread 16296.0x41b0 exited with code 1]
> [Inferior 1 (process 16296) exited with code 01]
> (gdb)
>
> I've set the PYTHONHOME to /mingw64
>
> Now I can launch KiCad in gdb. However, it now gives many errors,
>
> Ex: can't open file
> I:\msys64\home\Pradeepa\kicad-source\build\debug\share\kicad\resources\images.tar.gz
>
> I feel that it's something to do with paths, however, it's hard to figure
> out without knowing how everything fits together.
>
> Can someone please give me a hand?
>
> Thanks!
> Best Regards,
> Pradeepa Senanayake.
> ___
> Mailing list: https://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] For those wondering about KiCad version 5.99.0 in Debian unstable...

[Jon Evans]

Hi Carsten,

I was reminded of this thread because of this forum post:
https://forum.kicad.info/t/how-install-kicad-6-x-on-debian/30034/4

Is the fact that there is a 6.0.0 tag on experimental also related to this
issue with versioning?

Best,
Jon

On Sun, Apr 11, 2021 at 2:25 AM Carsten Schoenert 
wrote:

> it's not really a version 5.99.0.
>
> I made a mistake last week while preparing a current snapshot of all
> relevant KiCad parts and the kicad package was of course intended for
> uploading to the distribution experimental but was pushed into
> unstable/sid due stupidity of me.
>
> To fix this error I needed to upload a greater version into the archive
> than the previous upload as DAK (the Debian Archive Kit) is checking for
> this condition and will reject the upload otherwise, the Debian system
> is only supporting upgrades and no downgrades.
> Another option would have been to use a epoch, that prefix with a colon
> before the typical version number string. E.g. *1:*5.1.9 could I've been
> used.
>
> But introducing epochs need to go through consensus on the list
> debian-devel as these are often avoidable and not really needed. And I
> think this here is a case there no need for an epoch is required and I
> have chosen to simply increase the version numbering from a POV of DAK
> and created a version 5.99.0+really5.1.9.
>
> The underlying source is still 5.1.9.
>
> I need to stay with this schema until 6.x will get released (6.x is
> greater than 5.99.x), even for the backported versions. I'm really not
> proud about the mistake I've made but it's happen. :-(
>
> This will also have effect for Ubuntu and their downstreams as the PPA
> version will also became less than 5.99.0+really once the Debian
> version(s) will hit the Ubuntu archive and users wouldn't be able to
> install packages from PPA archives in case they have previously
> installed kicad package from the Ubuntu archive.
>
> There are two solution for this case people want to use the PPA versions
> of kicad.
>
> Option A:
>  - The PPA versioning doesn't adopt the version schema from Debian
>
> People can't have installed kicad packages from the Ubuntu archive
> before, if they have installed the kicad package from Ubuntu they need
> to be removed first!
>
> Option B
>  - The PPA archive is also using the versioning schema from Debian
>
> In this case users doesn't have to do anything than to add the PPA
> entries as it's already done yet right now.
>
> My suggestion is to do the latter, so the names, versions and behaviour
> will stay the same on all Debian based distributions.
>
> This all is only relevant for the non nightly packages as this is using
> a different package name!
>
> --
> Regards
> Carsten
>
> ___
> Mailing list: https://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] Coding style Policy (https://dev-docs.kicad.org/en/rules-guidelines/code-style/)

[Jon Evans]

https://dev-docs.kicad.org/en/rules-guidelines/code-style/ has been updated
to clarify this point.

-Jon

On Mon, Jul 5, 2021 at 12:32 PM Jon Evans  wrote:

> Lines which only contain braces do count as a blank line in this context.
> We should clarify this in the style guide.
>
> Best,
> Jon
>
> On Mon, Jul 5, 2021 at 2:20 AM Markus Bonk 
> wrote:
>
>> Hi,
>>
>>
>>
>> In my opinion there may be issues with the examples in the KiCAD coding
>> style doc relating to 4.2.3 Control Statements.
>>
>> 4.2.3 requires one blank line before and after the statement block.
>> Example 4.7 & 4.8 (for example) has missing opening and closing blank lines
>> for the while and if blocks.
>>
>>
>>
>> Do lines which only contain braces count as a blank line?
>>
>>
>>
>> The example for 10. Function CharAt also violates 4.2.3
>>
>>
>>
>> Markus
>>
>>
>>
>>
>>
>> --
>>
>> *Markus Bonk*
>> Senior Software Engineer
>>
>> Clarita-Bernhard-Str. 18
>> 81249 München
>> Germany
>> markus_b...@3dconnexion.com <%7BE-mail%7D>
>> www.3dconnexion.com
>>
>> Geschäftsführer: Antonio Pascucci
>> Sitz der Gesellschaft: München
>> Registergericht: München HRB 99232
>>
>> This email and any files transmitted with are from 3Dconnexion GmbH. The
>> contents of this email and any attachments are confidential to the intended
>> recipient. They may not be disclosed to or used by or copied in any way by
>> anyone other than the intended recipient. If this email is received in
>> error, please contact 3Dconnexion GmbH by calling +49 89 8974542-0 and then
>> delete it. Please note that neither 3Dconnexion GmbH nor the sender accepts
>> any responsibility for viruses and it is your responsibility to scan or
>> otherwise check this email and any attachments. Any opinion expressed in
>> this email are those of the individual and not necessarily those of
>> 3Dconnexion GmbH.
>> 3Dconnexion GmbH processes and stores for commercial purposes your
>> personal data, collected upon your consent, in accordance with its privacy
>> policy available at https://www.3dconnexion.eu/privacy.html, which has
>> been drafted in accordance with Regulation (EU) no. 679/2016 and all
>> applicable local data protection laws and regulations of the countries
>> where the company operates. To revoke your consent or exercise all your
>> rights with regards to personal data, please contact us at
>> priv...@3dconnexion.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
>>
>
___
Mailing list: https://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] Coding style Policy (https://dev-docs.kicad.org/en/rules-guidelines/code-style/)

[Jon Evans]

Lines which only contain braces do count as a blank line in this context.
We should clarify this in the style guide.

Best,
Jon

On Mon, Jul 5, 2021 at 2:20 AM Markus Bonk 
wrote:

> Hi,
>
>
>
> In my opinion there may be issues with the examples in the KiCAD coding
> style doc relating to 4.2.3 Control Statements.
>
> 4.2.3 requires one blank line before and after the statement block.
> Example 4.7 & 4.8 (for example) has missing opening and closing blank lines
> for the while and if blocks.
>
>
>
> Do lines which only contain braces count as a blank line?
>
>
>
> The example for 10. Function CharAt also violates 4.2.3
>
>
>
> Markus
>
>
>
>
>
> --
>
> *Markus Bonk*
> Senior Software Engineer
>
> Clarita-Bernhard-Str. 18
> 81249 München
> Germany
> markus_b...@3dconnexion.com <%7BE-mail%7D>
> www.3dconnexion.com
>
> Geschäftsführer: Antonio Pascucci
> Sitz der Gesellschaft: München
> Registergericht: München HRB 99232
>
> This email and any files transmitted with are from 3Dconnexion GmbH. The
> contents of this email and any attachments are confidential to the intended
> recipient. They may not be disclosed to or used by or copied in any way by
> anyone other than the intended recipient. If this email is received in
> error, please contact 3Dconnexion GmbH by calling +49 89 8974542-0 and then
> delete it. Please note that neither 3Dconnexion GmbH nor the sender accepts
> any responsibility for viruses and it is your responsibility to scan or
> otherwise check this email and any attachments. Any opinion expressed in
> this email are those of the individual and not necessarily those of
> 3Dconnexion GmbH.
> 3Dconnexion GmbH processes and stores for commercial purposes your
> personal data, collected upon your consent, in accordance with its privacy
> policy available at https://www.3dconnexion.eu/privacy.html, which has
> been drafted in accordance with Regulation (EU) no. 679/2016 and all
> applicable local data protection laws and regulations of the countries
> where the company operates. To revoke your consent or exercise all your
> rights with regards to personal data, please contact us at
> priv...@3dconnexion.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
>
___
Mailing list: https://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] Experience compiling latest HEAD

[Jon Evans]

Hi Ruth,

You can build the nightly flatpak (with wx 3.1) by grabbing this repository
and following the instructions in the readme:

https://gitlab.com/kicad/packaging/kicad-flatpak/kicad-nightly-flatpaks/kicad-nightly-flatpak

Johannes can probably answer any detailed questions better than I, but I
did test this a while ago and it worked.

The problem of dependency management on Linux would not be solved by
switching to Qt.  It's why things like flatpak have been created.
Personally I think to get the best experience with KiCad, one should use
Flatpak on Linux (if not building everything from source) because KiCad
can't solve the issues with the way Linux packaging works that mean that
many distros will not make wxWidgets 3.1 available, but we can at least
provide 3.1 on any systems where the dependencies are under our control
(Windows, Mac, Flatpak)

Best,
Jon

On Tue, Jun 29, 2021 at 9:15 AM Ruth Ivimey-Cook  wrote:

>
> On 29/06/2021 12:39, Jeff Young wrote:
> > Windows and Mac are single platforms, so the KiCad team builds those.
> We also build the Linux flatpak, which is statically linked (to 3.1).
>
> Except that the flatpak I installed yesterday is of version 5.1.10 and
> that one at least is linked to wx 3.0. If there is another version of
> kicad available as a flatpak I am unaware of it.
>
> I need (because of the new lib formats) a 5.99 linked to wx 3.1.
>
> I did try to self-compile, but the DRI linkage stuff broke. I still
> don't know why.
>
> Could the team consider making a flatpak of kicad-nightly available,
> linked to wx 3.1.x (not necessarily latest), and document on the
> relevant page how to install and use it for those like me who are unused
> to the flatpak?
>
>
> > It’s all the Linux distros that we can’t do much about.
> >
> >> I'm not saying it's ideal to use the possibly broken -dev version of
> wx, but IMO it is worse to use the actually broken "stable" version of it
> > He he… yeah, that about sums up the state of wxWidgets. ;)
>
> I presume KiCad 6 will be released after wx 3.2 is released (stated by
> their releases page as 'hopefully in September 2021').
>
> I personally feel the project would be much better off using Qt because
> it's a far better supported and designed framework, but I guess that's a
> question for another era!
>
> Ruth
>
>
> >
> > Cheers,
> > Jeff.
> >
> >
> >> On 29 Jun 2021, at 11:44, Ruth Ivimey-Cook  wrote:
> >>
> >>
> >>> wxwidget 3.1 is the development version for the upcoming stable version
> >>> 3.2 which possible breaks the API/ABI with every new version that is
> >>> getting released. That makes this software breaking other software too
> >>> often and by this unfit to get introduced into Debian unstable, it
> >>> simply make to less sense.
> >> Despite this, both the Windows and MacOS builds are using wx 3.1,
> somehow or other
> >>
> >> I'm not saying it's ideal to use the possibly broken -dev version of
> wx, but IMO it is worse to use the actually broken "stable" version of it.
> >>
> >> If needed, select a good-enough build of wx3.1 from the repo I
> referenced and link kicad statically to it, so there can be no pollution of
> other apps.
> >>
> >> Ruth
> >>
> >> --
> >>
> >> Tel: 01223 414180
> >> Blog: http://www.ivimey.org/blog
> >> LinkedIn: http://uk.linkedin.com/in/ruthivimeycook/
> >>
> >>
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to : kicad-developers@lists.launchpad.net
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> More help   : https://help.launchpad.net/ListHelp
>
> --
> Software Manager & Engineer
> Tel: 01223 414180
> Blog: http://www.ivimey.org/blog
> LinkedIn: http://uk.linkedin.com/in/ruthivimeycook/
>
>
> ___
> Mailing list: https://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] Fatal Python error: failed to get the Python codec of the filesystem encoding

[Jon Evans]

Please see https://dev-docs.kicad.org/en/build/windows-msvc/ at the bottom,
the "running and debugging" section.

Now that Python is required, you must tell KiCad how to find Python when
running from Visual Studio.

The options are to set the environment variables as explained on that page,
or else to copy Python into the appropriate relative path to the place
where you are having Visual Studio "install" to.

Best,
Jon

On Wed, Jun 23, 2021 at 9:41 AM Markus Bonk 
wrote:

> Hi
>
> I have built pcbnew.exe x64-Debug with vs2019 16.10.2 KiCAD commit
> 00b4134eb827 + some changes I am doing and am getting the above message on
> startup.
>
> I have no idea what to do to resolve the issue and no idea what code is
> causing it: no exceptions thrown to help debug.
>
> Typing in Python in cmd results in.
> Python 3.9.1 (tags/v3.9.1:1e5d33e, Dec  7 2020, 17:08:21) [MSC v.1927 64
> bit (AMD64)] on win32
>
> Can anyone point me in the right direction?
>
> -Markus
>
>
> Markus Bonk
> Senior Software Engineer
>
> 3Dconnexion GmbH
> Clarita-Bernhard-Str. 18
> 81249 München
> Germany
>
>
>
> markus_b...@3dconnexion.com
> www.3dconnexion.com
>
> Geschäftsführer: Antonio Pascucci
> Sitz der Gesellschaft: München
> Registergericht: München HRB 99232
>
> This email and any files transmitted with are from 3Dconnexion GmbH. The
> contents of this email and any attachments are confidential to the intended
> recipient. They may not be disclosed to or used by or copied in any way by
> anyone other than the intended recipient. If this email is received in
> error, please contact 3Dconnexion GmbH by calling +49 89 8974542-0 and then
> delete it. Please note that neither 3Dconnexion GmbH nor the sender accepts
> any responsibility for viruses and it is your responsibility to scan or
> otherwise check this email and any attachments. Any opinion expressed in
> this email are those of the individual and not necessarily those of
> 3Dconnexion GmbH.
> 3Dconnexion GmbH processes and stores for commercial purposes your
> personal data, collected upon your consent, in accordance with its privacy
> policy available at https://www.3dconnexion.eu/privacy.html, which has
> been drafted in accordance with Regulation (EU) no. 679/2016 and all
> applicable local data protection laws and regulations of the countries
> where the company operates. To revoke your consent or exercise all your
> rights with regards to personal data, please contact us at
> priv...@3dconnexion.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
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Python 3 now required

[Jon Evans]

The option KICAD_SCRIPTING_PYTHON3 doesn't even exist anymore.  I
recommend that people who are having issues get rid of your CMake
cache and start fresh, you have a lot of left over variables that may
be confusing things.  When we remove a variable from our CMake
configuration, many times it does not get removed from your cache.

On Wed, Jun 16, 2021 at 5:16 PM Nick Østergaard  wrote:
>
> You don't need to specify the type, but cmake will accept it as well and that 
> is how it is written by cmake in the CMakeCache.txt.
>
> On Wed, 16 Jun 2021 at 20:51, Kevin Cozens  wrote:
>>
>> On 2021-06-15 6:32 a.m., Marco Ciampa wrote:
>> > On Tue, Jun 15, 2021 at 12:22:42AM +0300, Eeli Kaikkonen wrote:
>> [snip]
>> >> That's where cmake UIs come handy. Try ccmake or cmake-gui (they are
>> [snip]
>> >
>> > Exactly, Kevin is right but using the cmake-gui command it was very easy
>> > to figure out how to change the variables to make it compile for me.
>>
>> I changed a symlink on my machine to make 'python' point to 'python3'. I
>> also rm'ed the build directory. I seem to be over the problem with it
>> finding the right version of Python when both 2.7 and 3.6 are installed.
>>
>> Now it complains that it can't find wxPython/Phoenix. AFAICT, that means I
>> need version 4 of wx. I only have 3 and the distro I'm using doesn't have
>> version 4 available so I can no longer build KiCAD v6. At least I solved the
>> previous problem. :)
>>
>> > //Build for Python 3 instead of 2 (default OFF).
>> > KICAD_SCRIPTING_PYTHON3:BOOL=ON
>>
>> Is this the new way of specifying whether a setting is enabled or not? You
>> need to specify the setting type and not just whether it is on or off? In
>> the past I just have just used =.
>>
>> --
>> 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
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] Python 3 now required

[Jon Evans]

I made this change[1] to try to fix the Ubuntu python3 situation

Does this not work for you if you start from a clean directory (get rid of
CMake cache)?

[1]
https://gitlab.com/kicad/code/kicad/-/commit/b345d979543d3f42add7e563e9881448b15d01bf

On Mon, Jun 14, 2021 at 5:00 PM Kevin Cozens  wrote:

> On 2021-06-14 4:34 p.m., Marco Ciampa wrote:
> > On Mon, Jun 14, 2021 at 03:43:54PM -0400, Jon Evans wrote:
> >> You should be able to override what is found by CMake by defining the
> >> PYTHON_EXECUTABLE variable in your cmake command line
> >
> > Gosh, shame on me, it was so simple!
>
> Not that simple. I tried passing -DPYTHON_EXECUTABLE=python3 and it still
> only finds 2.7. I tried it without the -D part. I have also tried it with
> and without a full path to python3. I even tried putting PYTHON_EXECUTABLE
> before 'cmake' on the line.
>
> How do you tell cmake which version of python you want to use?
>
>
> --
> 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
>
___
Mailing list: https://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] make install problems..

[Jon Evans]

I forget where the last conversation on that ended -- @Adam Wolf
 ?

The complication in offering multiple bundles has to do with notarization,
but I think after some changes that Adam is currently working on, it would
be possible to create the "barebones" images once again.

-Jon


On Mon, Jun 14, 2021 at 3:57 PM Jonatan Liljedahl 
wrote:

> Thanks! I will try this some day, but will use nightlies for now.
>
> PS. Would it be possible to have a barebones kicad nightly package
> that only includes the app(s) and not the footprints, symbols and 3D
> models? I already have those cloned separately. 1.3GB is quite a lot
> to download each time one want to try the latest build.
>
> On Mon, Jun 14, 2021 at 8:35 PM Jon Evans  wrote:
> >
> > Hi Jonatan,
> >
> > Using your system Python is no longer supported after the recent Python
> changes.
> >
> > Please see the instructions here:
> https://dev-docs.kicad.org/en/build/macos/
> > and obtain kicad-mac-builder for the dependencies here:
> > https://gitlab.com/kicad/packaging/kicad-mac-builder
> >
> > Adam has indicated that he thinks it may be possible to support system
> > Python in the future, but there are other higher priorities right now
> > to get 6.0 ready for release.
> >
> > Best,
> > Jon
> >
> > On Mon, Jun 14, 2021 at 2:32 PM Jonatan Liljedahl 
> wrote:
> > >
> > > So, it's been a while since I rebuilt so I updated my branch to
> > > current master and tried. Build went without errors, but make install
> > > fails:
> > >
> > > ...
> > > -- Analyzing
> app='/Users/lijon/Coding/kicad/build/install_py3/gerbview.app/Contents/MacOS/gerbview'
> > > -- bundle='/Users/lijon/Coding/kicad/build/install_py3/gerbview.app'
> > > --
> executable='/Users/lijon/Coding/kicad/build/install_py3/gerbview.app/Contents/MacOS/gerbview'
> > > -- valid='1'
> > > -- executable file 1:
> > >
> /Users/lijon/Coding/kicad/build/install_py3/gerbview.app/Contents/MacOS/gerbview
> > > -- executable file 2:
> > >
> /Users/lijon/Coding/kicad/build/install_py3/gerbview.app/Contents/MacOS/Python.framework/Versions/3.9/Resources/Python.app/Contents/MacOS/Python
> > > -- verified='0'
> > > -- info='external prerequisites found:
> > >
> f='/Users/lijon/Coding/kicad/build/install_py3/gerbview.app/Contents/MacOS/Python.framework/Versions/3.9/Resources/Python.app/Contents/MacOS/Python'
> > > external_prereqs='/usr/local/Cellar/python@3.9
> /3.9.4/Frameworks/Python.framework/Versions/3.9/Python'
> > > '
> > > --
> > > CMake Error at
> /Applications/CMake.app/Contents/share/cmake-3.20/Modules/BundleUtilities.cmake:1128
> > > (message):
> > >   error: verify_app failed
> > > Call Stack (most recent call first):
> > >
>  
> /Applications/CMake.app/Contents/share/cmake-3.20/Modules/BundleUtilities.cmake:995
> > > (verify_app)
> > >   gerbview/cmake_install.cmake:84 (fixup_bundle)
> > >   cmake_install.cmake:67 (include)
> > >
> > >
> > > make: *** [install] Error 1
> > >
> > > And trying to launch the app fails:
> > >
> > > lijon@lijon-mbp master_py3 % open ../install_py3/KiCad.app
> > > LSOpenURLsWithRole() failed with error -10810 for the file
> > > /Users/lijon/Coding/kicad/build/install_py3/KiCad.app.
> > >
> > > Any ideas?
> > > --
> > > /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
>
>
>
> --
> /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] Python 3 now required

[Jon Evans]

You should be able to override what is found by CMake by defining the
PYTHON_EXECUTABLE variable in your cmake command line

-Jon

On Mon, Jun 14, 2021 at 3:41 PM Marco Ciampa  wrote:
>
> On Fri, Jun 04, 2021 at 02:50:37PM -0400, Kevin Cozens wrote:
> > On 2021-06-04 1:34 p.m., Seth Hillbrand wrote:
> > > KiCad now officially only supports Python 3.
> > [snip]
> > > The current minimum Python version is 3.7 (due to a module test call we
> > > use) but we are looking at potentially supporting Python 3.6 if we can
> > > handle dynamic reloads.
> >
> > I have 2.7 and 3.6 installed. The build process only sees the 2.7 version of
> > Python and not my 3.6 version of Python.
> >
> > If 3.7 is required I won't be able to build it until I can update the
> > version of distro I run. Not easy for me to update my distro as someone
> > broke the update/upgrade process pretty much requiring a fresh install in
> > order.
>
> Same problem here (Ubuntu 20.04-64).
>
> How can I say to the builder to not consider the python 2.7 installed but
> only the 3.x version?
>
> --
>
> Saluton,
> Marco Ciampa
>
> ___
> Mailing list: https://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] make install problems..

[Jon Evans]

Hi Jonatan,

Using your system Python is no longer supported after the recent Python changes.

Please see the instructions here: https://dev-docs.kicad.org/en/build/macos/
and obtain kicad-mac-builder for the dependencies here:
https://gitlab.com/kicad/packaging/kicad-mac-builder

Adam has indicated that he thinks it may be possible to support system
Python in the future, but there are other higher priorities right now
to get 6.0 ready for release.

Best,
Jon

On Mon, Jun 14, 2021 at 2:32 PM Jonatan Liljedahl  wrote:
>
> So, it's been a while since I rebuilt so I updated my branch to
> current master and tried. Build went without errors, but make install
> fails:
>
> ...
> -- Analyzing 
> app='/Users/lijon/Coding/kicad/build/install_py3/gerbview.app/Contents/MacOS/gerbview'
> -- bundle='/Users/lijon/Coding/kicad/build/install_py3/gerbview.app'
> -- 
> executable='/Users/lijon/Coding/kicad/build/install_py3/gerbview.app/Contents/MacOS/gerbview'
> -- valid='1'
> -- executable file 1:
> /Users/lijon/Coding/kicad/build/install_py3/gerbview.app/Contents/MacOS/gerbview
> -- executable file 2:
> /Users/lijon/Coding/kicad/build/install_py3/gerbview.app/Contents/MacOS/Python.framework/Versions/3.9/Resources/Python.app/Contents/MacOS/Python
> -- verified='0'
> -- info='external prerequisites found:
> f='/Users/lijon/Coding/kicad/build/install_py3/gerbview.app/Contents/MacOS/Python.framework/Versions/3.9/Resources/Python.app/Contents/MacOS/Python'
> external_prereqs='/usr/local/Cellar/python@3.9/3.9.4/Frameworks/Python.framework/Versions/3.9/Python'
> '
> --
> CMake Error at 
> /Applications/CMake.app/Contents/share/cmake-3.20/Modules/BundleUtilities.cmake:1128
> (message):
>   error: verify_app failed
> Call Stack (most recent call first):
>   
> /Applications/CMake.app/Contents/share/cmake-3.20/Modules/BundleUtilities.cmake:995
> (verify_app)
>   gerbview/cmake_install.cmake:84 (fixup_bundle)
>   cmake_install.cmake:67 (include)
>
>
> make: *** [install] Error 1
>
> And trying to launch the app fails:
>
> lijon@lijon-mbp master_py3 % open ../install_py3/KiCad.app
> LSOpenURLsWithRole() failed with error -10810 for the file
> /Users/lijon/Coding/kicad/build/install_py3/KiCad.app.
>
> Any ideas?
> --
> /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

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

[Jon Evans]

If you use Docker, there is also a container for the docs build based on Debian:

https://gitlab.com/kicad/services/kicad-doc/-/blob/master/utils/docker/Dockerfile.kicad-doc-builder-base

Maybe this is also helpful for setting up a Fedora VM or Docker container

On Sun, May 30, 2021 at 3:00 PM Steven A. Falco  wrote:
>
> I'll have to spin up a VM to play with that.  I'll get back to you... :-)
>
> Steve
>
> On 5/30/21 2:34 PM, Jon Evans wrote:
> > You want this one: https://github.com/Mogztter/asciidoctor-web-pdf
> >
> > On Ubuntu I install it with "sudo npm i -g @asciidoctor/core 
> > asciidoctor-pdf"
> >
> > On Sun, May 30, 2021 at 2:33 PM Steven A. Falco  
> > wrote:
> >>
> >> I'm able to build the html pages, which is all we need for the nightlies, 
> >> but I am not able to build the pdf files.  I get an error:
> >>
> >>   Could NOT find ASCIIDOCTORPDF (missing: ASCIIDOCTORPDF_COMMAND)
> >>
> >> It looks like CMakeModules/FindASCIIDOCTORPDF.cmake wants a program called 
> >> "asciidoctor-web-pdf".
> >>
> >> Fedora has a package "rubygem-asciidoctor-pdf" which provides a program 
> >> called "asciidoctor-pdf".
> >>
> >> I don't know if "asciidoctor-pdf" is equivalent to "asciidoctor-web-pdf".  
> >> If it is, then perhaps the cmake file should accept either one.
> >>
> >>  Steve
> >>
> >> On 5/30/21 1:58 PM, Steven A. Falco wrote:
> >>> Thanks Jon.
> >>>
> >>> I'm running a test build now.  If it passes, I'll propose a patch for the 
> >>> README.  I'll also push the change to the nightly Fedora builds.
> >>>
> >>>   Steve
> >>>
> >>> On 5/30/21 1:51 PM, Jon Evans wrote:
> >>>> Hi Steve,
> >>>>
> >>>> As the readme notes, I have not yet updated the docs for Fedora or
> >>>> Manjaro/Arch as I don't use those distros and am not sure of the right
> >>>> incantations.
> >>>>
> >>>> If you can advise what should go into the README I'm happy to update it.
> >>>>
> >>>> Also, please let me know if you run into any snags building the docs
> >>>> with the new toolchain.
> >>>>
> >>>> Best,
> >>>> Jon
> >>>>
> >>>> On Sun, May 30, 2021 at 1:49 PM Steven A. Falco  
> >>>> wrote:
> >>>>>
> >>>>> The Fedora nightly build for doc failed because it wanted asciidoctor, 
> >>>>> but all it had was asciidoc.
> >>>>>
> >>>>> I believe I just need to change the "buildrequires" from:
> >>>>>
> >>>>> BuildRequires:  asciidoc
> >>>>>
> >>>>> to:
> >>>>>
> >>>>> BuildRequires:  rubygem-asciidoctor
> >>>>>
> >>>>> in the kicad-nightly-doc.spec file.
> >>>>>
> >>>>> However, I also noticed that the page 
> >>>>> https://gitlab.com/kicad/services/kicad-doc still calls for asciidoc, 
> >>>>> so that README.adoc should probably be updated too.
> >>>>>
> >>>>>   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] asciidoc

[Jon Evans]

You want this one: https://github.com/Mogztter/asciidoctor-web-pdf

On Ubuntu I install it with "sudo npm i -g @asciidoctor/core asciidoctor-pdf"

On Sun, May 30, 2021 at 2:33 PM Steven A. Falco  wrote:
>
> I'm able to build the html pages, which is all we need for the nightlies, but 
> I am not able to build the pdf files.  I get an error:
>
>  Could NOT find ASCIIDOCTORPDF (missing: ASCIIDOCTORPDF_COMMAND)
>
> It looks like CMakeModules/FindASCIIDOCTORPDF.cmake wants a program called 
> "asciidoctor-web-pdf".
>
> Fedora has a package "rubygem-asciidoctor-pdf" which provides a program 
> called "asciidoctor-pdf".
>
> I don't know if "asciidoctor-pdf" is equivalent to "asciidoctor-web-pdf".  If 
> it is, then perhaps the cmake file should accept either one.
>
> Steve
>
> On 5/30/21 1:58 PM, Steven A. Falco wrote:
> > Thanks Jon.
> >
> > I'm running a test build now.  If it passes, I'll propose a patch for the 
> > README.  I'll also push the change to the nightly Fedora builds.
> >
> >  Steve
> >
> > On 5/30/21 1:51 PM, Jon Evans wrote:
> >> Hi Steve,
> >>
> >> As the readme notes, I have not yet updated the docs for Fedora or
> >> Manjaro/Arch as I don't use those distros and am not sure of the right
> >> incantations.
> >>
> >> If you can advise what should go into the README I'm happy to update it.
> >>
> >> Also, please let me know if you run into any snags building the docs
> >> with the new toolchain.
> >>
> >> Best,
> >> Jon
> >>
> >> On Sun, May 30, 2021 at 1:49 PM Steven A. Falco  
> >> wrote:
> >>>
> >>> The Fedora nightly build for doc failed because it wanted asciidoctor, 
> >>> but all it had was asciidoc.
> >>>
> >>> I believe I just need to change the "buildrequires" from:
> >>>
> >>> BuildRequires:  asciidoc
> >>>
> >>> to:
> >>>
> >>> BuildRequires:  rubygem-asciidoctor
> >>>
> >>> in the kicad-nightly-doc.spec file.
> >>>
> >>> However, I also noticed that the page 
> >>> https://gitlab.com/kicad/services/kicad-doc still calls for asciidoc, so 
> >>> that README.adoc should probably be updated too.
> >>>
> >>>  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] asciidoc

[Jon Evans]

Hi Steve,

As the readme notes, I have not yet updated the docs for Fedora or
Manjaro/Arch as I don't use those distros and am not sure of the right
incantations.

If you can advise what should go into the README I'm happy to update it.

Also, please let me know if you run into any snags building the docs
with the new toolchain.

Best,
Jon

On Sun, May 30, 2021 at 1:49 PM Steven A. Falco  wrote:
>
> The Fedora nightly build for doc failed because it wanted asciidoctor, but 
> all it had was asciidoc.
>
> I believe I just need to change the "buildrequires" from:
>
> BuildRequires:  asciidoc
>
> to:
>
> BuildRequires:  rubygem-asciidoctor
>
> in the kicad-nightly-doc.spec file.
>
> However, I also noticed that the page 
> https://gitlab.com/kicad/services/kicad-doc still calls for asciidoc, so that 
> README.adoc should probably be updated too.
>
> 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] Build issue

[Jon Evans]

What version of ngspice are you using?

Sourceforge is down right now so I can't check the latest tree easily, but
in my cached version, the ControlledExit function signature in
sharedspice.h is using bool (not BOOL), and so is KiCad.

Is there some version of ngspice where those function signatures are BOOL
(aka int) not bool?

-Jon

On Tue, May 4, 2021 at 4:49 PM BERTRAND Joël 
wrote:

> Hello,
>
> I use KiCAD 5.99 as rolling release. For a few days, compilation
> aborts
> with :
>
> [ 32%] Building CXX object
> eeschema/CMakeFiles/eeschema_kiface_objects.dir/sim/ngspice.cpp.o
> /home/bertrand/git/kicad/eeschema/sim/ngspice.cpp: In member function
> ‘void NGSPICE::init_dll()’:
> /home/bertrand/git/kicad/eeschema/sim/ngspice.cpp:486:47: error: invalid
> conversion from ‘int (*)(int, bool, bool, int, void*)’ to ‘int (*)(int,
> BOOL, BOOL, int, void*)’ {aka ‘int (*)(int, int, int, int, void*)’}
> [-fpermissive]
>   486 | m_ngSpice_Init( , , ,
> NULL, NULL,
>   |   ^
>   |   |
>   |   int (*)(int, bool,
> bool, int, void*)
> /home/bertrand/git/kicad/eeschema/sim/ngspice.cpp:487:21: error: invalid
> conversion from ‘int (*)(bool, int, void*)’ to ‘int (*)(BOOL, int,
> void*)’ {aka ‘int (*)(int, int, void*)’} [-fpermissive]
>   487 | , this );
>   | ^~
>   | |
>   | int (*)(bool, int, void*)
> make[2]: ***
> [eeschema/CMakeFiles/eeschema_kiface_objects.dir/build.make:2846 :
> eeschema/CMakeFiles/eeschema_kiface_objects.dir/sim/ngspice.cpp.o] Erreur 1
> make[1]: *** [CMakeFiles/Makefile2:3021 :
> eeschema/CMakeFiles/eeschema_kiface_objects.dir/all] Erreur 2
> make: *** [Makefile:182 : all] Erreur 2
>
> I have built ngspice library from source (git).
>
> To be sure that this issue is reproductible, I have rebuild ngspice
> library and kicad from scratch with the same error.
>
> My workstation runs with Linux Debian/testing (up to date) with gcc
> 10.2.1. If I understand gcc error, compiler complains about mistake
> between BOOL (that seems to be 'int') and bool, but I don't known C++
> enough to fix it.
>
> Best regards,
>
> --
> KACHELHOFFER-BERTRAND Joël
> http://www.systella.fr
>
> ___
> Mailing list: https://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 with local Python3 etc

[Jon Evans]

I am not sure, but just FYI, the approach that Adam is investigating will
not involve wrangle-bundle in the end in order to use system Python.

For now I have decided to just use the Python 3.8 and wxpython builtby
kicad-mac-builder because it works, and hopefully eventually it will be
easy to use a different Python.

-Jon

On Thu, Apr 29, 2021 at 9:23 AM Jonatan Liljedahl 
wrote:

> Hi,
>
> So I continued to try building with my local python3 (installed via
> homebrew), and wxpython installed via pip.
>
> Running wrangle-bundle first gave this output:
>
> lijon@lijon-mbp master_py3 % wrangle-bundle --python-version 3.9 --fix
> ../install_py3/KiCad.app
> Looking for issues in ../install_py3/KiCad.app, and fixing what we can...
> ERROR: Dependency
> /usr/local/Cellar/python@3.9
> /3.9.4/Frameworks/Python.framework/Versions/3.9/Python
> of
> /Users/lijon/Coding/kicad/build/install_py3/KiCad.app/Contents/MacOS/Python.framework/Versions/3.9/Resources/Python.app/Contents/MacOS/Python
> isn't inside the app directory.
> ERROR: Dependency
> /usr/local/Cellar/python@3.9
> /3.9.4/Frameworks/Python.framework/Versions/3.9/Python
> of
> /Users/lijon/Coding/kicad/build/install_py3/KiCad.app/Contents/Frameworks/Python.framework/Versions/3.9/Resources/Python.app/Contents/MacOS/Python
> isn't inside the app directory.
> ERROR: Dependency /usr/local/opt/opencascade/lib/libTKVCAF.7.dylib of
>
> /Users/lijon/Coding/kicad/build/install_py3/KiCad.app/Contents/PlugIns/3d/libTKVCAF.7.dylib
> isn't inside the app directory.
> ERROR: Dependency /usr/local/opt/freeimage/lib/libfreeimage.dylib of
>
> /Users/lijon/Coding/kicad/build/install_py3/KiCad.app/Contents/PlugIns/3d/libTKVCAF.7.dylib
> isn't inside the app directory.
> ...snip...
> Issues found:
> Found dependency issues.
>
> Still no 'wx' inside the bundle, so pcbnew scripting console can't import
> wx.
> Tried this:
> cp -a /usr/local/lib/python3.9/site-packages/*
>
> /Users/lijon/Coding/kicad/build/install_py3/KiCad.app/Contents/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/
>
> And then re-ran wrangle-bundle, which now crashes:
>
> lijon@lijon-mbp master_py3 % wrangle-bundle --python-version 3.9 --fix
> ../install_py3/KiCad.app
> Looking for issues in ../install_py3/KiCad.app, and fixing what we can...
> Traceback (most recent call last):
>   File "/usr/local/bin/wrangle-bundle", line 8, in 
> sys.exit(main())
>   File
> "/usr/local/lib/python3.9/site-packages/dyldstyle/bundle_wrangler.py",
> line 505, in main
> handle_bundle(app_path, args.python_version, fix=True)
>   File
> "/usr/local/lib/python3.9/site-packages/dyldstyle/bundle_wrangler.py",
> line 166, in handle_bundle
> macho_types = utils.get_macho_types(app_path)
>   File "/usr/local/lib/python3.9/site-packages/dyldstyle/utils.py",
> line 231, in get_macho_types
> macho_type = get_macho_type(p)
>   File "/usr/local/lib/python3.9/site-packages/dyldstyle/utils.py",
> line 202, in get_macho_type
> magic = get_file_magic(path)
>   File "/usr/local/lib/python3.9/site-packages/dyldstyle/utils.py",
> line 151, in get_file_magic
> subprocess.check_output(cmd, stderr=subprocess.STDOUT)
> UnicodeDecodeError: 'utf-8' codec can't decode byte 0xd8 in position
> 194: invalid continuation byte
>
> Any ideas?
>
> On Thu, Apr 29, 2021 at 2:30 PM Jon Evans  wrote:
> >
> > Hi Jonatan,
> >
> > Adam and I have been bouncing ideas back and forth and he helped me get
> to a working setup, most recently with Seth's new_python branch but I think
> this should work with current master too.
> >
> > The key point is that we don't yet have a working way to use your system
> Python (but Adam has ideas on that and is working on it)
> >
> > So, the steps that worked for me are:
> >
> > 1) Use kicad-mac-builder to set up the dependencies.
> > As described in the readme:
> https://gitlab.com/kicad/packaging/kicad-mac-builder
> > run ./build.py --target setup-kicad-dependencies
> >
> > Note: this will install everything, including wxwidgets, wxpython, etc.
> There isn't currently a way to skip some if you already have them built
> outside kicad-mac-builder.
> > Really you and I mostly need Python out of this, as it's the only
> dependency that is hard to manage right now.
> >
> > 2) At the end of its run, build.py will spit out a lot of suggested
> CMake flags.  Save these, and then do a merge with your current CMake flags
> that you are building with.
> > In particular, you'll want to carry over the flags that point at the
> Python framework created by build.py.
> >
> > 3) Use A

Re: [Kicad-developers] Building with local Python3 etc

[Jon Evans]

Hi Jonatan,

Adam and I have been bouncing ideas back and forth and he helped me get to
a working setup, most recently with Seth's new_python branch but I think
this should work with current master too.

The key point is that we don't yet have a working way to use your system
Python (but Adam has ideas on that and is working on it)

So, the steps that worked for me are:

1) Use kicad-mac-builder to set up the dependencies.
As described in the readme:
https://gitlab.com/kicad/packaging/kicad-mac-builder
run ./build.py --target setup-kicad-dependencies

Note: this will install everything, including wxwidgets, wxpython, etc.
There isn't currently a way to skip some if you already have them built
outside kicad-mac-builder.
Really you and I mostly need Python out of this, as it's the only
dependency that is hard to manage right now.

2) At the end of its run, build.py will spit out a lot of suggested CMake
flags.  Save these, and then do a merge with your current CMake flags that
you are building with.
In particular, you'll want to carry over the flags that point at the Python
framework created by build.py.

3) Use Adam's wrangle-bundle script to fixup the installed bundle.
Obtain that from https://gitlab.com/adamwwolf/dyldstyle and install it (I
used the venv method suggested by Adam in the readme)
Run something like wrangle-bundle --python-version 3.8 --fix
path/to/KiCad.app

4) At this point, your build should work and make install should also work
(at least it did for me).  Please let us know if you don't have success

5) There are additional steps and complications if you want to run and
debug targets without first doing make install, as is possible on other
platforms.  I have figured out a workaround that makes this work, but it is
not awesome, so Adam and I are discussing an easier route.

We will update the documentation accordingly, things are just moving
quickly at the moment and we're trying to have them settle down in a way
that is easy to follow for developers.

Best,
Jon

On Thu, Apr 29, 2021 at 7:16 AM Jonatan Liljedahl 
wrote:

> I now tried manually copying my system site-packages into the bundle:
>
> cp -a /usr/local/lib/python3.9/site-packages/*
>
> /Users/lijon/Coding/kicad/build/install_py3/KiCad.app/Contents/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/
>
> Now when starting pcbnew, console gives a lot of:
>
> Class wxSTCPopupBaseView is implemented in both
>
> /Users/lijon/Coding/kicad/build/install_py3/KiCad.app/Contents/Frameworks/libwx_osx_cocoau-3.1.5.0.0.dylib
> (0x10f13c8d8) and
>
> /Users/lijon/Coding/kicad/build/install_py3/KiCad.app/Contents/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/wx/libwx_osx_cocoau_stc-3.1.5.0.0.dylib
> (0x1198ddbf8). One of the two will be used. Which one is undefined.
>
> And trying to open scripting console says:
>
> Traceback (most recent call last):
>   File "", line 5, in 
>   File
> "/Users/lijon/Coding/kicad/build/install_py3/KiCad.app/Contents/SharedSupport/scripting/kicad_pyshell/__init__.py",
> line 230, in makePcbnewShellWindow
> pyshell = PcbnewPyShell(parent, id=-1, title=INTRO)
>   File
> "/Users/lijon/Coding/kicad/build/install_py3/KiCad.app/Contents/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/wx/py/editor.py",
> line 265, in __init__
> EditorFrame.__init__(self, parent, id, title, pos,
>   File
> "/Users/lijon/Coding/kicad/build/install_py3/KiCad.app/Contents/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/wx/py/editor.py",
> line 29, in __init__
> frame.Frame.__init__(self, parent, id, title, pos, size, style)
>   File
> "/Users/lijon/Coding/kicad/build/install_py3/KiCad.app/Contents/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/wx/py/frame.py",
> line 69, in __init__
> wx.Frame.__init__(self, parent, id, title, pos, size, style)
> wx._core.PyNoAppError: The wx.App object must be created first!
>
> Hopefully this helps!
>
> On Thu, Apr 29, 2021 at 1:09 PM Jonatan Liljedahl 
> wrote:
> >
> > So, I updated my CMake and tweaked some variables, and now 'make
> > install' succeeds without "app verification failed". Also I can start
> > pcbnew without crashing. However, trying to open the scripting console
> > in pcbnew gives an error popup. The console reveals that it couldn't
> > import the 'wx' module.
> >
> > During make install, I saw this:
> >
> > cp: cannot overwrite directory
> >
> /Users/lijon/Coding/kicad/build/install_py3/KiCad.app/Contents/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages
> > with non-directory
> > /usr/local/Cellar/python@3.9
> /3.9.2_1/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages
> >
> > It's non-directory because it's a symlink. It points to
> > /usr/local/lib/python3.9/site-packages, which does contain the 'wx'
> > module.
> >
> > I've tried rerunning cmake with
> > -DPYTHON_SITE_PACKAGE_PATH=/usr/local/lib/python3.9/site-packages but
> > 

Re: [Kicad-developers] Compiling KiCAD 5.99 on Raspberry Pi (400)

[Jon Evans]

The patches are obsolete and will be removed from the documentation/source
tree.

On Wed, Apr 28, 2021 at 7:23 PM Eeli Kaikkonen 
wrote:

> On Thu, Apr 29, 2021 at 1:05 AM Knochi.de  wrote:
> >
> > I’m using the standard Raspberry OS which is “raspian buster”
> > libcurl4-gnutls-dev was the correct pick. So continuing with resolving
> dependencies for now.
>
> Nick reminded us that on .deb based systems there are often library
> packages with -dev in their name which are needed for building. They
> aren't visible in the binary package dependencies, but you can
> actually see all build time dependencies for KiCad in
> http://deb.debian.org/debian/pool/main/k/kicad/kicad_5.0.2+dfsg1-1.dsc
> (or
> http://deb.debian.org/debian/pool/main/k/kicad/kicad_5.1.9+dfsg1-1~bpo10+1.dsc
> in backports) so there's no need to guess. Whether all of them are
> available for the raspberry version of Debian, I don't know. These
> sources are authoritative because the Debian packaging system builds
> the KiCad packages using these dependencies. At least no build time
> dependency can be missing from them, although it's theoretically
> possible that some of them can't be satisfied on some port of the
> distro.
>
> > Next is how to apply patches. From my understanding I need to apply
> patches to certain files, plus the documentation says “platform dependent
> patches” so e.g. for boost I don’t need the “mingw” stuff.
> > Do I need to apply them at all? They are very old.
>
> I really don't know how these patches work or how they are applied,
> but there shouldn't be need to apply them manually. I have built KiCad
> on about 6 different Linux distros recently and haven't needed to
> patch anything.
>
> 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] UI only updates on mouse move

[Jon Evans]

Hi Markus,

I assume NL_3D_VIEWER_PLUGIN_IMPL is all your custom code as it doesn't
exist in KiCad's codebase.

Refreshing the display is a separate action that can be called when needed.
Some of the other actions do the refresh for you, but some do not.

It looks like you can send a EDA_3D_CONTROLLER::ZoomRedraw event to do the
refresh on the 3D viewer canvas

Best,
Jon

On Thu, Mar 25, 2021 at 10:32 AM Markus Bonk 
wrote:

> Hi,
>
>
>
> I am calling the following code:
>
>
>
> long NL_3D_VIEWER_PLUGIN_IMPL::SetActiveCommand( std::string commandId )
>
> {
>
> if( commandId.empty() )
>
> {
>
> return 0;
>
> }
>
>
>
> std::list actions = ACTION_MANAGER::GetActionList();
>
> TOOL_ACTION*context = nullptr;
>
>
>
> for( std::list::const_iterator it = actions.begin(); it
> != actions.end(); it++ )
>
> {
>
> TOOL_ACTION* action = *it;
>
> std::string  nm = action->GetName();
>
>
>
> if( commandId == nm )
>
> {
>
> context = action;
>
> }
>
> }
>
>
>
> if( context != nullptr )
>
> {
>
> wxWindow* parent = m_viewport3D->GetParent();
>
>
>
> // Only allow command execution if the window is enabled. i.e.
> there is not a modal dialog
>
> // currently active.
>
> if( parent->IsEnabled() )
>
> {
>
> TOOL_MANAGER* tool_manager = static_cast(
> parent )->GetToolManager();
>
>
>
> if( tool_manager == nullptr )
>
> {
>
> return navlib::make_result_code( navlib::navlib_errc::
> invalid_operation );
>
> }
>
>
>
> // Get the selection to use to test if the action is enabled
>
> SELECTION& sel =
> tool_manager->GetToolHolder()->GetCurrentSelection();
>
>
>
> bool runAction = true;
>
>
>
> if( const ACTION_CONDITIONS* aCond =
>
> tool_manager->GetActionManager()->GetCondition(
> *context ) )
>
> {
>
> runAction = aCond->enableCondition( sel );
>
> }
>
>
>
> if( runAction )
>
> {
>
> tool_manager->RunAction( *context, true );
>
> }
>
> }
>
> else
>
> {
>
> return navlib::make_result_code( navlib::navlib_errc::
> invalid_operation );
>
> }
>
> }
>
>
>
> return 0;
>
> }
>
>
>
> The issue I am experiencing is with tool_manager->RunAction( *context,
> true );
>
> If instead of true, false is specified then the action is not run until
> the 2D mouse is moved. Or if true then the action is run immediately,
> however the UI is not updated until the 2D mouse is moved (for example in
> the 3D-viewer when orthographic/perspective is toggled). This is on
> windows.
>
>
>
> Can anyone let me know what I need to do to get the UI to update as I
> would expect?
>
>
>
> Thanks
>
> -Markus
>
>
>
> --
>
> *Markus Bonk*
> Senior Software Engineer
>
> Clarita-Bernhard-Str. 18
> 81249 München
> Germany
> markus_b...@3dconnexion.com <%7BE-mail%7D>
> www.3dconnexion.com
>
> Geschäftsführer: Antonio Pascucci
> Sitz der Gesellschaft: München
> Registergericht: München HRB 99232
>
> This email and any files transmitted with are from 3Dconnexion GmbH. The
> contents of this email and any attachments are confidential to the intended
> recipient. They may not be disclosed to or used by or copied in any way by
> anyone other than the intended recipient. If this email is received in
> error, please contact 3Dconnexion GmbH by calling +49 89 8974542-0 and then
> delete it. Please note that neither 3Dconnexion GmbH nor the sender accepts
> any responsibility for viruses and it is your responsibility to scan or
> otherwise check this email and any attachments. Any opinion expressed in
> this email are those of the individual and not necessarily those of
> 3Dconnexion GmbH.
> 3Dconnexion GmbH processes and stores for commercial purposes your
> personal data, collected upon your consent, in accordance with its privacy
> policy available at https://www.3dconnexion.eu/privacy.html, which has
> been drafted in accordance with Regulation (EU) no. 679/2016 and all
> applicable local data protection laws and regulations of the countries
> where the company operates. To revoke your consent or exercise all your
> rights with regards to personal data, please contact us at
> priv...@3dconnexion.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
>
___
Mailing list: https://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] Contributing 3DMouse code to KiCAD

[Jon Evans]

> It makes me think the developers need to download a new copy of the
source tree to find out the differences.

Anyone (developers included) can see the differences in the GitLab web
interface when a merge request is created.

Of course, anyone can also check out the branch (with Git you do not need a
separate copy, you can just switch your local copy to a different branch)

-Jon

On Thu, Mar 25, 2021 at 1:42 PM Kevin Cozens  wrote:

> On 2021-03-25 10:18 a.m., Markus Bonk wrote:
> > I am able to start contributing code to implement navigation in the
> > 3D-Viewer and pcbnew.
> >
> > I am however already failing: I cannot create a branch on GitLab in the
> > KICAD project to add the feature.
>
> It has become more common with sites like GitHub and GitLab for you to
> fork
> the project, make your changes (to a branch), push the changes, then make
> a
> merge request.
>
> I've not dealt with merge requests on a project. It makes me think the
> developers need to download a new copy of the source tree to find out the
> differences.
>
> The older way of doing things was to file a bug report (or enhancement
> request in this case), and you can attach program patches to it that
> others
> can apply to their copies of the source tree.
>
> IIRC, KiCAD is now in feature freeze. I build KiCAD from source. I
> recently
> upgraded from a Space Navigator to a Space Mouse Pro. If you generate
> patch
> files I could apply them to my copy of v6 to help with initial testing and
> feedback.
>
> --
> 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
>
___
Mailing list: https://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] ngspice-34

[Jon Evans]

As Wayne points out, compatibility with older ngspice versions needs to be
considered, as well as Windows/vcpkg.

Since pkg-config apparently can't be used in the MSVC/vcpkg environment
during the kicad build, the only option I can think of is to generate a
version header as part of the ngspice vcpkg port itself.

So, there would be two different paths, one for Windows/MSVC and one for
other platforms.

-Jon

On Tue, Mar 23, 2021 at 11:28 AM Jonatan Liljedahl 
wrote:

> Ah, yes that sounds reasonable. I guess
> /CMakeModules/Findngspice.cmake could be modified to use pkg-config to
> get the version and paths needed?
>
> On Tue, Mar 23, 2021 at 4:20 PM Jon Evans  wrote:
> >
> > It sounds like the preference is to move away from using a config.h at
> all, which means all the KiCad packaging systems would need to update to
> use pkg-config to generate a header which can then be included in kicad's
> build process.  Is that correct?
> >
> > On Tue, Mar 23, 2021 at 11:15 AM Jonatan Liljedahl 
> wrote:
> >>
> >> If ngspice-35 is not ready to be tagged soon, perhaps Holger could
> >> make a branch called "ngspice-34-config-fix" or something, based on
> >> the ngspice-34 tag but only adding the simple fix of installing
> >> config.h into /include/ngspice/ instead? Then KiCad packagers could
> >> build from this branch? Unless some packages are not using locally
> >> built ngspice? Just some ideas of possible solutions...
> >>
> >> Cheers
> >>
> >> On Tue, Mar 23, 2021 at 3:22 PM Holger Vogt 
> wrote:
> >> >
> >> > The intention is to not at all install config.h.
> >> >
> >> > Installing it into ./include was a bug in ngspice-34 which has already
> >> > been removed in the current ngspice master branch.
> >> >
> >> > Perhaps you may make use of this bug by automatically moving config.h
> >> > from <...>/include/ to <...>/include/ngspice/ when building KiCad,
> >> > before we will have a solution without config.h in ngspice-35?
> >> >
> >> >
> >> > ___
> >> > Mailing list: https://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
>
>
>
> --
> /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] ngspice-34

[Jon Evans]

It sounds like the preference is to move away from using a config.h at all,
which means all the KiCad packaging systems would need to update to use
pkg-config to generate a header which can then be included in kicad's build
process.  Is that correct?

On Tue, Mar 23, 2021 at 11:15 AM Jonatan Liljedahl 
wrote:

> If ngspice-35 is not ready to be tagged soon, perhaps Holger could
> make a branch called "ngspice-34-config-fix" or something, based on
> the ngspice-34 tag but only adding the simple fix of installing
> config.h into /include/ngspice/ instead? Then KiCad packagers could
> build from this branch? Unless some packages are not using locally
> built ngspice? Just some ideas of possible solutions...
>
> Cheers
>
> On Tue, Mar 23, 2021 at 3:22 PM Holger Vogt 
> wrote:
> >
> > The intention is to not at all install config.h.
> >
> > Installing it into ./include was a bug in ngspice-34 which has already
> > been removed in the current ngspice master branch.
> >
> > Perhaps you may make use of this bug by automatically moving config.h
> > from <...>/include/ to <...>/include/ngspice/ when building KiCad,
> > before we will have a solution without config.h in ngspice-35?
> >
> >
> > ___
> > Mailing list: https://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
>
___
Mailing list: https://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] ngspice-34

[Jon Evans]

Bumping this thread as we don't seem to have a resolution yet.

The Windows vcpkg package works as there is still a config.h with the
version in the "visualc" directory.

But, MacOS doesn't build and I guess some Linux distros don't either.

Can we make pkg-config work for MacOS?

On Wed, Feb 3, 2021 at 1:45 PM Carsten Schoenert 
wrote:

> Am 03.02.21 um 13:03 schrieb jp charras:
> > OTOH, a version.h file is not a bad idea (read: for me a very good idea):
> >
> > at least the name is already a useful comment and it request only a very
> > few amount of work.
> >
> > Many tools use this trick (for instance opencascade, and most of other
> > tools we are using in Kicad), and one **big** advantage it works outside
> > the libtool stuff.
>
> For simple things like version detection pkg-config is already enough,
> no need for mostly incompatible hacks. Even different shells on the same
> host can behavior really unexpected.
>
> If you need to detect the version of ngspice you will need to do this
> this already before any build is started.
>
> > $ pkg-config --modversion ngspice
> > 33
> --
> Regards
> Carsten
>
> ___
> Mailing list: https://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] Current development status?

[Jon Evans]

Hi Rigo, here's my thoughts, other devs might have more to add:

> Most significantly, the separate icon set. While everyone is looking
forward to having this small feature, it's still kinda offending the term
feature "freeze". Though we weren't at string freeze, new features are
already annoying enough to translators. Are we getting other features
before V6 launch?

Several features were marked as feature freeze exceptions by the lead
development team, as they were deemed important features that were in
development and were being planned around for V6.  Support for dark color
themes was included here as lack of it makes KiCad pretty unusable in
desktop environments with dark window colors.

There are two other new features that are on the list of exceptions but
aren't in yet:

- Arc support in polygons
- New Python API

> Though we weren't at string freeze, new features are already annoying
enough to translators

The development team does not consider feature freeze to mean string
freeze, which is why we have that separate concept.  I certainly appreciate
the efforts of translators who work to keep up with development, but since
we are not at a string freeze, I think it would also be acceptable if some
translators wanted to just wait for the string freeze so they didn't have
to possibly do work twice.  Of course our use of Weblate now makes this a
little easier.

> Many (or most) critical/high priority issues are unresolved crashes,
usually hard to reproduce, without need-info tag. Are they slowing down the
version iteration?

Some of these may be missing a needed "need-info" tag.  Generally, crash
bugs in KiCad fall into two categories: ones that we can easily reproduce,
which are generally fixed very quickly, and ones that we cannot reproduce.
The latter are still important to fix if we have evidence that they are
caused by a KiCad problem (some hard-to-reproduce crash bugs can be caused
by various other system configuration things that are outside our
control).  Generally, as long as the reporter is able to consistently
reproduce the crash bug in a supported environment, we will hold the
release until all such bugs are fixed, but there may be exceptions.

If there are crash bugs that can't be reproduced by anyone (even outside
the development team) reliably enough to understand what causes them, it
might be a different story.  I think each situation has to be analyzed
independently.

> Will we get more frequent updates like 6.1 6.2 adding small features step
by step instead of doing all the things in one milestone?

Currently the plan is to stick with the major version numbering for new
features (i.e. going straight to 7.0) but to do fewer big features per
major version release.  We would all like to see more frequent releases.

-Jon

On Sat, Mar 20, 2021 at 11:02 AM RigoLigo RLC  wrote:

> I have a few questions about the current KiCad development.
>
> 1. new features after feature freeze?
>
> Most significantly, the separate icon set. While everyone is looking
> forward to having this small feature, it's still kinda offending the term
> feature "freeze". Though we weren't at string freeze, new features are
> already annoying enough to translators. Are we getting other features
> before V6 launch?
>
> 2. unresolved mysterious crashes
>
> Many (or most) critical/high priority issues are unresolved crashes,
> usually hard to reproduce, without need-info tag. Are they slowing down the
> version iteration? I mean, KiCad crashes are not new, not to mention those
> that are hard to tackle. Reducing data loss with autosave and such would be
> enough for current status of KiCad IMO. Of course crashes that have known
> reasons must be fixed. But what are we going to do with these mysterious
> crash issues? Wait till they're resolved before we launch RC1?
>
> 3. Development iteration...
>
> Currently KiCad will push big version leaps for all the features
> developers add into it. I know it's got reasons (difficulty of maintaining
> two branches, plugin API consistency) but a big leap requires a LONG wait.
> For OSS users this might not be a big problem but in Chinese community
> there are companies that use KiCad as alternatives. They dare not to use
> nightlies(even it's stable, it's not a stable release, and files are
> incompatible), but are still eager to have nice new features. Will we get
> more frequent updates like 6.1 6.2 adding small features step by step
> instead of doing all the things in one milestone?
>
> I'd like to know from you guys.
>
> Rigo
> ___
> Mailing list: https://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 : 

Re: [Kicad-developers] schematic.cpp includes sim/ngspice.h and consequently sharedspice.h

[Jon Evans]

I agree with Seth.  The longer a feature is part of KiCad, the more people
will refer to it in forum posts, tutorials, etc.   This feature has now
existed for plenty long enough for people to expect it.  If there are no
packaging reasons to do otherwise, I support it being included in all
builds.

-Jon

On Thu, Mar 18, 2021 at 10:49 PM Seth Hillbrand  wrote:

> I agree that this is one area where we can improve the user experience.
>
> By first-class, I mean only that it is an integral part of KiCad that we
> develop and support.  We are no longer in the testing phase where it would
> make sense to have a conditional compilation.
>
> -Seth
>
> On Thu, Mar 18, 2021 at 4:51 PM Mark Roszko  wrote:
>
>> You say it's first class but the spice gui needs alot of loving. The tool
>> framework is also ducktaped poorly into it.
>>
>> On Thu, Mar 18, 2021 at 7:14 PM Seth Hillbrand 
>> wrote:
>>
>>> Do we still need spice as a build option?  It would be nice to bring
>>> down the number of permutations out there and the SPICE simulator is really
>>> a first-class KiCad citizen nowadays.
>>>
>>> -S
>>>
>>> On Thu, Mar 18, 2021 at 4:04 PM Jon Evans  wrote:
>>>
>>>> Saving in the project file is fine, I just mean if you split out
>>>> NGSPICE_SIMULATOR_SETTINGS to a different file (not sim/ngspice.h) with no
>>>> dependencies on ngspice itself, the settings class can be built without
>>>> ngspice.
>>>>
>>>> On Thu, Mar 18, 2021 at 6:57 PM Wayne Stambaugh 
>>>> wrote:
>>>>
>>>>> I thought about that but in what context does a simulation make sense
>>>>> out side of a schematic or a netlist generated from a schematic?  I
>>>>> saved the ngspice simulator settings in the project file because that
>>>>> is
>>>>> the proper scope of the setting.  I really don't see a more logical
>>>>> place to save the setting.   I suppose I could split out the simulator
>>>>> settings code but it would be awkward at best.
>>>>>
>>>>> On 3/18/21 6:42 PM, Jon Evans wrote:
>>>>> > Wayne, I haven't checked this code carefully but I'd recommend
>>>>> building
>>>>> > the settings always, and moving the #ifdef to a different level (i.e.
>>>>> > make the settings not depend on ngspice)
>>>>> >
>>>>> > That way if the same settings files are shared between a build with
>>>>> > ngspice and a build without, they won't get thrown away.
>>>>> >
>>>>> > On Thu, Mar 18, 2021 at 6:37 PM Wayne Stambaugh <
>>>>> stambau...@gmail.com
>>>>> > <mailto:stambau...@gmail.com>> wrote:
>>>>> >
>>>>> > My bad.  I forgot the simulator was a build option so I will
>>>>> have to
>>>>> > #ifdef the offending settings code.
>>>>> >
>>>>> > - Wayne
>>>>> >
>>>>> > On 3/18/21 6:02 PM, Eeli Kaikkonen wrote:
>>>>> > > I have disabled ngspice in cmake settings but in a recent
>>>>> commit by
>>>>> > > Wayne #include , which in turn includes
>>>>> > > ngspice/sharedspice.h, was added to schematic.cpp which makes
>>>>> > > compilation fail apparently because I don't have ngspice at
>>>>> all.
>>>>> > >
>>>>> > > Eeli Kaikkonen
>>>>> > >
>>>>> > > ___
>>>>> > > Mailing list: https://launchpad.net/~kicad-developers
>>>>> > <https://launchpad.net/~kicad-developers>
>>>>> > > Post to : kicad-developers@lists.launchpad.net
>>>>> > <mailto:kicad-developers@lists.launchpad.net>
>>>>> > > Unsubscribe : https://launchpad.net/~kicad-developers
>>>>> > <https://launchpad.net/~kicad-developers>
>>>>> > > More help   : https://help.launchpad.net/ListHelp
>>>>> > <https://help.launchpad.net/ListHelp>
>>>>> > >
>>>>> >
>>>>> > ___
>>>>> > Mailing list: https://launchpad.net/~kicad-developers
>>>>> > <https://launchpad.net/~kicad-developers&

Re: [Kicad-developers] schematic.cpp includes sim/ngspice.h and consequently sharedspice.h

[Jon Evans]

Saving in the project file is fine, I just mean if you split out
NGSPICE_SIMULATOR_SETTINGS to a different file (not sim/ngspice.h) with no
dependencies on ngspice itself, the settings class can be built without
ngspice.

On Thu, Mar 18, 2021 at 6:57 PM Wayne Stambaugh 
wrote:

> I thought about that but in what context does a simulation make sense
> out side of a schematic or a netlist generated from a schematic?  I
> saved the ngspice simulator settings in the project file because that is
> the proper scope of the setting.  I really don't see a more logical
> place to save the setting.   I suppose I could split out the simulator
> settings code but it would be awkward at best.
>
> On 3/18/21 6:42 PM, Jon Evans wrote:
> > Wayne, I haven't checked this code carefully but I'd recommend building
> > the settings always, and moving the #ifdef to a different level (i.e.
> > make the settings not depend on ngspice)
> >
> > That way if the same settings files are shared between a build with
> > ngspice and a build without, they won't get thrown away.
> >
> > On Thu, Mar 18, 2021 at 6:37 PM Wayne Stambaugh  > <mailto:stambau...@gmail.com>> wrote:
> >
> > My bad.  I forgot the simulator was a build option so I will have to
> > #ifdef the offending settings code.
> >
> > - Wayne
> >
> > On 3/18/21 6:02 PM, Eeli Kaikkonen wrote:
> > > I have disabled ngspice in cmake settings but in a recent commit by
> > > Wayne #include , which in turn includes
> > > ngspice/sharedspice.h, was added to schematic.cpp which makes
> > > compilation fail apparently because I don't have ngspice at all.
> > >
> > > Eeli Kaikkonen
> > >
> > > ___
> > > Mailing list: https://launchpad.net/~kicad-developers
> > <https://launchpad.net/~kicad-developers>
> > > Post to : kicad-developers@lists.launchpad.net
> > <mailto:kicad-developers@lists.launchpad.net>
> > > Unsubscribe : https://launchpad.net/~kicad-developers
> > <https://launchpad.net/~kicad-developers>
> > > More help   : https://help.launchpad.net/ListHelp
> > <https://help.launchpad.net/ListHelp>
> > >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > <https://launchpad.net/~kicad-developers>
> > Post to : kicad-developers@lists.launchpad.net
> > <mailto:kicad-developers@lists.launchpad.net>
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > <https://launchpad.net/~kicad-developers>
> > More help   : https://help.launchpad.net/ListHelp
> > <https://help.launchpad.net/ListHelp>
> >
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] schematic.cpp includes sim/ngspice.h and consequently sharedspice.h

[Jon Evans]

Wayne, I haven't checked this code carefully but I'd recommend building the
settings always, and moving the #ifdef to a different level (i.e. make the
settings not depend on ngspice)

That way if the same settings files are shared between a build with ngspice
and a build without, they won't get thrown away.

On Thu, Mar 18, 2021 at 6:37 PM Wayne Stambaugh 
wrote:

> My bad.  I forgot the simulator was a build option so I will have to
> #ifdef the offending settings code.
>
> - Wayne
>
> On 3/18/21 6:02 PM, Eeli Kaikkonen wrote:
> > I have disabled ngspice in cmake settings but in a recent commit by
> > Wayne #include , which in turn includes
> > ngspice/sharedspice.h, was added to schematic.cpp which makes
> > compilation fail apparently because I don't have ngspice at all.
> >
> > 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
>
___
Mailing list: https://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] Packagers: proposed change to library search paths logic

[Jon Evans]

Hi all,

There is a proposal[1] to use the PATHS::GetStockDataPath() instead of
DEFAULT_INSTALL_PATH to set the base path for finding KiCad libraries.

This resolves to the KICAD_DATA CMake variable on Linux, and has
special-casing on Windows and MacOS to handle the packaging setup on those
platforms.

This would make it easier for packagers to set custom paths for things
without requiring the use of environment variables, as described in the MR.

I think this should be OK as we already depend on KICAD_DATA for other
things, but wanted to check to see if any packagers are concerned about
this.  It *should* result in no functional change, unless there is any
package that is customizing DEFAULT_INSTALL_PATH and isn't also setting
KICAD_DATA the same way.

Best,
Jon

[1] https://gitlab.com/kicad/code/kicad/-/merge_requests/727
___
Mailing list: https://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-msvc.r21621.b71ab01d-x86_64.exe AND kicad-msvc.r21619.2c3f9d30-x86_64.exe installs but does not start up-Windows reports as already running.

[Jon Evans]

If this is the first time you are running KiCad 5.99, or you erased your
settings directory, you may be hitting
https://gitlab.com/kicad/code/kicad/-/issues/7900 with that version.

If this is the case, try installing an older nightly (like go back a week
or so, just using the lite installer is fine) and try starting it up.  If
that works, you should be able to install the latest version again and have
it work.

-Jon

On Sat, Mar 13, 2021 at 10:26 AM Nick Østergaard  wrote:

> Please try to see if you can start it directly from the kicad.exe in the
> install location insread of the shortcuts.
>
> lør. 13. mar. 2021 16.22 skrev David :
>
>> I'm reporting this here as I am unable to provide any version information
>> as nothing starts up. This is reported as an incomplete report by the Kicad
>> bot on Gitlab.
>> Description
>>
>> kicad-msvc.r21621.b71ab01d
>> -x86_64.exe
>> AND kicad-msvc.r21619.2c3f9d30
>> -x86_64.exe
>> installs but does not start up-Windows reports as already running when
>> double-clicking on Kicad, eeschema or pcbnew. None of these applications
>> are listed in task manager. They have NOT been blocked by Comodo internet
>> security premium on my PC (any kicad application is normally sandboxed, and
>> I manually have to add to trusted applications).
>> Steps to reproduce
>>
>> 1.Install. 2.Double click on EESchema, PCBnew icons
>> KiCad Version
>>
>> Can not copy version info as applications will NOT start up. My Windows
>> version is Windows 10 2004 (OS Build 19041.867)
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Packaging note: new data file

[Jon Evans]

Great, thanks for testing, Steve!

On Thu, Mar 11, 2021 at 5:25 PM Steven A. Falco 
wrote:

> On 3/11/21 8:43 AM, Jon Evans wrote:
> > Hi all,
> >
> > As of 18037e2f, a new data file is generated during build that contains
> image resources for KiCad.
> >
> > This file should be installed to ${KICAD_DATA}/resources/images.tar.gz
> (So, something like /usr/share/kicad/resources/images.tar.gz on Linux).
> >
> > There is an install target for this in the cmake file now, so this
> *should* be done automatically, but I wanted to give a heads-up in case any
> of the nightly packages require manual modification when the build
> artifacts change.
>
> I tried a Fedora nightly build and the file is created in the correct
> place, so no changes are needed there.
>
> 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] Packaging note: new data file

[Jon Evans]

Hi all,

As of 18037e2f, a new data file is generated during build that contains
image resources for KiCad.

This file should be installed to ${KICAD_DATA}/resources/images.tar.gz (So,
something like /usr/share/kicad/resources/images.tar.gz on Linux).

There is an install target for this in the cmake file now, so this *should*
be done automatically, but I wanted to give a heads-up in case any of the
nightly packages require manual modification when the build artifacts
change.

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

Re: [Kicad-developers] build failure

[Jon Evans]

> As I said earlier, it links fine for me now. It might have been some
> combination of installing CommandLineTools via xcode-select and
> uninstalling and reinstalling OCC.

Well, I did those things too and was still having the same problem :(

I guess I can try blowing up homebrew and the tools/sdk and starting from
scratch.

-Jon

On Wed, Mar 10, 2021 at 7:59 AM Jonatan Liljedahl 
wrote:

> Hi,
>
> As I said earlier, it links fine for me now. It might have been some
> combination of installing CommandLineTools via xcode-select and
> uninstalling and reinstalling OCC. I did not force a 10.14 bottle.
>
> However, 'make install' still fails for me so I'm running kicad from
> the build dir (which works mostly). I think it might be the same issue
> as https://gitlab.com/kicad/code/kicad/-/issues/3718
>
> Would be great if we could find a fix for this..
>
> -- fixup_bundle
> --
>  app='/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/MacOS/kicad'
> --
>  
> libs='/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/_cvpcb.kiface;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/_eeschema.kiface;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/_gerbview.kiface;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/_pcb_calculator.kiface;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/_pcbnew.kiface;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/_pl_editor.kiface;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libs3d_plugin_idf.so;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libs3d_plugin_oce.so;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libs3d_plugin_vrml.so;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/sim/libngspice.0.dylib;/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/Frameworks/python/site-packages/_pcbnew.so'
> --   dirs=' /usr/local/opt/opencascade/lib'
> --   ignoreItems=''
> -- fixup_bundle: preparing...
> -- warning: embedded item does not exist
>
> '/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKVCAF.7.dylib'
> --
> warning: cannot resolve item '@loader_path/libTKVCAF.7.dylib'
>
>   possible problems:
> need more directories?
> need to use InstallRequiredSystemLibraries?
> run in install tree instead of build tree?
>
> CMake Error at
> /Applications/CMake.app/Contents/share/cmake-3.15/Modules/BundleUtilities.cmake:452
> (message):
>   otool -l failed: 1
>
>
>
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/objdump:
>   error: '@loader_path/libTKVCAF.7.dylib': No such file or directory
>
> Call Stack (most recent call first):
>
> /Applications/CMake.app/Contents/share/cmake-3.15/Modules/BundleUtilities.cmake:521
> (get_item_rpaths)
>
> /Applications/CMake.app/Contents/share/cmake-3.15/Modules/BundleUtilities.cmake:616
> (set_bundle_key_values)
>
> /Applications/CMake.app/Contents/share/cmake-3.15/Modules/BundleUtilities.cmake:939
> (get_bundle_keys)
>   kicad/cmake_install.cmake:101 (fixup_bundle)
>   cmake_install.cmake:67 (include)
>
> On Wed, Mar 10, 2021 at 3:48 AM Adam Wolf 
> wrote:
> >
> > I haven't seen that.  I can take a look at a bigger build log if you
> want.
> >
> > To be clear for others, I'm not advocating carrying around a 10.14
> > bottle of opencascade; this is troubleshooting in progress :)
> >
> > Adam
> >
> > On Tue, Mar 9, 2021 at 7:02 PM Jon Evans  wrote:
> > >
> > > Hi Jonatan,
> > >
> > > I hit the exact same issue (I'm also on 10.15), and after chatting
> with Adam about it, decided to try using the 10.14 bottle manually:
> > >
> > > Download
> https://bintray.com/homebrew/bottles/download_file?file_path=opencascade-7.5.0.mojave.bottle.tar.gz
> > >
> > > Install with:
> > >
> > > brew install -f --force-bottle opencascade-7.5.0.mojave.bottle.tar.gz
> > > brew link --overwrite opencascade
> > >
> > > After this, I am able to get past the opencascade link errors.
> > >
> > > I do have another error after this, which I haven't figured out yet:
> > >
> > > make[6]: *** No rule to make target
> `/usr/local/Cellar/cairo/1.16.0_3/lib/libcairo.dylib', needed by
> `kicad/KiCad.app/Contents/PlugIns/_eeschema.kiface'.  Stop.
> > >
> > > @Adam or anyone else, have you seen this before?
> > >
> > > -Jon
> > >
> > > On Sat, Mar 6, 2021 at 3:47 AM Jonatan Liljedahl 
> wrote:
> > >>
> > >> On Fri, Mar 5, 2021 at 8:45 P

Re: [Kicad-developers] build failure

[Jon Evans]

Hi Jonatan,

I hit the exact same issue (I'm also on 10.15), and after chatting with
Adam about it, decided to try using the 10.14 bottle manually:

Download
https://bintray.com/homebrew/bottles/download_file?file_path=opencascade-7.5.0.mojave.bottle.tar.gz

Install with:

brew install -f --force-bottle opencascade-7.5.0.mojave.bottle.tar.gz
brew link --overwrite opencascade

After this, I am able to get past the opencascade link errors.

I do have another error after this, which I haven't figured out yet:

make[6]: *** No rule to make target
`/usr/local/Cellar/cairo/1.16.0_3/lib/libcairo.dylib', needed by
`kicad/KiCad.app/Contents/PlugIns/_eeschema.kiface'.  Stop.

@Adam or anyone else, have you seen this before?

-Jon

On Sat, Mar 6, 2021 at 3:47 AM Jonatan Liljedahl  wrote:

> On Fri, Mar 5, 2021 at 8:45 PM Adam Wolf 
> wrote:
> >
> > It is certainly possible that Homebrew is distributing bottles that
> > are linked a little weird, and you'd be getting the MacOS 10.14
> > reference from that.  We've had this happen before.
>
> Yes, I think this was the case with my OCE install, OCEConfig.cmake
> referenced 10.14. After unbrewing OCE, I tried to brew install it
> again but only got a 404. However, after that I reinstalled OCC and it
> built fine so maybe OCE and OCC was in conflict or something.
>
> > Regarding the libTKVCAF error, it looks like something's not quite
> > right between the library and the fixup_bundle call.
> >
> > Does libTKVCAF.7.dylib exist on your system?
>
> Yes, that and all other OCC libs exist in
> /usr/local/Cellar/opencascade/7.5.0_1/lib as well as symlinked into
> /usr/local/lib (by homebrew).
>
> So I assume the problem here is that it's not finding all these libs
> at runtime? How can I check if this is actually the issue here?
>
> During "make install" I get all these warnings:
>
> -- warning: embedded item does not exist
>
> '/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKCAF.7.dylib'
> --
> warning: cannot resolve item '@loader_path/libTKCAF.7.dylib'
>
>   possible problems:
> need more directories?
> need to use InstallRequiredSystemLibraries?
> run in install tree instead of build tree?
>
> -- warning: embedded item does not exist
>
> '/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKV3d.7.dylib'
> --
> warning: cannot resolve item '@loader_path/libTKV3d.7.dylib'
>
>   possible problems:
> need more directories?
> need to use InstallRequiredSystemLibraries?
> run in install tree instead of build tree?
>
> -- warning: embedded item does not exist
>
> '/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKLCAF.7.dylib'
> --
> warning: cannot resolve item '@loader_path/libTKLCAF.7.dylib'
>
>   possible problems:
> need more directories?
> need to use InstallRequiredSystemLibraries?
> run in install tree instead of build tree?
>
> -- warning: embedded item does not exist
>
> '/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKCDF.7.dylib'
> --
> warning: cannot resolve item '@loader_path/libTKCDF.7.dylib'
>
>   possible problems:
> need more directories?
> need to use InstallRequiredSystemLibraries?
> run in install tree instead of build tree?
>
> -- warning: embedded item does not exist
>
> '/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKBO.7.dylib'
> --
> warning: cannot resolve item '@loader_path/libTKBO.7.dylib'
>
>   possible problems:
> need more directories?
> need to use InstallRequiredSystemLibraries?
> run in install tree instead of build tree?
>
> -- warning: embedded item does not exist
>
> '/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKPrim.7.dylib'
> --
> warning: cannot resolve item '@loader_path/libTKPrim.7.dylib'
>
>   possible problems:
> need more directories?
> need to use InstallRequiredSystemLibraries?
> run in install tree instead of build tree?
>
> -- warning: embedded item does not exist
>
> '/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKService.7.dylib'
> --
> warning: cannot resolve item '@loader_path/libTKService.7.dylib'
>
>   possible problems:
> need more directories?
> need to use InstallRequiredSystemLibraries?
> run in install tree instead of build tree?
>
> -- warning: embedded item does not exist
>
> '/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKMesh.7.dylib'
> --
> warning: cannot resolve item '@loader_path/libTKMesh.7.dylib'
>
>   possible problems:
> need more directories?
> need to use InstallRequiredSystemLibraries?
> run in install tree instead of build tree?
>
> -- warning: embedded item does not exist
>
> '/Users/lijon/Coding/kicad/build/install/KiCad.app/Contents/PlugIns/3d/libTKShHealing.7.dylib'
> --
> warning: cannot resolve item '@loader_path/libTKShHealing.7.dylib'
>
>   possible problems:
> need more directories?
> 

Re: [Kicad-developers] Build error.

[Jon Evans]

Should be fixed now.

On Sat, Feb 27, 2021 at 7:48 AM Wayne Stambaugh 
wrote:

> Looks like a commit in the last 24 hours broke KiCad builds with Python
> enabled.  Here is the build error on Linux using gcc 9.3.0.
>
> In file included from
> /usr/include/x86_64-linux-gnu/c++/9/bits/c++allocator.h:33,
>  from /usr/include/c++/9/bits/allocator.h:46,
>  from /usr/include/c++/9/string:41,
>  from /usr/include/c++/9/stdexcept:39,
>  from
>
> /home/wayne/build/kicad/trunk-debug-gtk3-phoenix-occt/pcbnew/pcbnew_wrap.cxx:3006:
> /usr/include/c++/9/ext/new_allocator.h: In instantiation of ‘void
> __gnu_cxx::new_allocator<_Tp>::construct(_Up*, _Args&& ...) [with _Up =
> std::pair >; _Args = {const
> std::pair std::default_delete > >&}; _Tp =
> std::_Rb_tree_node > >]’:
> /usr/include/c++/9/bits/alloc_traits.h:482:2:   required from ‘static
> void std::allocator_traits
> >::construct(std::allocator_traits
> >::allocator_type&, _Up*, _Args&& ...) [with _Up = std::pair const, std::unique_ptr >; _Args = {const std::pair const, std::unique_ptr > >&};
> _Tp = std::_Rb_tree_node std::unique_ptr > >;
> std::allocator_traits >::allocator_type =
> std::allocator std::unique_ptr > > >]’
> /usr/include/c++/9/bits/stl_tree.h:614:32:   required from ‘void
> std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
> _Alloc>::_M_construct_node(std::_Rb_tree<_Key, _Val, _KeyOfValue,
> _Compare, _Alloc>::_Link_type, _Args&& ...) [with _Args = {const
> std::pair std::default_delete > >&}; _Key = ZONE*; _Val =
> std::pair >; _KeyOfValue =
> std::_Select1st > >;
> _Compare = std::less; _Alloc = std::allocator const, std::unique_ptr > >; std::_Rb_tree<_Key, _Val,
> _KeyOfValue, _Compare, _Alloc>::_Link_type =
> std::_Rb_tree_node > >*]’
> /usr/include/c++/9/bits/stl_tree.h:487:3:   required from
> ‘std::_Rb_tree_node<_Val>* std::_Rb_tree<_Key, _Val, _KeyOfValue,
> _Compare, _Alloc>::_Reuse_or_alloc_node::operator()(_Arg&&) [with _Arg =
> const std::pair >&; _Key =
> ZONE*; _Val = std::pair >;
> _KeyOfValue = std::_Select1st std::unique_ptr > >; _Compare = std::less; _Alloc =
> std::allocator > >;
> std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_Link_type =
> std::_Rb_tree_node > >*]’
> /usr/include/c++/9/bits/stl_tree.h:658:33:   required from
> ‘std::_Rb_tree_node<_Val>* std::_Rb_tree<_Key, _Val, _KeyOfValue,
> _Compare, _Alloc>::_M_clone_node(std::_Rb_tree<_Key, _Val, _KeyOfValue,
> _Compare, _Alloc>::_Const_Link_type, _NodeGen&) [with _NodeGen =
> std::_Rb_tree
> >, std::_Select1st >
> >, std::less, std::allocator std::unique_ptr > > >::_Reuse_or_alloc_node; _Key = ZONE*;
> _Val = std::pair >; _KeyOfValue
> = std::_Select1st > >;
> _Compare = std::less; _Alloc = std::allocator const, std::unique_ptr > >; std::_Rb_tree<_Key, _Val,
> _KeyOfValue, _Compare, _Alloc>::_Link_type =
> std::_Rb_tree_node >
> >*; std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
> _Alloc>::_Const_Link_type = const std::_Rb_tree_node const, std::unique_ptr > >*]’
> /usr/include/c++/9/bits/stl_tree.h:1875:13:   required from
> ‘std::_Rb_tree_node<_Val>* std::_Rb_tree<_Key, _Val, _KeyOfValue,
> _Compare, _Alloc>::_M_copy(std::_Rb_tree<_Key, _Val, _KeyOfValue,
> _Compare, _Alloc>::_Const_Link_type, std::_Rb_tree<_Key, _Val,
> _KeyOfValue, _Compare, _Alloc>::_Base_ptr, _NodeGen&) [with _NodeGen =
> std::_Rb_tree
> >, std::_Select1st >
> >, std::less, std::allocator std::unique_ptr > > >::_Reuse_or_alloc_node; _Key = ZONE*;
> _Val = std::pair >; _KeyOfValue
> = std::_Select1st > >;
> _Compare = std::less; _Alloc = std::allocator const, std::unique_ptr > >; std::_Rb_tree<_Key, _Val,
> _KeyOfValue, _Compare, _Alloc>::_Link_type =
> std::_Rb_tree_node >
> >*; std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
> _Alloc>::_Const_Link_type = const std::_Rb_tree_node const, std::unique_ptr > >*; std::_Rb_tree<_Key, _Val,
> _KeyOfValue, _Compare, _Alloc>::_Base_ptr = std::_Rb_tree_node_base*]’
> /usr/include/c++/9/bits/stl_tree.h:901:15:   required from
> ‘std::_Rb_tree_node<_Val>* std::_Rb_tree<_Key, _Val, _KeyOfValue,
> _Compare, _Alloc>::_M_copy(const std::_Rb_tree<_Key, _Val, _KeyOfValue,
> _Compare, _Alloc>&, _NodeGen&) [with _NodeGen = std::_Rb_tree std::pair >,
> std::_Select1st > >,
> std::less, std::allocator std::unique_ptr > > >::_Reuse_or_alloc_node; _Key = ZONE*;
> _Val = std::pair >; _KeyOfValue
> = std::_Select1st > >;
> _Compare = std::less; _Alloc = std::allocator const, std::unique_ptr > >; std::_Rb_tree<_Key, _Val,
> _KeyOfValue, _Compare, _Alloc>::_Link_type =
> std::_Rb_tree_node > >*]’
> /usr/include/c++/9/bits/stl_tree.h:1783:16:   required from
> ‘std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>&
> std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
> _Alloc>::operator=(const std::_Rb_tree<_Key, _Val, _KeyOfValue,
> _Compare, _Alloc>&) [with _Key = ZONE*; _Val = std::pair std::unique_ptr >; _KeyOfValue =
> std::_Select1st > >;
> _Compare = std::less; _Alloc = std::allocator const, 

Re: [Kicad-developers] Code execution context

[Jon Evans]

As long as the experience is the same on all platforms (Win, Mac, Linux)
and KiCad does not require any proprietary libraries to compile, I think it
is up to Wayne whether or not an optional dependency on a proprietary
library on Windows is acceptable.

But, I would like to hear from Markus on the topic first -- if other
software is successfully using websockets to provide a good interface to
3dconnexion hardware on Windows, maybe it is not as bad as you fear?

-Jon

On Thu, Feb 25, 2021 at 9:38 AM Mark Roszko  wrote:

> On another note, I personally am not a fan of websockets usage locally on
> Windows. In corporate environments there's going to be hell with security
> software interfering and in general it's fragile.
>
> I personally would rather just link against the 3dconnexion library
> directly. We have the MSVC builds now, we can compile against MSVC built
> libraries no problem. MSYS2 builds would just remain without it.
>
> But just my opinion on this.
>
> On Thu, Feb 25, 2021 at 9:32 AM Jon Evans  wrote:
>
>> That is a good point Mark, we could either have this behind a flag so
>> that it only gets enabled/compiled with new-enough Boost versions, or
>> investigate a different websockets library.
>>
>> I'm not sure the overlap of 3dconnexion users and 18.04 users is large
>> enough to rule that approach out, at least if there are no other issues
>> with Beast.
>>
>> -Jon
>>
>> On Thu, Feb 25, 2021 at 9:23 AM Mark Roszko 
>> wrote:
>>
>>> * Boost 1.65 being the version Ubuntu 18.04 LTS currently has and are
>>> committed to support until EOL.
>>>
>>> On Thu, Feb 25, 2021 at 9:19 AM Mark Roszko 
>>> wrote:
>>>
>>>> Markus,
>>>>
>>>> We currently require support for a minimum of boost 1.59 due to Linux
>>>> distros lagging behind. boost/beast is not a viable option as beast did not
>>>> appear in boost until 1.66.
>>>>
>>>> From some offhand sounding out we may be able to bump the minimum to
>>>> 1.65 but that doesn't help :/
>>>>
>>>>
>>>> Regards,
>>>> Mark
>>>>
>>>> On Thu, Feb 25, 2021 at 9:00 AM Jon Evans  wrote:
>>>>
>>>>> Hello Markus,
>>>>>
>>>>> This is exciting news, as some of our users are also big fans of
>>>>> 3dconnexion products[1]
>>>>>
>>>>> Others have looked in to what it would take in the past, but there
>>>>> were some questions about the need for proprietary drivers on some
>>>>> platforms[2]
>>>>>
>>>>> It sounds like this websocket interface is a new approach that doesn't
>>>>> require any additional libraries for KiCad to link against?
>>>>> Does the hardware use some other daemon process to bridge between the
>>>>> device driver and websockets?
>>>>>
>>>>> As you may know, KiCad uses wxWidgets as a framework, so you probably
>>>>> want to plug in to the wx event loop on the main thread.
>>>>> There are some guidelines on this in their docs[3].
>>>>>
>>>>> You probably want to check out ./common/view/wx_view_controls.cpp to
>>>>> see how existing input events are handled by the 2D canvases.
>>>>> I guess your new code would hook in here somewhere, and provide
>>>>> additional event handlers to manage the data from the 3D device.
>>>>> Your communication thread should be able to post wxWidgets events to
>>>>> the main thread and then we can consume them here.
>>>>>
>>>>> By the way: although the wx docs use wxThread, I think this general
>>>>> concept should work with C++ standard libraries threads just fine.
>>>>> The documentation for wxEvtHandler::QueueEvent may also be useful[4]
>>>>>
>>>>> Hope this helps!
>>>>>
>>>>> Best,
>>>>> Jon
>>>>>
>>>>> [1] https://gitlab.com/kicad/code/kicad/-/issues/4951
>>>>> [2] https://lists.launchpad.net/kicad-developers/msg29464.html
>>>>> [3]
>>>>> https://wiki.wxwidgets.org/Inter-Thread_and_Inter-Process_communication#Sending_events_to_the_main_thread_-_wxWidgets_3_only
>>>>> [4]
>>>>> https://docs.wxwidgets.org/3.0/classwx_evt_handler.html#acffd03bf407a856166ea71ef0318b59a
>>>>>
>>>>>
>>>>> On Thu, Feb 25, 2021 at 1:47 AM Markus Bonk <
>>>>&

Re: [Kicad-developers] Code execution context

[Jon Evans]

That is a good point Mark, we could either have this behind a flag so that
it only gets enabled/compiled with new-enough Boost versions, or
investigate a different websockets library.

I'm not sure the overlap of 3dconnexion users and 18.04 users is large
enough to rule that approach out, at least if there are no other issues
with Beast.

-Jon

On Thu, Feb 25, 2021 at 9:23 AM Mark Roszko  wrote:

> * Boost 1.65 being the version Ubuntu 18.04 LTS currently has and are
> committed to support until EOL.
>
> On Thu, Feb 25, 2021 at 9:19 AM Mark Roszko  wrote:
>
>> Markus,
>>
>> We currently require support for a minimum of boost 1.59 due to Linux
>> distros lagging behind. boost/beast is not a viable option as beast did not
>> appear in boost until 1.66.
>>
>> From some offhand sounding out we may be able to bump the minimum to 1.65
>> but that doesn't help :/
>>
>>
>> Regards,
>> Mark
>>
>> On Thu, Feb 25, 2021 at 9:00 AM Jon Evans  wrote:
>>
>>> Hello Markus,
>>>
>>> This is exciting news, as some of our users are also big fans of
>>> 3dconnexion products[1]
>>>
>>> Others have looked in to what it would take in the past, but there were
>>> some questions about the need for proprietary drivers on some platforms[2]
>>>
>>> It sounds like this websocket interface is a new approach that doesn't
>>> require any additional libraries for KiCad to link against?
>>> Does the hardware use some other daemon process to bridge between the
>>> device driver and websockets?
>>>
>>> As you may know, KiCad uses wxWidgets as a framework, so you probably
>>> want to plug in to the wx event loop on the main thread.
>>> There are some guidelines on this in their docs[3].
>>>
>>> You probably want to check out ./common/view/wx_view_controls.cpp to see
>>> how existing input events are handled by the 2D canvases.
>>> I guess your new code would hook in here somewhere, and provide
>>> additional event handlers to manage the data from the 3D device.
>>> Your communication thread should be able to post wxWidgets events to the
>>> main thread and then we can consume them here.
>>>
>>> By the way: although the wx docs use wxThread, I think this general
>>> concept should work with C++ standard libraries threads just fine.
>>> The documentation for wxEvtHandler::QueueEvent may also be useful[4]
>>>
>>> Hope this helps!
>>>
>>> Best,
>>> Jon
>>>
>>> [1] https://gitlab.com/kicad/code/kicad/-/issues/4951
>>> [2] https://lists.launchpad.net/kicad-developers/msg29464.html
>>> [3]
>>> https://wiki.wxwidgets.org/Inter-Thread_and_Inter-Process_communication#Sending_events_to_the_main_thread_-_wxWidgets_3_only
>>> [4]
>>> https://docs.wxwidgets.org/3.0/classwx_evt_handler.html#acffd03bf407a856166ea71ef0318b59a
>>>
>>>
>>> On Thu, Feb 25, 2021 at 1:47 AM Markus Bonk 
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>> I am currently investigating adding support for 3D input devices to
>>>> pcbnew. The plan is to use a websocket interface (boost/beast) to
>>>> communicate with the 3D device. Effectively the communication runs on an
>>>> extra thread. Somewhere the event code will need to switch to executing on
>>>> the main thread.
>>>>
>>>>
>>>>
>>>> One way of achieving this on say win32 might be to add functors to a
>>>> queue post a message to a message window handler in the main thread which
>>>> empties the queue and invokes the functor.
>>>>
>>>>
>>>>
>>>> Is such a mechanism already in place in KiCAD? What is the KiCAD
>>>> recommended solution to the issue?
>>>>
>>>>
>>>>
>>>> Thanks
>>>>
>>>> -Markus
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> *Markus Bonk*
>>>> Senior Software Engineer
>>>>
>>>> Clarita-Bernhard-Str. 18
>>>> 81249 München
>>>> Germany
>>>> markus_b...@3dconnexion.com <%7BE-mail%7D>
>>>> www.3dconnexion.com
>>>>
>>>> Geschäftsführer: Antonio Pascucci
>>>> Sitz der Gesellschaft: München
>>>> Registergericht: München HRB 99232
>>>>
>>>> This email a

Re: [Kicad-developers] Code execution context

[Jon Evans]

Hello Markus,

This is exciting news, as some of our users are also big fans of
3dconnexion products[1]

Others have looked in to what it would take in the past, but there were
some questions about the need for proprietary drivers on some platforms[2]

It sounds like this websocket interface is a new approach that doesn't
require any additional libraries for KiCad to link against?
Does the hardware use some other daemon process to bridge between the
device driver and websockets?

As you may know, KiCad uses wxWidgets as a framework, so you probably want
to plug in to the wx event loop on the main thread.
There are some guidelines on this in their docs[3].

You probably want to check out ./common/view/wx_view_controls.cpp to see
how existing input events are handled by the 2D canvases.
I guess your new code would hook in here somewhere, and provide additional
event handlers to manage the data from the 3D device.
Your communication thread should be able to post wxWidgets events to the
main thread and then we can consume them here.

By the way: although the wx docs use wxThread, I think this general concept
should work with C++ standard libraries threads just fine.
The documentation for wxEvtHandler::QueueEvent may also be useful[4]

Hope this helps!

Best,
Jon

[1] https://gitlab.com/kicad/code/kicad/-/issues/4951
[2] https://lists.launchpad.net/kicad-developers/msg29464.html
[3]
https://wiki.wxwidgets.org/Inter-Thread_and_Inter-Process_communication#Sending_events_to_the_main_thread_-_wxWidgets_3_only
[4]
https://docs.wxwidgets.org/3.0/classwx_evt_handler.html#acffd03bf407a856166ea71ef0318b59a


On Thu, Feb 25, 2021 at 1:47 AM Markus Bonk 
wrote:

> Hi,
>
>
>
> I am currently investigating adding support for 3D input devices to
> pcbnew. The plan is to use a websocket interface (boost/beast) to
> communicate with the 3D device. Effectively the communication runs on an
> extra thread. Somewhere the event code will need to switch to executing on
> the main thread.
>
>
>
> One way of achieving this on say win32 might be to add functors to a queue
> post a message to a message window handler in the main thread which empties
> the queue and invokes the functor.
>
>
>
> Is such a mechanism already in place in KiCAD? What is the KiCAD
> recommended solution to the issue?
>
>
>
> Thanks
>
> -Markus
>
>
>
>
>
> --
>
> *Markus Bonk*
> Senior Software Engineer
>
> Clarita-Bernhard-Str. 18
> 81249 München
> Germany
> markus_b...@3dconnexion.com <%7BE-mail%7D>
> www.3dconnexion.com
>
> Geschäftsführer: Antonio Pascucci
> Sitz der Gesellschaft: München
> Registergericht: München HRB 99232
>
> This email and any files transmitted with are from 3Dconnexion GmbH. The
> contents of this email and any attachments are confidential to the intended
> recipient. They may not be disclosed to or used by or copied in any way by
> anyone other than the intended recipient. If this email is received in
> error, please contact 3Dconnexion GmbH by calling +49 89 8974542-0 and then
> delete it. Please note that neither 3Dconnexion GmbH nor the sender accepts
> any responsibility for viruses and it is your responsibility to scan or
> otherwise check this email and any attachments. Any opinion expressed in
> this email are those of the individual and not necessarily those of
> 3Dconnexion GmbH.
> 3Dconnexion GmbH processes and stores for commercial purposes your
> personal data, collected upon your consent, in accordance with its privacy
> policy available at https://www.3dconnexion.eu/privacy.html, which has
> been drafted in accordance with Regulation (EU) no. 679/2016 and all
> applicable local data protection laws and regulations of the countries
> where the company operates. To revoke your consent or exercise all your
> rights with regards to personal data, please contact us at
> priv...@3dconnexion.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
>
___
Mailing list: https://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] PCB Calculator text problem

[Jon Evans]

Issue reporting instructions are here:
https://kicad.org/help/report-an-issue/

Best,
Jon

On Fri, Feb 19, 2021 at 12:42 PM David  wrote:

> Hi,
>
> Just to let you know that there is a problem with the text on the first
> column fourth row of the board classes tab of the PCB Calculator (Please
> see attached screenshot). The text overflows the box.
>
> I don't know how to report bugs so thought I'd mention it here. Thanks.
>
> Thanks.
>
> David.
>
> ___
> Mailing list: https://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] error compiling kicad branch 5.1

[Jon Evans]

We don't have CI on the 5.1 branch right now.  I'm not sure if there is any
reason other than needing to set up additional runner machines, I agree it
would be a good idea.

On Wed, Feb 17, 2021 at 10:46 AM Marco Ciampa  wrote:

> On Wed, Feb 17, 2021 at 08:12:14AM -0500, Jon Evans wrote:
> > Hi Marco,
>
> Hi Jon,
>
> > I am not part of kicad-us...@groups.io but I am part of this list and I
> can
> > fix the issue you mention, sorry about that...
>
> You see, first I try to fix it myself, then ask others, then ask devs as
> a last resort...
>
> Glad I helped spot a glitch... only thought that bugs me... that should
> be the kind of problem that CI should help detect... I wonder why it
> didn't work?
>
> --
>
> Saluton,
> Marco Ciampa
>
> ___
> Mailing list: https://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] [ciam...@posteo.net: [kicad-users] error compiling kicad branch 5.1]

[Jon Evans]

Hi Marco,

I am not part of kicad-us...@groups.io but I am part of this list and I can
fix the issue you mention, sorry about that...

Best,
Jon

On Wed, Feb 17, 2021 at 7:34 AM Marco Ciampa  wrote:

> Forwarded because nobody answered me...
>
> - Forwarded message from Marco Ciampa  -
>
> Date: Sun, 14 Feb 2021 15:38:24 +0100
> From: Marco Ciampa 
> To: kicad-us...@groups.io
> Subject: [kicad-users] error compiling kicad branch 5.1
>
> Sorry to bother you but I do not understand what it's going on here
> (on my computer) and I do not know who I can ask for a hint...
>
> All of a sudden my computer started to say this:
>
> ~/git/gitlab/kicad/branch-5.1/code/kicad/eeschema/bom_plugins.cpp:130:10:
> error: ‘BOM_GENERATOR_HANDLER’ has not been declared
> wxString BOM_GENERATOR_HANDLER::getOutputExtension( const wxString&
> aHeader )
> make[2]: *** [eeschema/CMakeFiles/eeschema_kiface.dir/build.make:1191:
> eeschema/CMakeFiles/eeschema_kiface.dir/bom_plugins.cpp.o] Error 1
>
> KiCad master branch compiles just fine...
>
> My sysstem is Linux Unbuntu 20.04 64bit...
>
> Any hint?
>
> --
>
> Saluton,
> Marco Ciampa
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Groups.io Links: You receive all messages sent to this group.
> View/Reply Online (#22982): https://groups.io/g/kicad-users/message/22982
> Mute This Topic: https://groups.io/mt/80631239/2365677
> Group Owner: kicad-users+ow...@groups.io
> Unsubscribe: https://groups.io/g/kicad-users/leave/4830707/910801564/xyzzy
> [ciam...@posteo.net]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>
> - End forwarded message -
>
> --
>
> Saluton,
> Marco Ciampa
>
> ___
> Mailing list: https://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] Icon freeze

[Jon Evans]

We are planning something like this.  However I want to also mention that
we need to re-do most of the documentation itself (not just update the
screenshots for the existing documentation) because so much functionality
has changed.

On Sat, Feb 6, 2021 at 8:07 AM Константин Барановский <
baranovskiykonstan...@gmail.com> wrote:

> Could we have an icon freeze for the 6.0 version along with the string
> freeze (or even the GUI freeze)?
> It would give a good chance to update the screenshots of the documentation.
> We could start a tradition to update doc's screenshots for every major
> version.
> What do you think?
> ___
> Mailing list: https://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] DXF export generates non-closed polygons, and other problems interchanging data w/ Sonnet

[Jon Evans]

Hi Andrew,

The attached file does not open in PcbNew, it appears to be truncated.
It would be helpful if you could attach the full file to a GitLab issue
along with the exported DXF:
https://gitlab.com/kicad/code/kicad/-/issues/new?issue%5Bassignee_id%5D=%5Bmilestone_id%5D=

Thanks,
Jon

On Tue, Jan 12, 2021 at 7:44 AM Andrew Zonenberg 
wrote:

> Hi,
>
> Kicad's DXF export seems to be broken, causing many tools (such as the
> Sonnet field solver, example attached) to not import layouts correctly.
> I contacted Sonnet support and they did some digging; it seems like
> KiCAD is producing malformed DXFs that have non-closed polygons in them.
>
> I've also encountered two other problems getting KiCAD designs into Sonnet:
>
> 1) Sonnet's DXF import expects a *single* DXF, with one drawing layer
> per PCB/via layer. KiCAD generates one DXF per layer and I don't think
> there is currently a way to do a multilayer export. This isn't a fatal
> problem as I can just do multiple imports, but it's annoying.
>
> 2) More seriously, There does not seem to be any way to get via drill
> *outlines* in DXF format. The "drill map" file just has an X at each via
> location which is useless when trying to import layout into an external
> tool.
>
> Anybody have suggestions on how to proceed, or interested in helping to
> fix this? I'm not super familiar with the DXF file format although back
> in the v4.x days I did do some work on the microvia/blind via Excellon
> drill export code so I've done at least a little bit of work there.
> ___
> Mailing list: https://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] Dragging 45° trace in pcbnew lets the trace jump around

[Jon Evans]

I can't see an attached video, but what version do you have?

This behavior sounds like a recently fixed bug:
https://gitlab.com/kicad/code/kicad/-/issues/7002

On Tue, Jan 12, 2021 at 7:45 AM Johann Wilhelm
 wrote:

> Hi there!
>
> I have the feeling, there's something wrong with the dragging of 45°
> traces.
>
> If I drag a 0 (horizontal) or 90 (vertical) trace, everything moves as
> expected.
> The 45° part lets everything jump around... (see attached video)
>
> I did not report this earlier since I thought that might be some push/shove
> quirks...
> After playing around with the settings, I'm now very confident, that this
> has nothing to do with the interactive router, but might be just some x/y
> coordinate mixing somewhere in the pushing-code...
>
> Any thoughts?
>
> Regards,
> Johann
>
> Dipl.-Ing.
> *Johann Maximilian Wilhelm*
> *Bahnhofstraße 16/1*
> *4600 Wels / AUSTRIA*
> *Tel: +43 664 55 269 77*
> *VAT Number: ATU74582123*
> *EORI-Number: ATEOS1000106258*
> ___
> Mailing list: https://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] canvas_type configuration in different subprograms in 5.99?

[Jon Evans]

That key is part of the shared configuration class that is inherited by all
the specific application configuration classes.

Not all the applications actually make use of their own key.  For example,
the symbol editor will just use the eeschema setting, and the footprint
editor just uses the pcbnew setting.

I have not looked through the code to verify which of the other
applications actually make use of their key vs. inheriting from one of the
"main" programs.

-Jon

On Mon, Jan 11, 2021 at 10:25 AM Eeli Kaikkonen 
wrote:

> I quickly tried to set the canvas type to Accelerated on all
> subprograms. Then when I grep the configuration files I get:
>
> gerbview.json:"canvas_type": 1,
> libedit.json:"canvas_type": 2,
> pcb_calculator.json:"canvas_type": 2,
> 3d_viewer.json:"canvas_type": 2,
> bitmap2component.json:"canvas_type": 2,
> eeschema.json:"canvas_type": 1,
> cvpcb.json:"canvas_type": 2,
> kicad.json:"canvas_type": 2,
> pcbnew.json:"canvas_type": 1,
> symbol_editor.json:"canvas_type": 2,
> fpedit.json:"canvas_type": 2,
> pl_editor.json:"canvas_type": 1,
>
> Does it actually mean the same thing in all these files, and why the
> inconsistency?
>
> 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

[Kicad-developers] Starter bugs for V6

[Jon Evans]

Hi folks,

We've got a pile of bugs to fix between now and V6 release.

Some of them we think would be more approachable for those who haven't
contributed to KiCad before or have not contributed frequently.  These are
tagged "starter" on GitLab:

https://gitlab.com/kicad/code/kicad/-/issues?scope=all=%E2%9C%93=opened_name[]=starter_title=6.0.0-rc1_id=None

We'd appreciate any help on these!  If you'd like to take on one of these
issues, please leave a comment saying so on that issue page and one of us
can assign it to you.

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

Re: [Kicad-developers] 5.1.9 tagged for release

[Jon Evans]

Hi all,

I feel kind of bad now, my "Christmas special" email was not supposed to be
taken so seriously.

I don't think there is any huge rush, and if we need more time to prepare
the release, using Wayne's original timeline or something in the middle
(1-January release?) would also be fine, I think...

Best,
Jon

On Wed, Dec 23, 2020 at 5:47 AM Nick Østergaard  wrote:

> This is a distributed effort. We can't wait to announce it untill all habe
> bumped the pkgver, this could mean that we have builds released months
> before we even announced it and it will confuse users. Having "major"
> platforms covered and then announce is a good comprimise. Two of those
> don't are not released via a native package manager.
>
> ons. 23. dec. 2020 11.20 skrev Carsten Schoenert  >:
>
>> Hell Nick,
>>
>> Am 23.12.20 um 10:07 schrieb Nick Østergaard:
>> > Hi Carsten
>> >
>> > This is a balancing act. Quite some time ago we decided that we should
>> > make the release _announcement_ (on the website) when we have build
>> > available for some major platforms, these specifically being windows,
>> > ubuntu ppa and macos, mostly because that gives us some good
>> > "coverage" and we control those builds "ourselves".
>>
>> that's of course up to the KiCad team to do such decisions. But I see no
>> reason why KiCad should be that exclusive. So far I've seen in the past
>> all the big distributions and the maintainer of the packages for KiCad
>> have acted quick as possible. But you need to give them some time. And
>> again, we have x-mas, why rushing things more than needed?
>>
>> > I am not trying to exclude you as a kicad maintainer.
>>
>> But this is it it looks like.
>> As at least one other contributor has stated, please give us the needed
>> time. No planned release announcement was done again on any of the ML. :-(
>>
>> > By having the release announcement, it is easier to use that as a
>> > reference when users are flagging packages in various distros.
>> > Essentially we don't expect other distros to have builds ready by the
>> > release announcement.
>> Why not doing this? It has worked in the past years. It would look much
>> better if things would be done more coordinated.
>>
>> --
>> Regards
>> Carsten
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] 5.1.9 tagged for release

[Jon Evans]

The KiCad Christmas special?

On Tue, Dec 22, 2020 at 5:02 PM Nick Østergaard  wrote:

> I don't think we need that long. Everything seems to be tagged. I have
> triggered the windows build and it should just be a simple pkgver bump
> for macos and ubuntu ppa as well.
>
>
> On Tue, 22 Dec 2020 at 21:14, Wayne Stambaugh 
> wrote:
> >
> > 5.1.9 has been tagged for release. Please tag the library, doc, and
> > translation repos for release. I don't think we have much in the way of
> > changes there so is a week to get these repos tagged and another week to
> > get packages built for a January 5th release work for everyone?  Please
> > let me know an I will adjust the release schedule accordingly.  As
> > always, thank you to everyone who made this possible.
> >
> > Cheers,
> >
> > Wayne
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Buses - what am I doing wrong

[Jon Evans]

Note for the list:  Brian's design (shared privately with me) exposed
several bugs, and I have fixed the most serious one (and added a new
testcase for it).

https://gitlab.com/kicad/code/kicad/-/commit/a900fb319d34769eabb5a9e52a919f730f70dae6

I haven't yet fixed the other bugs or filed them on GitLab but will try to
do that soon if nobody beats me to it:

1) Schematic cleanup is missing some things.  In particular, Brian's design
has unnecessary junctions and overlapping wire segments that should have
been deleted.

2) dragging a bus wire away from a junction will cause a regular (non-bus)
wire to be added in -- this is new and probably related to the recent
dragging changes.

-Jon

On Tue, Oct 27, 2020 at 9:07 PM Jon Evans  wrote:

> Any chance you can share your schematic?
>
> I noticed that in your screenshot, your label {SD_SIGNALS} is on a green
> wire.
> By default, buses are blue and plain wires are green.
> Did you change the color theme, or is that not a bus?
>
> -Jon
>
> On Tue, Oct 27, 2020 at 9:04 PM Brian Piccioni <
> br...@documenteddesigns.com> wrote:
>
>> Hello
>>
>> I thought I had figured out bus aliases, etc. but likely not.
>>
>> I have a bus alias {SD_SIGNALS}. I run a bus and put a label {SD_SIGNALS}
>> on the bus. It is blue.
>>
>> I can unfold my signals from the bus. I run ERC and it flags my unfolded
>> signals "Net is graphically connected to bus but is not a bus member"
>>
>> I notice the label {SD_SIGNALS} has turned from blue to black.
>>
>> If I try unfold from the bus I get the error "Bus has no members".
>>
>> If I move the label away and then back on to the bus it turns blue again
>> and I can unfold signals. Unfortunately, if I run ERC I get the same errors.
>>
>> Rinse and repeat.
>>
>> What am I doing wrong?
>>
>> Application: Eeschema
>>
>>
>>
>> Version: (5.99.0-6550-gd6f91c810f), release build
>>
>> Libraries:
>> wxWidgets 3.0.5
>> libcurl/7.71.0 OpenSSL/1.1.1g (Schannel) zlib/1.2.11 brotli/1.0.7
>> libidn2/2.3.0 libpsl/0.21.0 (+libidn2/2.3.0) libssh2/1.9.0 nghttp2/1.41.0
>>
>> Platform: Windows 10 (build 18363), 64-bit edition, 64 bit, Little
>> endian, wxMSW
>>
>> Build Info:
>> Date: Oct 25 2020 10:10:16
>> wxWidgets: 3.0.5 (wchar_t,wx containers,compatible with 2.8)
>> Boost: 1.73.0
>> OCE: 6.9.1
>> Curl: 7.71.0
>> ngspice: 32
>> Compiler: GCC 10.2.0 with C++ ABI 1014
>>
>> Build settings:
>> KICAD_SCRIPTING=ON
>> KICAD_SCRIPTING_MODULES=ON
>> KICAD_SCRIPTING_PYTHON3=OFF
>> KICAD_SCRIPTING_WXPYTHON=ON
>> KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
>> KICAD_SCRIPTING_ACTION_MENU=ON
>> BUILD_GITHUB_PLUGIN=ON
>> KICAD_USE_OCE=ON
>> KICAD_SPICE=ON
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Buses - what am I doing wrong

[Jon Evans]

Any chance you can share your schematic?

I noticed that in your screenshot, your label {SD_SIGNALS} is on a green
wire.
By default, buses are blue and plain wires are green.
Did you change the color theme, or is that not a bus?

-Jon

On Tue, Oct 27, 2020 at 9:04 PM Brian Piccioni 
wrote:

> Hello
>
> I thought I had figured out bus aliases, etc. but likely not.
>
> I have a bus alias {SD_SIGNALS}. I run a bus and put a label {SD_SIGNALS}
> on the bus. It is blue.
>
> I can unfold my signals from the bus. I run ERC and it flags my unfolded
> signals "Net is graphically connected to bus but is not a bus member"
>
> I notice the label {SD_SIGNALS} has turned from blue to black.
>
> If I try unfold from the bus I get the error "Bus has no members".
>
> If I move the label away and then back on to the bus it turns blue again
> and I can unfold signals. Unfortunately, if I run ERC I get the same errors.
>
> Rinse and repeat.
>
> What am I doing wrong?
>
> Application: Eeschema
>
>
>
> Version: (5.99.0-6550-gd6f91c810f), release build
>
> Libraries:
> wxWidgets 3.0.5
> libcurl/7.71.0 OpenSSL/1.1.1g (Schannel) zlib/1.2.11 brotli/1.0.7
> libidn2/2.3.0 libpsl/0.21.0 (+libidn2/2.3.0) libssh2/1.9.0 nghttp2/1.41.0
>
> Platform: Windows 10 (build 18363), 64-bit edition, 64 bit, Little endian,
> wxMSW
>
> Build Info:
> Date: Oct 25 2020 10:10:16
> wxWidgets: 3.0.5 (wchar_t,wx containers,compatible with 2.8)
> Boost: 1.73.0
> OCE: 6.9.1
> Curl: 7.71.0
> ngspice: 32
> Compiler: GCC 10.2.0 with C++ ABI 1014
>
> Build settings:
> KICAD_SCRIPTING=ON
> KICAD_SCRIPTING_MODULES=ON
> KICAD_SCRIPTING_PYTHON3=OFF
> KICAD_SCRIPTING_WXPYTHON=ON
> KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
> KICAD_SCRIPTING_ACTION_MENU=ON
> BUILD_GITHUB_PLUGIN=ON
> KICAD_USE_OCE=ON
> KICAD_SPICE=ON
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] V6 Usability suggestion

[Jon Evans]

I think we can define a manual grouping and sort order based on function,
and apply that here as well as in the DRC dialog perhaps

On Wed, Oct 21, 2020 at 1:12 PM Brian  wrote:

>
>
> On 10/21/20 12:51 PM, jp charras wrote:
> > Unfortunately, even in a alphabetical order in English, it will be not
> > ordered in other languages.
> >
>
> It should be sorted at runtime, in the current locale.  Then it's in
> lexicographic order regardless of language.
>
> Note: I say this not having examined the code in the slightest, and
> don't know how dynamic (or non-dynamic) that particular dialog is.
>
> Even when sorted by groups (assuming the groups make sense to every
> user, which is almost certainly not going to be the case), within groups
> a lexicographic sort would be helpful, unless groups are limited to,
> say, 5-10 items each.
>
> My $0.02,
> -Brian (the other one*)
>
> * - one of many, I'm sure
>
> ___
> Mailing list: https://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] Can't see references - V5.99 what am I doing wrong?

[Jon Evans]

(The contrast for the current icons is worse on Windows than on other
platforms because the default Windows application color theme uses a darker
panel background)

On Wed, Oct 14, 2020 at 11:06 AM Jon Evans  wrote:

> Like I said, the icons (visual style and color) will be changed before
> release
>
> On Wed, Oct 14, 2020 at 11:05 AM Brian Piccioni <
> br...@documenteddesigns.com> wrote:
>
>> Perhaps eye / no eye?
>>
>> The thing is, the difference between on and off is eyelashes + contrast.
>> Depending on the display that can be pretty hard to differentiate.
>>
>>
>> On 2020-10-14 11:00 a.m., Jon Evans wrote:
>>
>> > FWIW, I find the "open eye", "closed eye" a bit hard to differentiate.
>> I'd prefer something like an X or check mark.
>>
>> The icons are being tweaked before release.  The problem with the
>> checkboxes is that they look different on every platform and it's not as
>> clear that they are visibility controls -- normally checkboxes are for
>> enabling/disabling things.
>>
>>
>> On Wed, Oct 14, 2020 at 10:57 AM Ian McInerney 
>> wrote:
>>
>>>
>>>
>>> On Wed, Oct 14, 2020 at 3:52 PM Jon Evans  wrote:
>>>
>>>> "Footprint Text" off turns off all footprint text, including references
>>>> and values.  This isn't new behavior but I worry that the simplified
>>>> objects panel has made it more confusing than it was in 5.1
>>>>
>>>>
>>> This only turns it off when viewing the board, correct? It will still be
>>> included in the plot output if the actual text is marked "Show" in the
>>> dialog.
>>>
>>
>> Yes
>>
>>
>>>
>>>> We could have the Footprint Text control act as a visual override for
>>>> the Values and References controls to make this more clear...
>>>>
>>>
>>> Can we link these controls so that changing the "Footprint Text"
>>> visibility changes the "references" and "values" visibility, but those two
>>> can still be changed separately? (e.g. to allow showing only the references
>>> text from footprints).
>>>
>>
>> That's what I was proposing
>>
>> -Jon
>>
>>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Can't see references - V5.99 what am I doing wrong?

[Jon Evans]

Like I said, the icons (visual style and color) will be changed before
release

On Wed, Oct 14, 2020 at 11:05 AM Brian Piccioni 
wrote:

> Perhaps eye / no eye?
>
> The thing is, the difference between on and off is eyelashes + contrast.
> Depending on the display that can be pretty hard to differentiate.
>
>
> On 2020-10-14 11:00 a.m., Jon Evans wrote:
>
> > FWIW, I find the "open eye", "closed eye" a bit hard to differentiate.
> I'd prefer something like an X or check mark.
>
> The icons are being tweaked before release.  The problem with the
> checkboxes is that they look different on every platform and it's not as
> clear that they are visibility controls -- normally checkboxes are for
> enabling/disabling things.
>
>
> On Wed, Oct 14, 2020 at 10:57 AM Ian McInerney 
> wrote:
>
>>
>>
>> On Wed, Oct 14, 2020 at 3:52 PM Jon Evans  wrote:
>>
>>> "Footprint Text" off turns off all footprint text, including references
>>> and values.  This isn't new behavior but I worry that the simplified
>>> objects panel has made it more confusing than it was in 5.1
>>>
>>>
>> This only turns it off when viewing the board, correct? It will still be
>> included in the plot output if the actual text is marked "Show" in the
>> dialog.
>>
>
> Yes
>
>
>>
>>> We could have the Footprint Text control act as a visual override for
>>> the Values and References controls to make this more clear...
>>>
>>
>> Can we link these controls so that changing the "Footprint Text"
>> visibility changes the "references" and "values" visibility, but those two
>> can still be changed separately? (e.g. to allow showing only the references
>> text from footprints).
>>
>
> That's what I was proposing
>
> -Jon
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Can't see references - V5.99 what am I doing wrong?

[Jon Evans]

> FWIW, I find the "open eye", "closed eye" a bit hard to differentiate.
I'd prefer something like an X or check mark.

The icons are being tweaked before release.  The problem with the
checkboxes is that they look different on every platform and it's not as
clear that they are visibility controls -- normally checkboxes are for
enabling/disabling things.


On Wed, Oct 14, 2020 at 10:57 AM Ian McInerney 
wrote:

>
>
> On Wed, Oct 14, 2020 at 3:52 PM Jon Evans  wrote:
>
>> "Footprint Text" off turns off all footprint text, including references
>> and values.  This isn't new behavior but I worry that the simplified
>> objects panel has made it more confusing than it was in 5.1
>>
>>
> This only turns it off when viewing the board, correct? It will still be
> included in the plot output if the actual text is marked "Show" in the
> dialog.
>

Yes


>
>> We could have the Footprint Text control act as a visual override for the
>> Values and References controls to make this more clear...
>>
>
> Can we link these controls so that changing the "Footprint Text"
> visibility changes the "references" and "values" visibility, but those two
> can still be changed separately? (e.g. to allow showing only the references
> text from footprints).
>

That's what I was proposing

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

Re: [Kicad-developers] Can't see references - V5.99 what am I doing wrong?

[Jon Evans]

"Footprint Text" off turns off all footprint text, including references and
values.  This isn't new behavior but I worry that the simplified objects
panel has made it more confusing than it was in 5.1

We could have the Footprint Text control act as a visual override for the
Values and References controls to make this more clear...

On Wed, Oct 14, 2020 at 10:49 AM Brian Piccioni 
wrote:

> I am working on a PCB with PCBNew from a couple days ago.
>
> I can't see the references. Silkscreen is on and the little eye is open
> but the references don't show up.
>
> If I edit a reference it is on the right layer and show is clicked.
>
>
> What am I doing wrong?
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] 3D-Viewer: limit scale to positive values?

[Jon Evans]

(I reopened https://gitlab.com/kicad/code/kicad/-/issues/3453 )

I personally think the best tool we could create is one that allows you to
take a closed shape drawn on a board layer and extrude that by a given
height to create a model that can then be exported as a STEP along with the
rest of the board.
If we did that, we would not need any specific tools for creating boxes or
cylinders.

I think this is somewhat independent from the topic of what to do about
VRML scaling.

-Jon

On Tue, Sep 29, 2020 at 6:17 PM Cirilo Bernardo 
wrote:

> HI Mario,
>
>  Maybe I could make a small tool to allow you to create different
> sized/colored boxes and cylinders
> in VRML format. Would that be helpful to you? We could possibly even
> add other basic shapes.
> I'd like to help users move away from scaling (it's something I always
> wished I could get rid of).
> Unfortunately I see no way we can do this without causing a lot of
> pain to all users who currently
> have scaled VRML models.
>
> Cirilo
>
> On Wed, Sep 30, 2020 at 4:51 AM Mário Luzeiro  wrote:
> >
> > From my user experience: I use the 3 scale values on my projects.
> > I created unit solids (eg: 1mm cube, 1mm cylinder radius / thickness,
> etc) and then I use it to quickly create shapes (by adjusting X,Y,Z scale)
> to populate the board if I don't have the proper STEP model.
> > This is helpful to create round buttons, push buttons switch house
> packages, displays (attached is an example I made just using 1mm cubes)
> > I'm using WRL but I believe it should work if I had used STEP scaled and
> then export it for CAD purposes.
> >
> > If you remove scale at all, I will need to learn and use a new CAD
> software :/ :)
> >
> > My suggestion is keep the scale but hide (or disable) it by default on
> the UI and it should only be enabled by clicking on some checkbox, at that
> time, displaying some message to the user "this is not a good idea for
> CAD.."
> >
> >
> > > I'm not sure the history of why VRML was chosen as the first model
> type that was supported
> >
> > Maybe at that time it was created was a very time consuming thing to
> implement.
> > For STEP we need a 3rd part library (as it is very complex format).
> > On the current 3D-Viewer implementation, Cirilo worked alone on the
> model importer code alone and it took some months of work..
> >
> > Mario
> >
> > 
> > From: Kicad-developers  ua...@lists.launchpad.net> on behalf of Seth Hillbrand  >
> > Sent: 29 September 2020 19:01
> > To: Jon Evans
> > Cc: kicad-developers@lists.launchpad.net
> > Subject: Re: [Kicad-developers] 3D-Viewer: limit scale to positive
> values?
> >
> > I've never seen another package use VRML.  Everyone uses STEP.  I
> suspect if we were implementing this today, we would look at the tradeoff
> on support/benefit for VRML and limit ourselves to STEP as well.
> >
> > I like Ian's suggestion for unit options.
> >
> > -Seth
> >
> > On Tue, Sep 29, 2020 at 10:22 AM Jon Evans  j...@craftyjon.com>> wrote:
> > Do other EDA tools allow model scaling?  Altium doesn't even allow VRML
> import in the first place.
> >
> > On Tue, Sep 29, 2020 at 1:10 PM Seth Hillbrand  <mailto:s...@kipro-pcb.com>> wrote:
> > Well, we've backed ourselves into a bit of a corner.  VRML is specified
> in meters, so if we're assuming inches, we're a bit off in left field.  But
> do we need three separate scale parameters?  We could reduce to 1, correct?
> >
> > In the official footprint library, we have 7 footprints that specify
> non-unity scaling. (Banana_Jack_[1-3], NS-Tech_Grove_1x04, Fuse_Blade_ATO,
> Fuse_Blad_Mini, Oscillator_SMD_TXC0_G158).
> >
> > -Seth
> >
> >
> >
> >
> > On Tue, Sep 29, 2020 at 9:30 AM Ian McInerney  <mailto:ian.s.mciner...@ieee.org>> wrote:
> > We can't remove the scaling option until we make the VRML importer
> handle proper unit selection. I have routinely run into the case where I go
> OpenSCAD -> Wings3D -> KiCad and design a model using mm in OpenSCAD
> because it makes for easier computations (all the datasheet values are
> nicely given in mm) and then have to apply a scaling factor of 0.3937 to
> all the axes in KiCad to make it the proper size because we seem to have a
> hardcoded assumption about what unit system the VRML file is in.
> >
> > In fact, the KLC says: WRL files do not specify absolute dimensions.
> KiCad normalizes model parameters to units of inches and the internal units
> (dimensionless) of the WRL model must be scaled accordingly.
> >
> > -

Re: [Kicad-developers] 3D-Viewer: limit scale to positive values?

[Jon Evans]

Note Altium's solution to the use case of needing "easy basic models": it
can actually generate the models built-in.

You just specify some parameters and it will generate cylinders, spheres,
or extruded shapes from a 2D contour.

If we could add this kind of feature in the future, maybe we would not need
to support "stretching" generic models, as we could just generate the right
generic model parametrically (without "stretching" a source model)

On Tue, Sep 29, 2020 at 2:50 PM Mário Luzeiro  wrote:

> From my user experience: I use the 3 scale values on my projects.
> I created unit solids (eg: 1mm cube, 1mm cylinder radius / thickness, etc)
> and then I use it to quickly create shapes (by adjusting X,Y,Z scale) to
> populate the board if I don't have the proper STEP model.
> This is helpful to create round buttons, push buttons switch house
> packages, displays (attached is an example I made just using 1mm cubes)
> I'm using WRL but I believe it should work if I had used STEP scaled and
> then export it for CAD purposes.
>
> If you remove scale at all, I will need to learn and use a new CAD
> software :/ :)
>
> My suggestion is keep the scale but hide (or disable) it by default on the
> UI and it should only be enabled by clicking on some checkbox, at that
> time, displaying some message to the user "this is not a good idea for
> CAD.."
>
>
> > I'm not sure the history of why VRML was chosen as the first model type
> that was supported
>
> Maybe at that time it was created was a very time consuming thing to
> implement.
> For STEP we need a 3rd part library (as it is very complex format).
> On the current 3D-Viewer implementation, Cirilo worked alone on the model
> importer code alone and it took some months of work..
>
> Mario
>
> ________
> From: Kicad-developers  ua...@lists.launchpad.net> on behalf of Seth Hillbrand  >
> Sent: 29 September 2020 19:01
> To: Jon Evans
> Cc: kicad-developers@lists.launchpad.net
> Subject: Re: [Kicad-developers] 3D-Viewer: limit scale to positive values?
>
> I've never seen another package use VRML.  Everyone uses STEP.  I suspect
> if we were implementing this today, we would look at the tradeoff on
> support/benefit for VRML and limit ourselves to STEP as well.
>
> I like Ian's suggestion for unit options.
>
> -Seth
>
> On Tue, Sep 29, 2020 at 10:22 AM Jon Evans  j...@craftyjon.com>> wrote:
> Do other EDA tools allow model scaling?  Altium doesn't even allow VRML
> import in the first place.
>
> On Tue, Sep 29, 2020 at 1:10 PM Seth Hillbrand  s...@kipro-pcb.com>> wrote:
> Well, we've backed ourselves into a bit of a corner.  VRML is specified in
> meters, so if we're assuming inches, we're a bit off in left field.  But do
> we need three separate scale parameters?  We could reduce to 1, correct?
>
> In the official footprint library, we have 7 footprints that specify
> non-unity scaling. (Banana_Jack_[1-3], NS-Tech_Grove_1x04, Fuse_Blade_ATO,
> Fuse_Blad_Mini, Oscillator_SMD_TXC0_G158).
>
> -Seth
>
>
>
>
> On Tue, Sep 29, 2020 at 9:30 AM Ian McInerney  <mailto:ian.s.mciner...@ieee.org>> wrote:
> We can't remove the scaling option until we make the VRML importer handle
> proper unit selection. I have routinely run into the case where I go
> OpenSCAD -> Wings3D -> KiCad and design a model using mm in OpenSCAD
> because it makes for easier computations (all the datasheet values are
> nicely given in mm) and then have to apply a scaling factor of 0.3937 to
> all the axes in KiCad to make it the proper size because we seem to have a
> hardcoded assumption about what unit system the VRML file is in.
>
> In fact, the KLC says: WRL files do not specify absolute dimensions. KiCad
> normalizes model parameters to units of inches and the internal units
> (dimensionless) of the WRL model must be scaled accordingly.
>
> -Ian
>
> On Tue, Sep 29, 2020 at 4:50 PM Seth Hillbrand  s...@kipro-pcb.com>> wrote:
> There has been some discussion to removing the scale option here
> altogether.  The logic being that if you need the model scaled, you should
> be doing this in your solid CAD not in your electronic CAD.  I have come
> around to this idea and it might be worth implementing rather than doing
> the scale limiting.
>
> -Seth
>
> On Tue, Sep 29, 2020 at 4:52 AM Mário Luzeiro  mrluze...@ua.pt>> wrote:
> Hi all,
>
> I'm wondering if it is safe to limit the scale of shapes to be positive
> values?
>
> Applying negative scales will cause inverted shapes and render issues on
> the models.
>
> Could be that anyone in the world is using negative scale values?
> or should be safe to limit

Re: [Kicad-developers] 3D-Viewer: limit scale to positive values?

[Jon Evans]

Do other EDA tools allow model scaling?  Altium doesn't even allow VRML
import in the first place.

On Tue, Sep 29, 2020 at 1:10 PM Seth Hillbrand  wrote:

> Well, we've backed ourselves into a bit of a corner.  VRML is specified in
> meters, so if we're assuming inches, we're a bit off in left field.  But do
> we need three separate scale parameters?  We could reduce to 1, correct?
>
> In the official footprint library, we have 7 footprints that specify
> non-unity scaling. (Banana_Jack_[1-3], NS-Tech_Grove_1x04, Fuse_Blade_ATO,
> Fuse_Blad_Mini, Oscillator_SMD_TXC0_G158).
>
> -Seth
>
>
>
>
> On Tue, Sep 29, 2020 at 9:30 AM Ian McInerney 
> wrote:
>
>> We can't remove the scaling option until we make the VRML importer handle
>> proper unit selection. I have routinely run into the case where I go
>> OpenSCAD -> Wings3D -> KiCad and design a model using mm in OpenSCAD
>> because it makes for easier computations (all the datasheet values are
>> nicely given in mm) and then have to apply a scaling factor of 0.3937 to
>> all the axes in KiCad to make it the proper size because we seem to have a
>> hardcoded assumption about what unit system the VRML file is in.
>>
>> In fact, the KLC says: WRL files do not specify absolute dimensions.
>> KiCad normalizes model parameters to units of inches and the internal units
>> (dimensionless) of the WRL model must be scaled accordingly.
>>
>> -Ian
>>
>> On Tue, Sep 29, 2020 at 4:50 PM Seth Hillbrand 
>> wrote:
>>
>>> There has been some discussion to removing the scale option here
>>> altogether.  The logic being that if you need the model scaled, you should
>>> be doing this in your solid CAD not in your electronic CAD.  I have come
>>> around to this idea and it might be worth implementing rather than doing
>>> the scale limiting.
>>>
>>> -Seth
>>>
>>> On Tue, Sep 29, 2020 at 4:52 AM Mário Luzeiro  wrote:
>>>
 Hi all,

 I'm wondering if it is safe to limit the scale of shapes to be positive
 values?

 Applying negative scales will cause inverted shapes and render issues
 on the models.

 Could be that anyone in the world is using negative scale values?
 or should be safe to limit it?

 This is related with this issues:
 https://gitlab.com/kicad/code/kicad/-/issues/5817

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

>>>
>>>
>>> --
>>> [image: KiCad Services Corporation Logo]
>>> Seth Hillbrand
>>> *Lead Developer*
>>> +1-530-302-5483‬ <+12126039372>
>>> Davis, CA
>>> www.kipro-pcb.comi...@kipro-pcb.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
>>>
>>
>
> --
> [image: KiCad Services Corporation Logo]
> Seth Hillbrand
> *Lead Developer*
> +1-530-302-5483‬ <+12126039372>
> Davis, CA
> www.kipro-pcb.comi...@kipro-pcb.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
>
___
Mailing list: https://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] mingw64 build issue.

[Jon Evans]

MSVC works great, I really recommend giving it a try.  Much faster compile
time than msys.

Seems like Mark will have a solution for wxPython very soon too :)

On Fri, Sep 25, 2020 at 3:10 PM Wayne Stambaugh 
wrote:

> On 9/25/2020 3:04 PM, jp charras wrote:
> >
> > Le 25/09/2020 à 19:11, Wayne Stambaugh a écrit :
> >> Is anyone else seeing the following error when building with
> >> MinGW64/msys2?
> >>
> >> ../common/libcommon.a(libcontext.cpp.obj):libcontext.cpp:(.text+0x19e):
> >> relocation truncated to fit: R_X86_64_PC32 against `*ABS*'
> >>
> >> I did some digging around and it looks like it's a bug in the context
> >> assembly code but I've never seen the error before.  I tried downgrading
> >> gcc from 10.2 to 10.1 but no luck.  It also happens when building the
> >> 5.1 branch.  It doesn't happen when building with MinGW32/msys2.
> >>
> >> Thanks,
> >>
> >> Wayne
> >
> > I am not seeing this issue.
> >
> > I have a recent (2 weeks) msys install, on a new computer, with W10 -
> > 64bits
>
> Thanks for the feedback.  Maybe something got broken during an update.
> My msys2 install is quite old so maybe it's time to do a clean reinstall
> :(.  I guess all development for me will be on Linux until I can free up
> a decent block of time to upgrade msys2 or maybe try out the new msvc
> stuff Mark has been working on.
>
> Cheers,
>
> Wayne
>
> >
> >
> >> --
> >> Jean-Pierre CHARRAS
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Help needed

[Jon Evans]

Can you run with ASAN on (KICAD_SANITIZE in CMake) and see if you get some
info about why you get a segfault?

On Fri, Sep 25, 2020 at 10:28 AM Franck Jullien 
wrote:

> Hi,
>
> I'm working on the intersheets references functionality and I'm
> struggling with a segfault.
> Until now, I didn't try to remove iref from sheets. Now, I do this with:
>
> void SCH_EDIT_FRAME::RemoveAllIntersheetsRefs()
> {
> SCH_SHEET_LIST sheets = Schematic().GetSheets();
> SCH_GLOBALLABEL* gLabel;
>
> m_labelTable.clear();
>
> for( const SCH_SHEET_PATH& sheet : sheets )
> {
> SCH_SCREEN* screen = sheet.LastScreen();
>
> for( SCH_ITEM* item : screen->Items() )
> {
>
> if( item->Type() == SCH_GLOBAL_LABEL_T )
> {
> gLabel = (SCH_GLOBALLABEL*)( item );
> SCH_IREF* iref = gLabel->GetIref();
>
> if( iref )
> {
> gLabel->SetIref( nullptr );
> gLabel->SetIrefSavedPosition( wxDefaultPosition );
> screen->DeleteItem( iref );
> }
> }
> }
> }
> }
>
> As soon as I call DeleteItem (or RemoveFromScreen) I get a crash.
> Is there something obvious I don't see ?
>
> I still need to get familiar with screens, sheets, frames, canvas,
> views
>
> Thanks in advance.
>
> Franck.
>
> ___
> Mailing list: https://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] High speed tools

[Jon Evans]

Hi Alexander,

For (1) I know Oleg Endo has been doing some work on the Net Inspector to
allow grouping nets for combined length measurement:
https://gitlab.com/kicad/code/kicad/-/merge_requests/187

For (3) the intent was to do this via the new DRC rule system.
The PNS router needs to be updated to take the new DRC rules into
consideration before this will work.

For (2) and (4) I don't think anything is in progress.
Updating diff pairs could be a feature added to the global track/via
editing dialog, perhaps.

-Jon

On Tue, Sep 22, 2020 at 9:32 AM Alexander Shuklin 
wrote:

> Dear all,
> I want to start my first KiCad high speed design and for that purpose I
> plan to make some pcbnew python scripts. I just want to ask if some of that
> tools are expected in the nightly builds (may be I will wait for it or even
> give a hand or contribute)
> 1) tool to visualize nets lengths (similar to
> https://github.com/MitjaNemec/Kicad_action_plugins#length-stats ). I want
> to make a gui where you can define what nets you want to see altogether.
> And it should show you length on each layer and summary. And vias as well.
> 2) Same stuff for length between 2 objects (for example via and pad for
> T-topology) similar to
> https://github.com/MitjaNemec/Kicad_action_plugins#pad2pad-track-distance.
> 3) some tool to define and automatically change tracks length on different
> layers (to match target impedance)
> 4) Tool to work with differential pairs. At least change its width and
> clearance. I think that now differential pairs are just tracks, is there
> some option to change these parameters after they are created easily? For
> example, you change stackup, or you change manufacturer and have to use
> different PCB materials, and after that you have to adjust differential
> pairs.
> ___
> Mailing list: https://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] Placing real components out of a database instead of: "Automatic assignment of footprint with a database"

[Jon Evans]

I think the people suggesting CSV are missing the point of the database
feature (as I see it): collaboration.

Having 5 different people working from a single CSV file is not fun.

-Jon

On Sat, Aug 29, 2020 at 10:26 AM Jeff Young  wrote:

> My point about MySQL wasn’t that *we* should bundle it, but rather why
> some of the contributors to this thread wanted to avoid it (or other things
> that support ODBC) and instead use CSV.
>
>
>
> ___
> Mailing list: https://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] Placing real components out of a database instead of: "Automatic assignment of footprint with a database"

[Jon Evans]

Nobody is suggesting that we bundle any database engine.

If your company doesn't want to use MySQL, and they want to use this
feature, I would suggest Postgres or MariaDB :)

On Sat, Aug 29, 2020 at 9:52 AM Mark Roszko  wrote:

> > Surely there must be an open source impl of an ODBC interface on a CSV
> file?
>
> Yep they do. On Windows, Microsoft actually installs their "Microsoft Text
> Driver" with MS Office which allows ODBC to CSV files.
>
>
> >Although I’m not sure of the desire to avoid MySQL.  It’s remarkably easy
> to set up an instance (or auto-deploy one with an app).
>
> My company has an outright ban policy on oracle (including network level).
> We aren't the only ones too. Oracle intentionally baits users (corporate
> ones specifically) into license violations and is basically a company with
> more lawyers than engineers. MySQL as such is affected/infested by Oracle.
>
> Other than that, bundling a database engine is incredibly messy and a
> world of packaging hell from conflicts, IT policy, MS Group policy, etc.
> Not worth bundling.
>
>
>
> On Sat, Aug 29, 2020 at 9:22 AM Jeff Young  wrote:
>
>> Surely there must be an open source impl of an ODBC interface on a CSV
>> file?
>>
>> Although I’m not sure of the desire to avoid MySQL.  It’s remarkably easy
>> to set up an instance (or auto-deploy one with an app).
>>
>> Apologies if we’ve already talked about that; I’ll confess to not having
>> followed this thread 100%….
>>
>> On 29 Aug 2020, at 14:11, Wayne Stambaugh  wrote:
>>
>> I would most likely reject any solution that was tied to a particular
>> database.  All this would do is open up a Pandora's box of complaints as
>> to why we didn't use database A over database B.  ODBC is the most
>> flexible solution that I am aware of and allows users to choose their
>> preferred database.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 8/29/20 8:29 AM, Jon Evans wrote:
>>
>> Putting aside the fact that I think this feature isn't really aimed at
>> hobbyists, I would not be opposed to people wanting to extend it beyond
>> ODBC but that comes with extra complexity that must be handled.
>>
>> With ODBC, KiCad just needs to know about the interface to retrieve the
>> data.
>>
>> With a CSV file, KiCad actually needs to read that file in and keep it
>> in memory.  Watch for modifications on disk, or else lock it
>> exclusively.  Things like that.
>>
>> I'm not sure I really see the advantage of a CSV-backed "database" over
>> the existing KiCad library system, if we're talking about a single user.
>>
>> -Jon
>>
>> On Sat, Aug 29, 2020 at 8:19 AM Mark Roszko > <mailto:mark.ros...@gmail.com >> wrote:
>>
>> Sqlite was a quick way to test if my ideas would work.
>>
>>There are ODBC wrappers for SQLite
>>
>> I mean libreoffice would do for the management.
>>
>>Yes, and you know what you would use? Not CSV files.
>>LibreOffice Base / Microsoft Access.
>>This is the office suite database that's basically SQLite and there
>>are ODBC wrappers as well :D
>>
>> Also, why would a hobbyist fire up a sql database when a CSV file
>>
>>would be sufficient? I mean libreoffice would do for the management.
>>
>>KiCad's uses aren't limited to hobbyists...
>>And, you assume there aren't hobbyists like me who will gladly take
>>that ODBC link and spin up an frontend in a few hours to the whole
>>system :D
>>
>>
>>On Sat, Aug 29, 2020 at 4:22 AM Johann Wilhelm
>> wrote:
>>
>>Hi there!
>>
>>Well, then my comment was not completely wrong.
>>
>>Sqlite was a quick way to test if my ideas would work. For
>>my future productive system I really want to use a mix of
>>couchdb and maybe postgres. i.e. a JSON document storage for the
>>component information and sql for inventory management.
>>
>>So ODBC would not work well for me.
>>
>>Also, why would a hobbyist fire up a sql database when a CSV
>>file would be sufficient? I mean libreoffice would do for the
>>management.
>>
>>Additionally, I'd suggest looking at the BOM creation. There,
>>external programs are called.
>>
>>So why not define a dataformat (xml, json, csv,...) and just
>>call an external app or read from a file/uri?
>>
>>Anyways, I would volunteer for implementing some alternative

Re: [Kicad-developers] Placing real components out of a database instead of: "Automatic assignment of footprint with a database"

[Jon Evans]

I think this thread has kind of blown up to use cases beyond the original
subject.

While I don't think it's wrong to consider *other* proposals for how people
want to get library data into KiCad, I want to limit this particular thread
(and the linked spec doc to one in particular):

An external ODBC-compatible database, managed outside of KiCad, containing
links to symbols/footprints in existing KiCad library files.

The use case for this is teams collaborating on designs in "private"
Not to be a global community-wide database of parts for all KiCad users,
and not to be an additional library option that adds value to individual
hobbyists using KiCad alone.

It's possible that both of those use-cases can be addressed by building
additional tools (inside or outside of KiCad) on top of this proposed
feature, but I don't want to try to address all those use cases at once.

Best,
Jon

On Sat, Aug 29, 2020 at 9:40 AM Wayne Stambaugh 
wrote:

>
> On 8/29/20 9:21 AM, Jeff Young wrote:
> > Surely there must be an open source impl of an ODBC interface on a CSV
> file?
>
> I'm pretty sure this already exists.
>
> >
> > Although I’m not sure of the desire to avoid MySQL.  It’s remarkably
> > easy to set up an instance (or auto-deploy one with an app).
>
> MySQL has an ODBC plug in.  So does PostgreSQL.  I can't imagine any of
> the commercial databases not having an ODBC plug-in.  The goal here is
> to maximize database coverage.
>
> >
> > Apologies if we’ve already talked about that; I’ll confess to not having
> > followed this thread 100%….
> >
> >> On 29 Aug 2020, at 14:11, Wayne Stambaugh  >> <mailto:stambau...@gmail.com>> wrote:
> >>
> >> I would most likely reject any solution that was tied to a particular
> >> database.  All this would do is open up a Pandora's box of complaints as
> >> to why we didn't use database A over database B.  ODBC is the most
> >> flexible solution that I am aware of and allows users to choose their
> >> preferred database.
> >>
> >> Cheers,
> >>
> >> Wayne
> >>
> >> On 8/29/20 8:29 AM, Jon Evans wrote:
> >>> Putting aside the fact that I think this feature isn't really aimed at
> >>> hobbyists, I would not be opposed to people wanting to extend it beyond
> >>> ODBC but that comes with extra complexity that must be handled.
> >>>
> >>> With ODBC, KiCad just needs to know about the interface to retrieve the
> >>> data.
> >>>
> >>> With a CSV file, KiCad actually needs to read that file in and keep it
> >>> in memory.  Watch for modifications on disk, or else lock it
> >>> exclusively.  Things like that.
> >>>
> >>> I'm not sure I really see the advantage of a CSV-backed "database" over
> >>> the existing KiCad library system, if we're talking about a single
> user.
> >>>
> >>> -Jon
> >>>
> >>> On Sat, Aug 29, 2020 at 8:19 AM Mark Roszko  >>> <mailto:mark.ros...@gmail.com>
> >>> <mailto:mark.ros...@gmail.com>> wrote:
> >>>
> >>>> Sqlite was a quick way to test if my ideas would work.
> >>>There are ODBC wrappers for SQLite
> >>>
> >>>> I mean libreoffice would do for the management.
> >>>Yes, and you know what you would use? Not CSV files.
> >>>LibreOffice Base / Microsoft Access.
> >>>This is the office suite database that's basically SQLite and there
> >>>are ODBC wrappers as well :D
> >>>
> >>>> Also, why would a hobbyist fire up a sql database when a CSV file
> >>>would be sufficient? I mean libreoffice would do for the management.
> >>>
> >>>KiCad's uses aren't limited to hobbyists...
> >>>And, you assume there aren't hobbyists like me who will gladly take
> >>>that ODBC link and spin up an frontend in a few hours to the whole
> >>>system :D
> >>>
> >>>
> >>>On Sat, Aug 29, 2020 at 4:22 AM Johann Wilhelm
> >>> >>> <mailto:johann.wilhelm@wilhelm.consulting>> wrote:
> >>>
> >>>Hi there!
> >>>
> >>>Well, then my comment was not completely wrong.
> >>>
> >>>Sqlite was a quick way to test if my ideas would work. For
> >>>my future productive system I really want to use a mix of
> >>>couchdb and maybe postgres. i.e. a JSON document storage f