You heard it here first: not a tentative plan, a definite plan :) (or at
least as definite as these things get)
Project format will be changing, and the extension will change to kicad_pro
along with it.
The extension change will not apply to the existing file format.
This change is tied to other w
Altium doesn't have "annotate selected"
It does let you lock the annotation on components at will, so you can lock
some, reset everything (which ignores locked) and then re-annotate.
If you change the annotation of one part of a multi-part component, it will
result in two components being forwarded
Thanks Jeff, this is awesome. I look forward to trying it out.
On Sat, May 16, 2020 at 12:00 PM Jeff Young wrote:
> Here’s a really dumb test file just so you can get an idea of what it
> looks like:
>
> (version 1)
> (selector (match_netclass "Default") (rule "Big Gap"))
> (selector (match_typ
Hi Johannes,
Thank you for offering to take on maintenance of the flathub package.
We are happy to have your help with this, and as far as I know none of
the other lead developers was planning on taking it on.
Please feel free to reach out here if you run into any challenges with
fixing the packa
Pushed a fix, sorry about that
On Tue, May 19, 2020 at 1:12 PM Steven A. Falco
wrote:
> I built KiCad 5.99.0-1718-g28b8e7521 for Fedora 32 and found that I cannot
> add a component to a new project.
>
> I opened the schematic, typed 'a', and selected a 1N4001 diode. Before I
> could even try to
You can file this as an issue if you'd like, but it's already planned to
completely re-do this UI at some point once we know what the actual DRC
implementation will be.
We're not doing that yet because the new system is still very much in flux.
On Wed, May 20, 2020 at 3:22 PM Diego Herranz
wrote
, not a work-in-progress."
The kind of feedback we are most interested in at this point is around
whether this kind of system can meet all your needs in terms of defining
design rules.
On Wed, May 20, 2020 at 3:24 PM Jon Evans wrote:
> You can file this as an issue if you'd like,
I am used to, and like better, always placing the best match on top
and removing things that don't match at all.
This is the behavior of most modern text editors and IDEs I've used.
On Sat, May 30, 2020 at 10:50 AM Jeff Young wrote:
>
> One strategy is to highlight the first match as you type, b
Hi all,
A DRC error code is something like "Via inside keepout area", or in
the code, DRCE_VIA_INSIDE_KEEPOUT. It describes a "type" of DRC
error. This type is used for organizing the errors in the DRC report,
and more recently, for letting you set a severity
(error/warning/ignore) for each code
t; > different unique id. I think this would help greatly on near-tapeout
> > activities where sifting over the same DRC errors becomes tedious and prone
> > to missing valid DRC violations in the midst of “designer checked and
> > allowed” ones.
> >
> > Greg S
baugh wrote:
>
> I was thinking along the same lines. Wouldn't it make more sense to
> define the objects that violate a DRC rule and generate the error
> message on the fly rather than adding violation error codes for every
> possible error?
>
> On 6/11/20 9:26 A
"this rule is very important and
> should be treated as an error" and "this rule is just a guideline and can be
> treated as a warning" while they are both the same error code would make more
> sense.
>
> -Ian
>
> On Thu, Jun 11, 2020 at 2:53 PM Jon Evans wr
> should be treated as an error" and "this rule is just a guideline and can be
> treated as a warning" while they are both the same error code would make more
> sense.
>
> -Ian
>
> On Thu, Jun 11, 2020 at 2:53 PM Jon Evans wrote:
>>
>> The only
us? The only things the error code gives us is a string
> and a severity. The data storage (items, locations, etc.) is already
> completely orthogonal.
>
> > On 11 Jun 2020, at 15:36, Jon Evans wrote:
> >
> > But couldn't this taxonomy be separate from the D
In Altium (and I suspect in other commercial tools) there are two
different types of pad behavior: when creating/editing/viewing
footprints, and when working on the board.
When editing footprints, you only have the concept of top, middle, and
bottom layers. You don't know the full board stackup.
ions for via annulus (a production
> constraint) and via size (possibly just a current/heat constraint).
>
> I’m still on the fence with throughVia drill vs. uVia drill. The rest I can
> agree with.
>
> Cheers,
> Jeff.
>
>
> > On 11 Jun 2020, at 15:56, Jon Evans w
t;
On Thu, Jun 11, 2020 at 1:13 PM Jeff Young wrote:
>
> Imagine that violating the micro-via min bumps me up a classification but
> violating the through-via min drops me out of pooling. There’s a big cost
> difference between those two.
>
>
> > On 11 Jun 2020, at 1
Yeah I like this.
For the basic rules, we could still make it so that each basic rule had
independent severity while generating common error codes, although that
increases complexity. It might be better to keep one error code per "basic"
rule, except for the ones we are already in agreement can be
-built selectors and use the same mechanisms for specifying the severity
> of them as custom rules would. I think that is also nicer, because it
> essentially provides an example rules file.
>
> -Ian
>
> On Thu, Jun 11, 2020 at 6:40 PM Jon Evans wrote:
>>
>> Ye
. It’s
> pretty easy to agree on priority of all the edge case (pad override,
> footprint overrides, netclasses vs. board settings, etc.), but there’s
> nothing uniform about them.
>
> > On 11 Jun 2020, at 19:35, Jon Evans wrote:
> >
> > That has yet to be determine
I have also wondered why many large C++ projects, including KiCad, don't
use the explicit integer types. The embedded codebases I've used always do.
I've never brought it up before, so I'm also curious to hear if this is
just a legacy decision or if there is a reason.
-Jon
On Sat, Jun 20, 2020, 1
Hi Roberto,
Welcome! Thanks for pointing that out about Altium, I learn something
new every day!
I recommend that you open a merge request for your CADSTAR importer
once it is far enough along for people to do some basic tests. You
can mark it as "WIP", but having the MR open early will help ge
Hi all,
I wanted to make it more clear what the remaining work is for 6.0, so
I created a new "6.0 Feature Freeze" milestone separate from the
6.0.0-rc1 milestone that already existed:
Those with permissions to assign milestones on GitLab: please assign
wishlist/feature-request items to the Featu
Hi Jeff,
Yes, I think anything you are playing with or working on should / can have
the milestone, even if it's not required for 6.0.
We mostly thought it would be good to remove the milestone from things that
are not assigned to anyone in GitLab and that nobody is currently working
on or plannin
I tried to change the Milestones section to the below text, but
GitLab's website is currently only half-working for me:
# Milestone
Attaching a milestone to an issue is intended to associate the fix for
the issue with a target release. If an issue is present in two
branches, target it to the mile
Yes, that's what I was intending
On Fri, Jun 26, 2020 at 10:21 AM Wayne Stambaugh wrote:
>
> I should replace the entire "Milestone" section with the text you
> provided correct?
>
> On 6/26/20 10:13 AM, Jon Evans wrote:
> > I tried to change the Miles
Currently, KiCad automatically creates backups of schematic and PCB
files when you save a file.
The logic for these backups is basically: if a file already exists
with the same name as what we are saving, copy that file to a new file
and give it the "-bak" suffix on the file extension.
These back
something goes wrong before
> reaching this point, you can restore from the bak.
>
> On 6/29/20 12:23 PM, Jon Evans wrote:
> > Currently, KiCad automatically creates backups of schematic and PCB
> > files when you save a file.
> >
> > The logic for these backups is basi
JP, I agree that true backups are useful.
Maybe even it is a good idea for KiCad to have a built-in backup function.
I just don't think the current backup function is actually useful
because of my first point (backups are overwritten on each save).
I would propose:
1) Remove the current backup
t; As limited and simple as it is, the current system provides valuable
> safeguard against data loss on crashes that may corrupt the main save file.
> And no, VCS is not a replacement, most people hit ctrl-s a lot more often
> than they do "git commit".
>
>
> On Tue
; Especially if you change your mind after 2h working on something which is not
> going anywhere :)
>
> Thanks,
> Diego
>
> On Tue, 30 Jun 2020 at 15:15, Wayne Stambaugh wrote:
>>
>> Sounds like a great solution to me.
>>
>> On 6/30/20 10:12 AM, Jon Evan
Hi Joël,
As Dino mentioned, buses in KiCad work just like net labels: Another
bus with the same name on the same schematic sheet will be connected,
the same way that two pins will be connected if you place the same net
label on them (even if you don't draw a wire between the pins).
If you send m
I think 1 and 2 (I assume you mean the OpenGL renderer of the 3D
viewer) are good ways forward for the short term.
The DRC system is in a period of heavy change right now so it's
probably best to wait until the dust settles a bit before adding new
checks to it.
Best,
Jon
On Sat, Jul 4, 2020 at 1
Hi Reece,
Could you open a merge request for this branch? You can mark it as
WIP by putting "WIP: " in the beginning of the title.
Doing so will allow people to review it more easily (even if it's not done)
Thanks,
Jon
On Mon, Jul 6, 2020 at 12:21 PM Reece R. Pollack wrote:
>
> On 7/3/20 9:22
where that describes the process for requesting merges
> and such to KiCad's code base?
>
> -Reece
>
> On 7/6/20 12:24 PM, Jon Evans wrote:
> > Hi Reece,
> >
> > Could you open a merge request for this branch? You can mark it as
> > WIP by putting "WIP
build system in Python looks
like a headache to integrate.
I have not looked at SWIG yet. OCC it seems like is in progress (we
are less worried about that one)
-Jon
On Tue, Jul 7, 2020 at 7:31 AM Mark Roszko wrote:
>
> Nope, I'm building straight out of vcpkg now.
> Jon Evans posted
significantly complicates things as we will have to provide a build for
> every supported version of Python that could be installed on someones
> system. There is a big advantage with the current way we handle Python
> on windows.
>
> On 7/7/20 8:59 AM, Jon Evans wrote:
> > Yes, wx
straw that breaks the msvc camel's back. If we are
> tied to the installed Python on windows, the amount of effort required
> to package KiCad on windows increases significantly. Shipping KiCad
> without Python on windows is not acceptable.
>
> On 7/7/20 2:36 PM, Jon Evans wrot
Shouldn't the origin be stored in the design data (BOARD / SCHEMATIC)
rather than the base frame?
It seems like all data about objects, including their coordinates in
the coordinate space defined by the user, should be available just by
parsing a board or schematic file (which should be independen
n the file, then it
> should be in the BOARD/SCHEMATIC like Jon said (which is easy to access from
> the BOARD_ITEM or SCH_ITEM).
>
> Cheers,
> Jeff.
>
>
> > On 10 Jul 2020, at 18:25, Jon Evans wrote:
> >
> > Shouldn't the origin be stored in the desi
RAME object and perform the needed transformations.
>
> This works for everything that can find the EDA_DRAW_FRAME object, like
> UNIT_BINDER. The GetMsgPanelInfo functions take an EDA_DRAW_FRAME
> pointer as a parameter, so this isn't a problem. However, the
> GetSelectMenuTe
; On 7/10/20 3:00 PM, Jeff Young wrote:
> > I agree on both points: units and transform should be saved in the project
> > file, and they should be passed to GetSelectMenuText as parameters.
> >
> > Cheers,
> > Jeff.
> >
> >
> >> On 10 Jul 2020
pass them as two individual arguments to
> the GetSelectMenuText function.
>
> -Ian
>
> On Fri, Jul 10, 2020 at 8:40 PM Jon Evans wrote:
>>
>> It would be preferable to make it possible to call GetSelectMenuText
>> (or really, any facility that needs access to the cu
atypes are needed in other places at the same time, then I could see
> the justification.
>
> -Ian
>
> On Fri, Jul 10, 2020 at 9:30 PM Jon Evans wrote:
>>
>> The way I see it, there is one package of information that we should
>> be delivering: how to turn internal units
Hi Josh,
Please see the GitLab documentation on how to create a MR:
https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html
We also have some KiCad-specific MR guidelines:
https://gitlab.com/kicad/code/kicad/-/wikis/Merge-Request-Guidelines
In general: you will need t
Hi Conrad,
We are working towards removing all the UI dependencies (already the
latest state-of-the-art is way better than the 5.1 branch in this
regard). We are also working towards a more stable Python API.
One of the goals of this work is to enable some of the features you
mentioned (automate
Good point, Andrew.
I normally have my fork as "origin" (which will be the default when
doing push/pull operations).
I set the main KiCad repository as a remote called "upstream" (this
name is just my personal choice, it can be anything)
That way by default I am just interacting with my fork, bu
Lead Developer
>> > +1-530-302-5483
>> > Davis, CA
>> > www.kipro-pcb.comi...@kipro-pcb.com
>> >
>> >
>> > On 2020-07-13 21:00, Tim Hawkins wrote:
>> > > Would it be possible to consider using swig to create the Python
>>
If you know a version that builds (you said late June worked) you can
do a git bisect against a commit from back then and eventually this
will tell you which commit changed the behavior
On Wed, Jul 22, 2020 at 5:58 PM Brian Piccioni
wrote:
>
> You can't imagine how happy it makes me feel to know
1:10 PM Brian Piccioni
> > > mailto:br...@documenteddesigns.com>
> > <mailto:br...@documenteddesigns.com
> > <mailto:br...@documenteddesigns.com>>> wrote:
> > >
> > > Perhaps what I can try and do is a binary search for the last
>
Local rules will be done with zones: you can give a name to a copper or
keepout zone and use it to define a rule. If you want a zone that is only
used to define a rule and has no other effect, use a keepout that has no
restrictions set.
Regarding castellations, I think we should study an example c
Hi Fabien,
I know Ian had some thoughts about this so hopefully he has a chance
to review this document soon and reply.
We have not been using MRs to discuss specifications previously, so I
would say we can keep the discussion in that document until people
actually start writing code (unless the
There is a start of one here:
https://docs.google.com/document/d/1zD0CoBcFqf5v9QT8dabgq2S4BGytL4zJJD71IOCkrss/edit
Best,
Jon
On Sun, Jul 26, 2020 at 1:31 PM Roberto Fernández Bautista
wrote:
>
> Hi all,
>
> I thought I'd send a message here regarding
> https://gitlab.com/kicad/code/kicad/-/issu
From this comment, maybe Simon has something that is not published yet?
https://gitlab.com/kicad/code/kicad/-/merge_requests/85#note_282728454
On Wed, Jul 29, 2020 at 7:34 PM Seth Hillbrand wrote:
>
> On Wed, Jul 29, 2020 at 4:16 PM Roberto Fernández Bautista
> wrote:
>>
>> Hi all,
>>
>> I see
Tom just pushed a fix for this
On Wed, Jul 29, 2020 at 7:26 PM Niki Guldbrand wrote:
>
> Hi.
>
> I was trying to build the master branch right now, but I get a CMake
> error for 5.99.0-2470-gb06c15876:
>
> -- Configuring done
> CMake Error at common/CMakeLists.txt:438 (add_dependencies):
> The
Hi Brian,
This merge request is still marked as WIP, which is probably why it's
been flying under the radar. If you consider it complete and ready
for a review, please remove the WIP status from the title. From the
comments, it wasn't clear if you were still working on changes to the
UI based on
Hey Mario, I'm probably your friend here!
The COLOR_SETTINGS is used for the switchable color theme system.
It is not used for board-specific colors, for example if someone wants to
customize the soldermask color of a particular board.
So, would you want these lighting settings to be tied to the
Can you see if it's fixed by abc64f22?
On Sun, Aug 9, 2020 at 6:16 PM Roberto Fernández Bautista <
roberto.fer@gmail.com> wrote:
> Hi all,
>
> I just rebased my branch to master and got the following errors unrelated
> to the changes in my branch (compiling in MSVC, Windows 10)
>
> Severity C
https://gitlab.com/kicad/code/kicad/-/issues/4911
On Sun, Aug 16, 2020 at 5:15 AM Jonatan Liljedahl
wrote:
> Hi,
>
> It's been a while since I synced my git clone, and now I noticed that
> my symbol library is read-only because it's in the old file format.
>
> When trying to save it, it asks me
I won't speak for Jonatan, but installing after a full build on MacOS takes
significant time. In fact, if I'm changing a single file and recompiling,
doing the install probably takes ~10x longer than the compile. So, for
iterating quickly, it's not great.
On Wed, Aug 26, 2020 at 5:22 PM Nick Øst
Hey Martin,
This is a concept I've been working on in the background (managing
libraries through a database, including footprint assignments but also
fields/properties)
The way I was thinking about approaching it is not just a filter in CvPcb,
but actually a new type of library (including a new p
deas and time to contribute to this effort.
>
>
Happy to have your help!
-Jon
>
>
>
> On Aug 27, 2020, at 2:22 PM, Jon Evans wrote:
>
>
> Hey Martin,
>
> This is a concept I've been working on in the background (managing
> libraries through a data
Hi Martin,
On Thu, Aug 27, 2020 at 3:55 PM Martin Marmsoler
wrote:
>
> On 8/27/20 9:41 PM, Jon Evans wrote:
> > This is basically what I'm thinking, except I was planning to
> > integrate it into the symbol chooser as well (so no need to open cvpcb
> > if you do
I think the system I am describing could easily link to Part-DB as the
backend, just looking at it briefly.
That could be a cool application.
-Jon
On Thu, Aug 27, 2020 at 4:16 PM Martin Marmsoler
wrote:
>
> On 8/27/20 10:04 PM, Jon Evans wrote:
> >
> > You can also choos
> Am Do., 27. Aug. 2020 um 22:26 Uhr schrieb Jon Evans :
>
>> I think the system I am describing could easily link to Part-DB as the
>> backend, just looking at it briefly.
>>
>> That could be a cool application.
>>
>> -Jon
>>
>> On Thu, Aug 27, 2
Hi Clemens,
On Fri, Aug 28, 2020 at 9:34 AM Clemens Koller wrote:
> Hello!
>
> This is related to the previous thread: "Automatic assignment of footprint
> with a database"
>
> I would generally prefer assemble real components on a real PCB right from
> the beginning instead of first placing gen
the proposal). With such an
>> interface, as has been pointed out already, data-source-specific
>> implementations should be relatively straightforward, and then I don’t have
>> to potentially throw away my years of privately curated data or figure out
>> how to cram it into some al
ich could
> read from files and/or web resources, well, never mind my comment :)
>
> With "global parameter" I mean something which could be part of a .pro
> file.
>
> Regards,
> Johann
>
>
> Am Fr., 28. Aug. 2020 um 19:04 Uhr schrieb Jon Evans :
>
>>
ice 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?
>>
:
> >>
> >> 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 so
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
>>
>&
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, b
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 t
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 t
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 Sta
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 fie
n 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: J
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
"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 c
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, inclu
etty 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 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 bef
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
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
egular (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
> wi
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 2
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 thin
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=a
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
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 4
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=&issue%5Bmilestone_id%5D=
Thanks,
Jon
On
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 Константин Барановский <
baranovski
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 -
>
>
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
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
> s
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 n
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
>
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/co
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:
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-b
201 - 300 of 847 matches
Mail list logo
