Welcome everybody to the open source computer-aided modeling and design dev room and the KiCad project status talk. For those of you who don't know who I am, my name is Wayne Stambaugh.

I've been the KiCad project leader now for about eight years. So let's get to it. I'll try to get through this quick so we leave some time for a Q&A at the end. So what's been going on with the KiCad project? One of the things I got a little flak last year about my talk,

it turned out that that talk ended up being a bit more prophetic than I had intended it to be. Given the COVID issues and the shortage of ventilators, the open ventilator project was started early in 2020. KiCad drove that, and I think it really shows the power of

open hardware design and how open software will drive that and allow that to happen. I don't want to talk about it too much, but if you get a chance, go take a look at it.

It's really impressive what was done in a very short amount of time. So onward with what's been going on in the KiCad project. What most people I'm sure are interested in, version six was feature freeze, happened on October 1st. So the goal is to get version six

stable release planned for the end of Q1. I don't know if that's going to happen. We were hoping to have a RC1 out by now. We've had a few setbacks, so that may get pushed back to end of Q2, but it should be close to that timeframe. We've released the 5.1.9, the

ninth version of the 5.1 stable series on December 28th. We initiated a funding campaign from December 15th to January 15th of this year that resulted in more than $14,000 of donations.

Along with that came a dollar match guarantee up to 10K. So the KiCad Services Corporation kicked in an additional $10,000, bringing the grand total to just over $24,000. So thank you to everyone who donated to that. All the project repositories have now been moved

to GitLab. So the libraries, the website, all the build stuff is now on GitLab. So the entire project's in one single place. We also had two new developers promoted to the

development team. One thing that was a pleasant surprise last year was there was a big uptick in new developer contributions. So that looks good. The project seems to be very healthy in terms of contributors. We moved the translation to Weblate to give more people an opportunity

to provide translations. It's a little less technical, a little bit easier for users to contribute. So we've seen a nice bump in the translations. One thing that you will notice if you've been playing around with the

nightly builds is the graphical, all of the user interface icons have changed. So we hired a graphics designer to create a new theme. Love it or hate it, at least it's consistent now. And out of that grew a policy to ensure that any new bitmaps that are added

will stay consistent with the theme. So hopefully that improves KiCad's consistency, which is one of the things that many users have complained about.

KiCon 2021 is planned for September at CERN. Unfortunately, we didn't get to have it this year in 2020 due to COVID. So the plan is to return to CERN live. We don't have a date set for that yet, but I expect within the coming months, you'll see more information about that.

So what's new with version six? Keep in mind, this is not a complete change set. It's just the large user facing changes that you'll notice. There's hundreds of other smaller changes that are every bit as significant, but aren't on this list. There's

also a few that didn't make the feature freeze, which may happen between now and release time. So I didn't put those on either in case that changes. So obviously we have a new theme and that helped. We also did a good job of improving the user interface coherence for

all of the windows and dialogs and the user interface. We switched the configuration file format to JSON, gives us a little bit more flexibility. We also broke a lot of the

configuration files from their previous. We still have lots of stuff stored in small bigger files. We now broke it down into smaller files for project portability. We now support multiple version configurations. So when you run

version six for the first time, you'll be asked if you want to support multiple versions. And so you can keep an old version of Ki-Kat around with its own set of configurations. If you're not comfortable migrating to the new version just yet,

we've completely removed the legacy canvas that's gone. We now support custom color themes. So all of the editors have separate color themes, which can be maintained in a separate config file so that you can have per project themes if you prefer, or you can move them from

machine to machine fairly easy. We also added info bar support. One of the things we like, we try to do is reduce the number of modal information dialogs that require you to stop and move to the next thing. So that I think a lot of people will find that happy. We also added

global variable text expansion. So most text objects now export variable expansion. So the project manager received a few changes. There's now a project archive utility. CatStar projects are imported like Eagle projects. The project file format also was changed to JSON.

Symbol and library editors are now usable with no project loaded. So you can edit your global symbol and footprint library editors without having a project open. The project tree view files now are moved to trash instead of a straight delete to give users a little bit more safety.

And there's a save as function now that you can save a whole project to a different a new name to a new project name. The schematic editor, the new file formats for the schematic

and library symbols has been completed. Library symbols are now embedded in the schematic file. So that means you no longer have to take the symbol libraries with you to make sure that you don't lose your connectivity information. So that's a big plus.

We fully support copy and paste now with the clipboard. That's that's a real nice feature instead of the old copy and paste that we had before. Lines, wires and bus color width and styles can be individually changed. So not only do you have a custom color theme, but you can

change your all those features individually as well. The same holds true for the junction colors and the diameter. So you can have an individual junction color and diameter if you're trying to call out attention to something on a schematic.

We now have user defined page numbering. So any valid string you can use to as a page number. We also added back annotation from the board. So if you change a footprint or a reference designator on the on a footprint on the board, you can push those changes back

to the schematic editor and then save them. There's been lots of wire drawing, wire drawing tool improvements, custom color themes also supported by the schematic editor as well.

There's been a significant improvement in the bus definitions. There's also an unfolding tool that allows you to expand buses. It's a real handy tool when you have large complex buses. There's also some background bus connectivity testing that is really handy in

version six, which doesn't exist in five point one. Along with that came a bunch of electronic rules checking improvements. There's also a object property editing tool similar to what we have in the board editor, allows you to change project or object properties like text size

across multiple objects. It's not quite as nice as what we had hoped to get with the inspector, but that didn't make it into version six. The hierarchy navigation tool can stay open now while you're editing. So it's easier for you to

move from sheet to sheet. We also add a inner sheet references. These are sort of like hyperlinks to other sheets from the current sheet that you're working in. So we made, there's a lot

changes to the new symbol library editor as well. There's obviously the new symbol file library format came along with the schematic file format. We improved the inheritance model from the old model. Now you can derive objects from a base

symbol and change all the fields or add additional fields that weren't in the base field. There's now support for alternate pin definitions. So if you do a lot of design with micro controllers where a pin can have four or five different functions, you can now support that

in the symbol editor and the schematics as well. There's a conversion tool. So if you want to convert your legacy libraries over to the new file format, there's kind of a one-click tool to do that, and it will update your library tables accordingly.

Legacy libraries are no longer saveable. They're read-only now from here out. So you'll be able to use them as is, but you won't be able to take advantage of any of the new features in legacy libraries. We now have cut, copy and paste symbols between libraries. We also support cut, copy and paste graphical items between symbols or in the same symbol. So the clipboard

support for the symbol library editor has been significantly improved. We've also added flags for bill material and board-only symbols. So you can determine whether a symbol shows up in the bill materials or on the board exported to the board net list or only shows up in the

schematic itself. So what about the board editor? The board editor received a new appearance panel that along with the appearance panel comes selection filtering, which allows you to turn on

and off different objects. So when you do block select that you can ignore them or not. The appearance panel also provides, you can set up custom views. So if you have different visibilities, layer visibility, layer, et cetera, for a view, you can create your own views

instead of the old fixed views that were in 5.1. We now have selection grouping so you can group objects by name. We didn't get done the grouping between the schematic editor and the

board editor. So right now that's primarily just for the board editor. Hopefully that'll happen in version 7. One thing that was not on the original version 6 roadmap was custom design

strengths and a rules editor. We now have logic-based design rules. It's somewhat like programming language. Most other major design tools already have similar things in their products. So we now have it as part of KiCad. So that was an unexpected

new feature that happened for version 6. The design rules are now saved in their own file so that you can export them to other projects instead of being embedded in the board. It makes them a little bit more usable for projects and other projects. Along with the new design rules

came a whole slew of design rule check improvements. You can now set the severity of design rule errors and you can completely ignore them if you so choose.

We made some major improvements to the DXF import and export utilities. We added some additional dimensioning tools. That was a big plus. We now have a full layer

stack manager which allows you to include things like layer thicknesses, impedance matching. These are all definable and can be exported to the Gerber X2 file formats when you export

your Gerbers for manufacturing. We added 13 new user-defined layers. So that's new. And now all the layers can be renamed. Previous to version 6, only copper layer names can be removed. We added support for curved tracks. So

for those of you who are doing RF and don't want segmented tracks, we now have true curve support in the board editor. There's been a whole host of push and shove router refinements that make the behavior a little bit more predictable, which is nice. We've added

an option to the rat's nester to allow you to have curved rat's nest instead of straight rat's nest. So in high density designs, the curves are a little easier to see where

the rats begin and end. We also now have net coloring as well. So you can make each rat a different color if you prefer, or you can change the default color if that's what you like. We now have import for SVG files. We added thermal relief for custom pads.

You had to do that manually in previous versions of KiCad. We also now allow arcs and polygons on non-copper layers. Hatch zone support is new. We have

a whole bunch of, that was a feature request that's been a long time coming. We also have multi-layer zones, so you can draw a single zone and put it on multiple layers instead of having to draw each one individually. We now support

castellated edge connections on the board edges. You can drag footprint and keep the traces connected, although it doesn't maintain design rules, so that's not fully fleshed out yet. It's a decent first step. You can add opacity to 3D models, so it allows you to

look through the models and see the board on the 3D when you're looking at 3D views. Once again, we really made some significant improvements to the default color scheme so that you can leave all your layers enabled and still have reasonably good visibility.

As I mentioned earlier, you can now back annotate from the board to the schematic, and along with that came a geographical annotation feature, which allows you to change all your reference designators by geographical location.

So that's pretty nice if that's something you're interested in. We've also picked up Altium and Fabmaster, which is Orcad Ascii board importers. Those are big, important features. A lot of customers have been asking for those. We didn't quite get the schematic support for those in, but at least the board support is

solid. So the footprint editor also got the new appearance manager. Obviously, along with that came object selection filtering and custom layer visibility presets.

There were some big improvements made to object snapping, which makes it easier to align things when you're drawing footprints. You can now add rules or what are known as keep out areas and footprints. You can also add edge cuts to footprints, which get

combined with the edge cuts in the board to create a full outline. We have chamfered rectangular pad support was added. We also added a custom chamfered and rounded rectangle pads, which means you can

basically set the chamfer or rounding on each corner individually. It's a way to prevent the need to have to do full custom pads if that's something you need. That was by no means all of version six, but those were the most of the big

things in version six. As of now, the version seven roadmap is still in flux and it's still being fleshed out. Things on this list may or may not change between now

and when we start working on version seven. But these are the things that we'd like to see happen for version seven. We'd like to see Altium library support right now. We just import the the board. There is schematic support, but it's still a work in progress.

And whether that makes it into v6 or not remains to be seen. There's been a lot of people have requested database driven atomic libraries. So we'd like to do something like that, have that for v7.

We are now to the point we have so many libraries. Our library's support is quite good. But the problem is we have so many footprint and symbol libraries that running them in the foreground takes quite a while. And it's so we need to consider background loading them on startup. So that's something we want to add for v7.

We'd like to improve our pings exports for third party tool chains for things like visual diffing, visual differencing tools. We also want to provide an output automation tool that will allow all

build outputs or all manufacturing outputs to be created in this one time. That's something that's been requested for a long time. We'd like to consolidate our overlay widgets into a single system. Right now, we have several individual

overlay widgets that allow you to see things like dimensions while you're drawing. We need to improve that. We want to allow keyboard access to all tools via an overlay UI widget. One of the problems is that KiCad's getting complex enough now that we're running out of hot

keys. So we need a way to chain keystrokes together to allow us to access all tools via keyboard. One of the things we also would like to do is add a BGFX graphic abstraction layer. This would give us direct support for Metal on Mac OS and use the native

Windows graphics layers instead of always using OpenGL. We'd like to provide a custom tooltip widget

that will allow improved rich contextual help instead of just the simple tooltips. We want to embed the worksheet into the schematic and board files instead of being externally linked. This should clean up things as far as portability.

We want to improve the grouping support between both editors so that we can do things like create what are called rooms in Altium. You can group things together so that you can make duplicate copies of schematic groups and related board groups.

We would like to allow multiple boards per schematic. Right now, KiCad is limited to a single board per schematic, so we want to allow the grouping to support multiple boards so you can lay out multi-board designs using a single project.

Initially, we'd like to create a multiple document interface that supports having more than one project open at a time. Whether we can support multiple boards and schematics at the same time in a single project, that may or may not happen, but at the very least,

we'd like to do multiple projects. We would like to get rid of the standalone schematic and board editors and just have a single binary and just emulate the standalone mode. It causes us some issues and some additional code complexity, so I think that's

something we're going to try to do. We'd also like to have a true net tie implementation from schematic through to board. Right now, we have some crude hacks in there that we use to emulate net ties, but it's not a complete solution. One thing we do want to get done is the

object properties editor, so that didn't make it into v6. Also, pinning gate swapping, which we were hoping would make it into v6, also needs to be done, is on the version 7 roadmap.

As far as the schematic editor, we want to unify the symbols browser or symbol viewer in the footprint assignment tool, so we can have a single symbol tool instead of having three tools that do very similar things. The object inspector, hopefully that will happen too.

We want to allow editing power symbols and schematics so that for custom voltage buses, you don't have to create a new power symbol. We have a lot of visual enhancements for graphical and text objects we'd like to make. We want to support non-hierarchical multiple sheet schematics. In other words,

it's a flat schematic from multiple files so that you don't have to use sheets. There's a whole bunch of splice simulator improvements we want to make. The Eagle Importer doesn't quite yet support hierarchical sheets, so that needs to be fixed.

We want to finish the complete inheritance model so that you can do more complex inheritance. Right now, it's just a simple model that allows for field changes. We want to add stack symbol pins for

large ASICs and micros that have lots of ground and power pins, so you only have to add a single pin and then they get broken out for the footprint. Actually, the symbol alternate pin definition was actually made it into version six, so

that's actually done. For the upcoming changes of the board editor, we want to use the new design rule engine for fine searching on real complex design. The current searching

tool is a little weak. We want to have a push and shove footprint placement tool so that you can move footprints around just by picking up a footprint and pushing the other ones out of the way. We want to have multi-grid support. We want to support local

and prioritize Cartesian and polar grids for improved snapping and placement. Pad and via stacks are definitely going to happen for version seven. This is kind of a must for importing other projects. We want to add a zone manager. Rather than having to manage each zone individually, we would like to have a

top-level zone tool that allows you to see the priority and manage all zones in one place. Automatic neck down feature for the push and shove router for high density BGA layout. We want to change the footprint file format to allow multiple

footprints in a single library and also with compression. We want to create a board outline, a true board outline object that would allow us to define more accurately, define holes and board out cutouts and board outlines.

We'd also like to add a stack up support so that we can do things like milling for flex circuits. We don't currently support that yet. Right now we have a unidirectional 3D viewer cross probing. We'd like to make that

bi-directional. We'd like to have a real implementation for guard ring zones and tracks. We'd like to have a granular locking feature so we can do things like lock move. Right now our locking is pretty coarse, so we would like to do that selection locking, etc. We'd like to improve the push and shove router to handle multiple net

bus routing via placement modes. We need to overhaul the 3D model library lookup to use a table-based system similar to the other libraries. We need a BGA fan out tool,

which will go along with the breakout tool. IPC 2581 support is scheduled to make it into 7.1. That's it for most everything. As always, I'd like to say thanks to all the developers who

contribute their valuable time and talent to the KiCad project. Thanks to them, KiCad happens. It takes a lot of people to make KiCad the project it is. I'd also like to thank all of

our sponsors and everyone who has generously donated to KiCad. I think the donations keep going up every year and I think that's a testament to the strength of the project. Thank you everyone for your interest and continued support of the KiCad project. I'd

like to make a special thanks to Seth Hillbrand who volunteered to be the Dev Room lead. It's live or virtual so thanks to Seth and hope to see everyone live at KiCon 2021 because hopefully this will be my last virtual talk ever. Hopefully the rest of them are all live.

Thank you for attending my talk and talk to you at the quiet Q&A. On the number of features that KiCad 6 is bringing into our ecosystem. Can you just describe

what was the one that you are most excited about the users having access to in KiCad 6?

Oh man, there's so many good changes. I just think the overall polish of the UI is probably going to be one of the most noticeable things for users. Yeah, there's a lot of new features,

but even the features that already existed in 5.1, just how much better the usability is. I think the new icon set, just the overall look and feel of KiCad is a lot more polished

and refined. I mean, it's not like there won't be weak spots there. Any open source project, there's always going to be places that the corners of KiCad that needs some love. But I think that for the Schematic Editor, the primary tools, the Schematic Editor and the Board Editor and the two library editors, I think we've done a really pretty good job of

kind of unifying the behavior between all those editors. And I think that's probably for me, as the project leader, I like to see that kind of growth of the maturity of the project itself.

New features will come over time, but it's nice to see that kind of cohesiveness that we've really lacked for a long time. And we've been working slowly towards that over time, but I think version six is really a big step in that direction. So yeah, I think that's as far as forward facing

for the user is probably the thing that I'm most excited about. Okay, that is, that's really an important point and I couldn't agree more. I've done,

I've had to go back to version five a few times. We do support questions for it. And every time I go back, I'm just, I'm astounded by the shift in how much easier version six is to use just for everyday tasks than version five. So on the backend, there's a question on what,

where the get diff friendliness. So the, so how, how we handle revision controls has changed with the new schematic file format. Like where does the,

where does the revision control friendliness come in, in version six? Well, we've made quite a few, I mean, obviously the file format's completely different, but there were some changes in the parsers and the, and the, and the format specifically the format or to try to maintain things in as orderly fashion as possible. So

when you make changes to your schematic, the diffs won't be quite as severe as they used to be with the old legacy file format. There's still a few places yet, cause internally, we still have a few things to fix in version seven that will improve that. In particular,

grounded, you know, power symbol annotation tends to change. I think some of that's been mitigated by the work John did, but there's probably still some places where we can do some get diff improvements, but I think it's certainly a big step

up from where we were with the old legacy formats. Right, right. So this is one of the questions that came up is that didn't quite get mentioned and proudly deserves to is our,

is our new Python API for version six. And this is one of the feature freeze exceptions that has been lagging. And that's, that's, largely, largely on me. But, maybe you can address real quick. We are going to have a stable Python API in version six,

and that people will be able to, that is disconnected then from the, from the internals. Yeah, there's, there's several reasons that I didn't mention that for one, because it hasn't been committed yet. I, as, as if anybody who ever knows anything about running

open source project is, you know, I, I can only, I can't speak on everybody's behalf, you know, so until that gets committed and it's actually part of the code branch, I, or a part of the development branch of key cat, I don't want to commit to anything that hasn't been done yet. So

I know we're closed and we're getting there. And the goal is to definitely have a stable API for version six. It's just at the time of the, uh, when I recorded the talk, obviously that was a couple of weeks ago. It still hasn't been in, but I know we're getting close and I've been, I, I talked to the developing development team regularly to keep

track of where we are with, with the outstanding freeze exceptions, but I didn't want to, you know, I don't want to commit to, you know, I don't want to publicly say something in talk and then it doesn't happen. And somebody goes, Hey, you said that. So it was to really try to avoid, um.

You know, you know, overextending the project. Where we shouldn't probably do that. So, uh, but yes, like there, it's looking like the API will be ready to go shortly here. And hopefully it looks like we lost Seth, but, um, yeah, it looks, it's going to happen. It's and it's just a matter of

when we get it committed. So, oh, you're back. Okay. Yeah. No, I, um, I was just testing. We don't have the follow me, uh, turned on right now, which, uh, normally seems to

focus on the speaker. This one seems to be focusing on me, even though I'm not the one talking. Uh, so, um, but let's see, we, we have a couple more really good questions. So for example, uh, uh, Jay Hahn was wondering how risky is it to start using CCAD version six development right now to test out all these, uh, awesome new features?

Well, it, except for the few exceptions, um, it, the feature sets frozen. So, uh, and that includes the file formats. So you're not going to see, unless there's a bug in any of the file formatting, you're not going to see any file format changes

between now and v6 release. So if you're worried about, you know, compatibility issues, that I think version six is in a pretty stable place right now. Um, there are a few quirks and, and niggling issues, but there's not a lot of real major data loss problems.

I think we've got most everything under control. Um, in general, if, um, I don't know if you're familiar with how key CAD development works, we really do try to do a good job, even during the next version development of keeping key CAD as usable as possible, because we want

our user base. We have quite a large user base who actually run nightly builds on a regular basis, which actually helps out a lot with, um, helping key CAD move forward quickly as we, you know, track down any bugs and whatnot, um, give us, and they give us feedback to improve.

So I think you're pretty safe using version six, um, for regular development. Now, if you have an existing project or something that you got to get done tomorrow, you might want to hold off. But I think for, if you're starting a new design and you're looking forward to taking, or, and you want to like to take advantage of the new features, like say you have a, a

situation where you will actually want to use a curve trace, then, you know, then you, I think you're, you should go ahead and use version six for a new, new designs. Right. Um, I know that we have, uh, we have a number of corporate customers who are actually

moved, have moved on to version six and are actively developing. They're looking, they're looking at products that are six months, a year or two years out, and they've, they've moved their designs over to version six to make sure that they have that continuity,

going, going through and, and really access to, access to really all, all of the features that, that you mentioned in, in your talk. So the, there are a few other aspects here. I think maybe we have time for one more, uh, one more question. Um, when you are talking about

version seven features, things like, uh, the database-driven atomic, uh, atomic libraries, um, you're, you're really talking about, uh, full specification, right? So that, can you, uh, talk a little bit more about, uh, what that means for, uh, from a design

perspective? Well, from a design perspective, there's, there's, there's always, there's a generic symbol. You say like, take a resistor, right? You don't want to define the specific part number because it has to have a specific footprint and all the, um, complete information

manufacturer, maybe you might have a vendor part number. Um, so there's the generic concept of a generic symbol. Then there's what we call atomic symbols. Another way to think of them are fully defined symbols. In other words, a fully defined symbol might be a specific

vendor part number or manufacturer part number, the manufacturer's name, the vendor part number, maybe a vendor name you might have, uh, you have a specific footprint that goes with that, maybe even a custom footprint that goes with that resistor or part, then you might have a

specific 3D model specifically for that part. So an atomic symbol is completely defined and it, it literally defines a single part number. So if you think in terms of resistors, there's probably tens of millions of resist, individual resistor part numbers. Um, so there's, there's

different schools of thought. So a fully defined part number would be used like in somebody's MRP ordering system, uh, for, for like a company that you might import into a, uh, data, the corporate database for, you know, material resource planning and, and generic, obviously

generic symbols are something you can't use for that. So it's kind of the, that's really what defines the difference. So, so databases make sense for atomic libraries, just for that reason, you know, because they have use outside of key CAD proper and, and they are useful for, for corporate, other corporate reasons for lots of, uh, uh, you know, primarily, like I said,

big MRP systems. Well, all right. Well, it looks like we are almost out of time.