Jon Evans discusses KiCad 6 

Here is a list of significant moments from the transcript, including timestamps and summaries:

1. [00:00] Introduction and Greeting

   - Peter welcomes Jon Evans and mentions the purpose of the discussion, which is to talk about the upcoming KiCad 6 release.

2. [01:00] Jon's Role in KiCad

   - Jon Evans introduces himself as one of the lead developers of KiCad, explaining his responsibilities in the project.

3. [02:30] KiCad 6 Timeline

   Jon discusses the anticipated release timeline for KiCad 6, mentioning the challenges faced due to the project's volunteer nature and external factors affecting developers' schedules.

4. [05:30] New Python API

   - Jon explains the new Python API feature in KiCad 6, its benefits, and potential applications for users.

5. [10:00] Plugin Ecosystem

   - Discussion on the future of the plugin ecosystem in KiCad, including the potential for a plugin registry and the importance of plugins in expanding KiCad's capabilities.

6. [15:00] Curved Traces and Future Routing Improvements

   - Jon talks about the new curved traces feature and future improvements planned for routing, such as automatic trace width changes and routing multiple traces at once.

7. [20:00] Pin Swapping Feature

   - Jon confirms that pin swapping, a feature allowing flexible routing of bus signals, is planned for KiCad 7.

8. [22:00] Netlist File Usage

   - Jon clarifies the continued availability and use of netlist files for external applications, despite changes in internal workflows.

9. [24:00] Import Tools for Eagle and Other CAD Software

   - Discussion on the current state and future improvements of import tools for Eagle and other CAD software, emphasizing the importance of user feedback.

10. [30:00] S-Expressions as File Format

    - Jon explains the reasoning behind using S-expressions for KiCad's file formats, highlighting its strong typing and lack of ambiguity.

11. [33:00] Board House Technology Preferences

    - Jon discusses the potential for importing/exporting technology files to match board house capabilities, mentioning current and future possibilities.

12. [36:00] Auto-Routing

    - Jon addresses the topic of auto-routing, explaining why it is not currently a priority for KiCad development due to its complexity and mixed results in other tools.

13. [40:00] Drawing Tools Improvements

    - Discussion on improvements to drawing tools in KiCad 6, including new primitives and better snapping, while noting the limitations compared to dedicated mechanical CAD tools.

14. [45:00] Sharing Projects Between Users

    - Jon explains how KiCad 6 facilitates sharing projects between users, including packaging projects and using source control, and the improvements made to file formats for better version control.

15. [50:00] Documentation and Source Control

    - Jon mentions the ongoing efforts to update KiCad documentation and provides guidance on where to find information about file types and source control practices.

16. [52:00] Conclusion

    - Peter thanks Jon for the insightful discussion, and Jon expresses his pleasure in addressing the questions.

Peter: John Evans, thank you for joining me today. How are you?

Jon: Doing well, Peter. Good to be speaking with you again.

Peter: Yeah, it's been a while. It's been a few months since last time we had the opportunity. This time things have moved along with KiCad 6. I've been keeping an eye on the project and this is the reason why we decided to get together today and talk about the upcoming KiCad 6 which I think is gonna be a big deal.

Jon: Yeah, definitely. I'm very much looking forward to KiCad 6 being out in the wild and seeing everyone use it.

Peter: Perfect. Well, before we get started with my questions and your answers, could you take a minute to tell us a little bit about you and especially what is your role in the KiCad project?

Jon: Absolutely. So my name is John Evans and I'm one of the lead developers of KiCad. I've been working on the project for quite a while now and for some years now I've been on the lead development team which means I'm part of the team of volunteers who decides the direction of the project and decides what will go into each release and helps to implement new features and fix bugs that are found by our users.

Peter: Perfect. So you are, I was thinking about this because I recently wrote an article about KiCad 6. It took a couple of weeks to play with the, oh, it's not a release candidate yet. It's code named 5.99. It's the nightly build and eventually it's going to become KiCad 6. So it took a couple of weeks to play around with it and compare it to KiCad5 and wrote an article about it. People read it and they sent me questions. And I thought, well, who is best to answer those questions? And that was you. That's why I invited you to have the session with me. So I've got some questions there as well. Most of these questions came from readers. So if you're ready, I can start asking.

Jon: Oh, let's go.

Peter: Okay. Now the first one is from me, but it's a question that I get a lot from a lot of people and that has to do with KiCad 6 timeline. And when do you approximately think that KiCad 6.0 might be out?

Jon: That's the biggest question, isn't it? I hear that a lot as well. So we're an open source project and we are getting work done through the work of volunteers and those volunteers are working on KiCad diligently, but they also have the rest of their lives going on. And in the past year or so, there's been a lot of volatility in the world and that's impacted all of our developers as well. Some people's schedules have changed in ways they didn't anticipate and some things have changed about jobs and things like that. So that's why it's a little bit harder for us to come up with a very concrete release schedule compared to some commercial projects. But what I can say is we're very close. We have a couple more features, one of which is the new Python API that everyone is looking forward to who does Python scripting with KiCad that are not yet in. And we're waiting to get those in before we are ready to say that the only thing standing between us and release is fixing bugs. And in the meantime, while some developers are working on that, the rest of us are working on fixing bugs that are found by our users who are testing the nightly builds, the 5.99 builds. And we have a good list of bugs. Some of those, it might be decided at the end of the day that they're low priority bugs. Maybe there's a workaround and it's just something that could work a little bit better. And we might put that off from the 6.0 initial release, but all of the severe bugs, the kind of bugs that might cause you to lose work or get in the way of getting a serious design done, we wanna fix those before release because we want everyone who is upgrading from the 5.1 stable release to 6.0 to have just as smooth an experience and in fact, a smoother experience due to all the improvements. We don't want them to upgrade and say, "Oh, this upgrade looks nice, but it doesn't work as well as the old version does." So we are basically looking for that state more than a particular date. And at the rate that we've been going, definitely this year, we'll have this out. And hopefully in the first half of this year, it's looking pretty possible. But I just wanted to give that longer explanation because we still do face a lot of uncertainty caused by what's going on in the daily lives of the developers who are writing this code. And we're all doing the best we can, but it's hard to give a fixed date other than the list of things that is left to do is getting smaller and smaller.

Peter: Yeah, that's great. I wasn't expecting a specific date like by the 1st of July, because I did not realize that you actually have new features that you're still working on. My understanding was that you were fixing bugs at the moment and everything big, like the new file structure, for example, was completed. But yeah, the API for the Python scripting, that is like a fundamentally new feature. It did exist probably previously, but I think you're expanding it a lot. And because I do have a question about this later on, I bet Ken just bring it up to my list and ask you now, can you tell us more about this feature and what kind of applications do you see people developing based on Python scripting and its API?

Jon: Sure, so Python scripting has been a part of the PCB editor for KiCad for a while now. And some of our users have done a lot of incredible things with this to expand what is possible to do and what is easy to do in KiCad. And we'd like to encourage that. One of the problems with the existing Python API has been the way it was designed makes it pretty hard to maintain the underlying code, which is written in C++ with the Python code that all of our users who are developing Python plugins are developing. It's hard to keep those in sync and it caused some friction over time. And what we set out to do was to solve two problems that users had. One was this kind of struggle to keep up to date with changes to the C++ code. And the other was the fact that our Python API only supported the board editor. If you wanted to write code against the schematic or other parts of KiCad, it simply wasn't possible. So the new API we're working on is designed to support all of KiCad, not just the PCB editor. And what we see people doing with that, we already have some ideas, but I just know as soon as it's out there, people will start working on it and they'll come up with things that I haven't even thought of. But once you can write Python programs, it becomes possible to expand what KiCad does without waiting for us, the core developers, to implement something in C++ and release a new KiCad version. Some of the Python plugin developers have been releasing new versions of their plugins on a weekly or sometimes even daily basis. And you can install a new version of a plugin without updating the core of KiCad. And the new stable API will let plugin authors write code that they can sort of depend on continuing to work as new KiCad versions come out. And users can trust that the Python API sort of limits what people can do. The new Python API, the old Python API had some ways in which it could be misused where you could even cause KiCad to crash. And so we want to sort of solve those problems as well so that the Python plugins can be more trusted. But as to what people can do with this, there's a whole lot of things that people will think of, but generally it's automation. So if you wanted to do something that was very specific to your workflow, like say you wanted to take all of the components in a schematic and change some properties of their fields in a particular way that was suited to your company or something like that, you could write a plugin to do that. Or if you wanted to go and look up prices for parts on your chosen distributor of parts, you could write a plugin to do that and put that part information in your BOM. Things like that where it might be pretty specific to your application. And so we might not develop a general KiCad feature for it. You can write those specific features quickly and easily and expand KiCad to your own preferences.

Peter: Great, so it seems like this is becoming a core feature of KiCad 6 and beyond. I do have a follow-up question on this on the state of plugins and the future. And because as I was playing around with KiCad 5.9, I could see a lot of evidence of the plugin components becoming more important than they had been in the past. So I want to ask you this, there's already an ecosystem of KiCad plugins, as you said, they really work in PCB new because there's no capability to do such thing in EE schema that is coming in KiCad 6. So my question has got two parts. Number one, what is gonna happen to those older plugins? Will they be working in KiCad 6 or will they need to be modified? And part two, maybe you can blend them together is this, if plugins through the Python API becoming so much more important and therefore useful, it means that people will be using that capability and they will be creating plugins that others will be able to use. It could be free plugins. I can even see an ecosystem of paid plugins or higher quality plugins that can pass certain standards of quality. How do you see that forming in the future? For example, will there be some kind of a registry for plugins that people can download from? Will there be some kind of organized ecosystem like we can see in other projects? It could be a bit of an open ended question, but I wonder what your thoughts are about when it comes to the plugin ecosystem.

Jon: Absolutely. So the first part of that question, will plugins that were written for KiCad 5 need to be updated for 6? And the answer is usually small tweaks will be needed. Some might work without any changes, but there have been some small changes to the old API in PCB new that will have broken some Python scripts where they just need to change the name of some function call or something like this. And some plugin authors are already doing this. They're posting nightly build versions of their plugins. And I don't see any more changes coming to the old API. So it's really up to plugin authors to decide what they want to do if they want to support nightly builds or if they want to wait for the stable release and then update their plugins. And it's really up to how much time they have to keep track of changes in the nightly builds. The new Python APIs that are planned are going to be separate from the old APIs. So new scripts will have to be written against the new APIs, but there will be this transition period where both APIs will exist in KiCad 6. So the old scripts will be able to use the old APIs as long as they make those minor adjustments. And to the second part of your question, I think is pretty interesting as well. I would love to see such an ecosystem where people can go to a registry of plugins and see user reviews and ratings and things like that. I think it's going to need some effort from various parties who are going to need to help out with something like that. Of course, we need some kind of a web presence and software on the web to handle distributing plugins and keeping track of ratings and reviews and things like that. And I think it goes beyond what the core KiCad team can do by ourselves, but I think it's definitely going to be important for the ecosystem. So there's already been some discussions about how to make this happen. And I think there will be more involved and more serious discussions once the new API is merged into the nightly builds and people can start testing it out and getting ideas about what to do with it. So I think we don't have immediate plans to when KiCad 6 is released, there won't be some KiCad plugin store that immediately shows up. But I think it's a wonderful idea and it's obviously something that would help the Python ecosystem a lot.

Peter: Yeah, I think that would be amazing. You can just becoming inspired from other open source projects like Python itself, for example, and how easy it is to get Python modules written by third party developers, just one command and it's installed and then it just works. That would be like a very good target to have. But of course, over time, I think the API is the first component that needs to be in place before people start exploring possibilities there.

Jon: Yes, and even before we have some kind of nice web service where people can put their plugins and things like that, we are planning to make it a little bit easier to install plugins than it was in previous versions of KiCad just to make it that much easier for users to get involved with the plugin ecosystem.

Peter: Would that be in 6.0 or perhaps 6.5? Maybe push it a little bit.

Jon: Plan is for that to be in 6.0, so we'll see how it goes. But yes, currently we plan in 6.0 to have the new API and to have also the plugin manager to make it a little bit easier to install plugins.

Peter: Yeah, great. Seems like Christmas might be coming early this year. All right. Okay, I think let's move away from plugins now. Let's have a look at some other submitted questions. So this one is from Alan. So Alan is interested to know what happens after curved traces. So we now have curved traces, it's amazing. Do you think there's gonna be some kind of tools that can produce other types of like other geometries of traces?

Jon: Yeah, so there's a number of different ways I could answer that. What's next after curved traces? There's maybe a hundred things that we're thinking about next, but maybe I'll focus on traces in particular and improvements that we're thinking about for the routing of traces. So right now the router in KiCad has some set of capabilities for working with single traces, for working with differential pairs and things like that. It's a lot better than it used to be, but it's not nearly as full featured as the kind of interactive router that you can see in some of the higher end commercial packages. So some of the things we're thinking about are, for example, having the router be able to automatically change the width of tracks while you route. This would allow things like automatic neck downs to fit through tight spaces and escape from BGAs. And it would also allow things like defining different trace widths for a controlled impedance line on different layers and having the router automatically change to the correct width when you change layers with a via without having to manually change width. Another thing we're thinking about is routing multiple traces at once. So the diff pair handles the plus and the minus trace at once, but we want to expand that to the general case. Maybe you can take a whole bus of signals and route them as one and place a bunch of vias together in different patterns to change layers. So those are just a few of the things off the top of my head that we're looking at with the router. And some of the other things that might be interesting for copper shapes, we want to make it easier for people to do more advanced copper shapes. So we've already done some work that is in six, or is in the nightly builds already, will be in six, such as making it easy to define custom shape pads in footprints. It was already possible, but it was kind of clunky, so it's now much easier. And we've also made it easier to import shapes that were designed in a different CAD program, maybe a mechanical CAD program, and convert them into copper pads or traces. So for very, very particular applications, such as some RF and magnetic applications, you might want to design a pad or a trace or an antenna or something like that and then import it into KiCad. So that's a little bit easier now, and we have some other improvements in the roadmap for future versions there.

Peter: Yeah. You can-- speaking of pads, you can already, in KiCad 5.99, create all sorts of different shapes. We can control the various parameters, for example, of a curved or a rectangular type of pad. So a lot of that has been already parameterized. So you're talking about a lot more beyond that, importing pads from other tools.

Jon: I think the most important part of that that is not in six and is currently planned to be in the next version after six is full pad stack support. So this means for pads and for vias, being able to find a different shape for that pad on every layer. So you can have pads where you have a square on the back layer and no pad at all on the top layer or better control over vias in case you need back drilling and things like that to eliminate stubs in really high frequency situations.

Peter: Cool. That's for KiCad 7, right? You push it to that.

Jon: Yeah.

Peter: All right. OK, let's move on. The next one is from Lars. So Lars is interested in the new bus features. So you've extended the way that buses work, and you can use now expressions to match nets together into a single bus. And Lars is wondering if you could actually delay setting the bus by making it possible-- so he's got a long question. I'm trying to shape it concisely. So he says it'd be useful as an example in an MCU, like a microcontroller unit that is connected to a static RAM chip, where it doesn't matter how you route the individual traces of the bus. So instead of doing the routing in the schematic to allow for the writing of a bus and its components to be done inside the layout, and then once layout decides how to do the routing to send that information back to the schematic just so that you have completeness there as well. I don't think that's possible now, right? But Lars is asking if that might be possible in the future.

Jon: Yes. This is, I think, if I understand correctly, this is a feature that we call pin swapping. And this is a feature that is not in 6, you're right, but it's planned for version 7 at the moment. And this is another one of the key features that commercial high-end layout packages have that KiCad doesn't have yet. So it's a pretty high priority for version 7. So what pin swapping is, it's a way to define for particular parts this group of pins can be swapped around in a certain way. Maybe like the example from Lars, you have a whole set of lines, and it doesn't matter what order they go in. Or maybe there are some lines, and they can be swapped but in a more restricted way. Like you can only swap one with three and two with four or something like that. But basically, you can define how this works in your symbol and in your footprint. And then at layout time, you can make those choices based on what would make the routing the easiest and then push that back to the schematic. So yes, it's a good idea, and it is on the roadmap.

Peter: Perfect. Yeah. All right. There you go, Lars.

Jon: All right. Next one from Lee. Lee's interested in what's going on with the netlists, and he's asking about what is the outlook for the netlist file. It seems like he's considering the netlist file as being particularly useful for applications where you want to interact with other external applications like the HDL and Verilog applications and use it as an interchange file. I'm guessing Lee saw some comments that the netlist file is no longer required for passing data back and forth between the schematic and the board in KiCad. And don't worry, the netlist file is very much still available. It's one of the things that can be exported. And so we definitely still have all of the same capabilities for exporting netlists in a few different formats, for talking to different applications. Some people use it for doing routing and for doing simulation and for interfacing with HDL tools like Lee mentioned. So that's very much still an option. It's just no longer part of the workflow inside KiCad.

Peter: OK, so it's now just a way to export data from the schematic so that you can do something useful with the data. Perfect. All right. Next one's from me. I wonder what's the story and the progress when it comes to import tools, in particular, Eagle. So I work with Arduinos, for example. You probably know that. And Arduino publishes their schematics for the various boards from Eagle. I've imported them into KiCad 6 using the Eagle import tool. And it does kind of work, but it still requires a lot of manual editing to get things right. So I wanted to ask you, how is the import tool going for KiCad 6 from Eagle, but perhaps no other tools as well that you might have in your radar?

Jon: So first of all, I'll say we welcome bug reports on the importers. And if there's something that is not quite right when you import a schematic using one of the formats that we support or a board, just open an issue for it. And it's possible we hadn't seen it before. So the Eagle importer is something that's been around for a while. It's not new for version 6. It's gotten some minor improvements so far for version 6. But I think there's, off the top of my head, not very many things that we know about and are planning to fix for version 6 with the Eagle importer in particular. So I would definitely encourage you to, if you have any issues, especially if they're breaking your design, to report them so that we know about them. I would say, with Eagle, one of the challenges with importing Eagle designs, particularly with importing Eagle schematics, is that Eagle and KiCad have fairly different internal models for how connections work on a schematic. The rules are different. And whenever you're converting between two different worlds that have different rules, it's hard to do something exactly. And so we have to make some compromises when importing Eagle schematics because of those differences. And we don't see those same compromises in some other tools just because those other tools happen to have a model of connections in the schematic that's a little bit closer to KiCad's.

Peter: Yeah. I should just clarify that when I do such an import, the layout works out perfect. I haven't noticed any problems in the layout. It's the schematic, as you said, that I see the problems there with, for example, symbols missing. So KiCad doesn't know what symbol was used in Eagle. So it just has a question mark usually, or a blob. I can't remember exactly how the symbology works. But the layout is perfect. But yeah, next time, we will file in a report, especially when it comes to the EE schema side, which seems to be more problematic.

Jon: Yeah. Sorry. Go ahead. Go ahead.

Peter: Yeah, so I thought I'd ask this question because many of the comments that I get is from people that are working on different tools right now. And they would like to be able to bring their projects across to KiCad over time. And I guess that's where import becomes important.

Jon: Absolutely. So all of our different importers have come from a champion developer who is able to both work on KiCad code and is motivated to move away from a certain tool. So we've actually added two new importers in version 6 this way, one from Altium Designer and its related products like Altium Circuit Maker, and one from CAD* So both of these were done by two different people who had access to those tools and had the ability to check that the importer was doing the right thing on their own designs. So it's always difficult with reverse engineering because all of these formats are, for the most part, Eagle is a little bit different in that some of the Eagle file formats are published. But some of these other formats, you just have to reverse engineer them and hope for the best. And so when the importers get out there, people use them on their own designs and find things that we didn't know about or we didn't do correctly. And they evolve over time. So I would expect those to keep getting better as people report issues about them. But already, we've had a lot of people testing those new importers and having some success. So I'm looking forward to KiCad being able to help people who have legacy designs in some of those tools as well.

Peter: Yeah, it is a difficult problem. I typically suggest to people that start your new project in KiCad so that it's clean and you don't have to worry about the transition over. OK, next one is from Nicholas. So Nicholas has got actually two questions. And the first one has to do with S expressions. And he's asking, what is your reasoning behind choosing S expressions as the file format for the schema and the layout now instead of something more common as JSON or YAML?

Jon: So that decision was a little bit before my time on the project. And part of the reason why we have decided in version 6 to move the schematic file format to be S expressions as well as the PCB, which has been S expressions for a long time, is just because that decision was already made. And it made more sense to keep using the format than to move all of the file formats yet again. The PCB and the footprint format got some minor changes to add new features and fix some bugs in version 6. But it also, from a high level, looks pretty similar to the format in version 5. And for the file formats, everyone can have their opinion about file formats. I think one of the things that we like about S expressions that is not unique to S expressions, but it is a property, is that it's a pretty strongly typed language, so to speak. We construct a grammar of what a key-cad file means. And it's not really open to interpretation. So that means that when we're importing files or we're opening files, we can be pretty sure what the files are supposed to be. And they're not as ambiguous as some of those formats like JSON, where we use JSON as well. We use it for configuration files and for Gerber job files and things like that, where things can be a little bit more flexible. It's OK for things to be missing. If a configuration value is just missing, key-cad can assume that it's the default value and things like that. In the file formats, we want things to be a little bit more rigid. But why S expressions? Just because someone decided that and wrote the code for it. And it's not perfect, but also it's there and it's working. And so I think we have better things to do than change it just for the sake of changing it.

Peter: Yeah. Now, I think Nicklick was curious. He's not suggesting change, of course, but he's curious about whether there is something unique in his expressions. I think what she said about it being strongly typed and therefore there's no ambiguity, I can see that is quite important. And that could be why it was selected by whoever made the selection in the olden days. And it's pretty good. It works. It works well. All right, so let's keep it. She said there's other things to do, other things to worry about. Now, the other question from Nicklas has to do with setting up board house technology preferences. And he's asking whether KiCad 6 will have an import/export technology file. I guess that the manufacturing house will be able to publish on the website. Then I'll be able to download it, import it into my KiCad instance. And then my KiCad instance would know what I can and can't do so that my eventual design is compatible with that manufacturer's capabilities. So do you think that something like that is coming?

Jon: Yes, so we don't have a separate file format that's just like a technology file format. I know some other tools have this kind of thing. We might be open to adding that in the future. I think it just hasn't made the cut yet for version 6. So what we do have is all of the design rules in a project file format. Those are stored in JSON, the standard design rules. And so it would be possible for manufacturers to publish these in a format that KiCad can import. It just wouldn't be this kind of technology file format that its only purpose is to convey board house capabilities and things like that. So it's definitely possible. It just doesn't work quite the same way as some other software tools do. And it's definitely something we're open to changing in the future. It's also something that we-- speaking of the Python API-- think that people could do with the Python API is it should be possible to write a Python program that goes and collects requirements from a certain board house and applies them to a design or something like that.

Peter: There you go. That's a good suggestion, actually. So that's another reason why the Python API could be a game changer. And a lot of these questions asking for potential features in future editions can actually be satisfied through Python script taking advantage of the new API. Cool. Next one. Vasilis is asking if there's any plans for auto-routing. So currently, there are external tools that we use for auto-routing. Is there anything that is planned to be integrated, perhaps?

Jon: Currently, we're not planning on working on an auto-router. And I'll say a little bit more about this, because I know this is a kind of a divisive topic sometimes for some people. So auto-routers are very complicated pieces of software to create. I've used a number of them. And what I'll say is the results I've had with them have been mixed. Even with the routers that were created by teams of paid software engineers working for years, they sometimes didn't end up saving as much time as they promised. They created things that needed a lot of cleanup, and they require a lot of setup time. Now, I have designed big boards. I fully know there are situations where auto-routers are useful. What I am not sure about is where the KiCad team should prioritize that relative to some of the other things we could be working on. When we go and talk to people who are designing boards in KiCad every day, especially those who are working on advanced boards and those people who work in multiple tools-- we have a number of users where they do some boards in KiCad, and they do some boards in Allegro or Altium or some other paid product where KiCad's capabilities just can't deliver the same efficiency they need. Auto-routing usually doesn't come up as a feature request from those people. Usually what comes up is things like better interactive routing, like I was talking about earlier, being able to route whole buses at once, being able to do more targeted auto-routing, like being able to automatically fan out a BGA or being able to, once you have routed something 90% of the way, just sort of finish it up. Or things like giving the router a kind of a sketch of how you want traces to flow and the router solving the details of making the traces follow that sketch and look nice and things like that. So first I'll say our team of people who know how to work on the router is very small. It's really just a few people and their volunteers. And it's fairly complicated software. It's no doubt the most complicated part of KiCad is the router. And when we look at the kinds of things that would be possible for us to add, I just don't think an auto-router is in the cards right now, even if there were universal high demand for it, which currently it's not really clear that that's the highest priority for all our users. We just wouldn't have the developers to do a good auto-router. And I'm not sure doing a poor auto-router would be a good use of our time. So we'll definitely continue to support the workflows using external auto-routers. But unless something significant changes with our resources and our ability to have developers working on the really hard problems that are behind automatic routing in general, I don't see us having a full board auto-router anytime soon.

Peter: Yeah. No, I think you nailed it. That's kind of how I feel. I don't work on complicated boards myself, but they are boards that are not really affected by the intricacies of how the auto-router work. So I see the auto-router myself as a time-saving tool. And then an external auto-router just works perfectly. But I had discussions with people that do build much more complicated and high-speed boards with RF requirements, et cetera. And then the auto-router breaks down. It's just not useful enough. So I think that the case is rested. All right, let's move on to the next one. The next one is in relation to drawing tools. I don't have a first name for the person that asked for this question, so that's OK. He's asking if there are going to be any kind of improvements to the drawing tools. He gives examples, the ability to trim, for example, snapping or adding offsets, parametric constraints between lines and component distances, things of that sort.

Jon: Yes. So in 6.0, I would say the biggest improvements to drawing are a few new drawing primitives. So now it's easy to draw things like rectangles and arcs. And some improvements to snapping. Snapping to different points on objects works a lot better than it did in old versions. Some of the other things on that list, trimming lines, constraints, and parametric design elements are not in KiCad yet. And in terms of what will be in KiCad in the future, we're still trying to figure that out. I think there is a line to be drawn somewhere if we're considering how to use our limited developer time. There are tools that are specializing in mechanical design that have extremely complex drawing tools. FreeCAD, for example, if you stay within the open source world, where they have parametric CAD engines where you can do all of these things and then import into KiCad. So at some point, it doesn't make sense for us to duplicate all of the work of those external tools when we could just work on better interoperation between KiCad and mechanical CAD tools. But I think there is still room for us to add some of those things to KiCad. I just think we will probably not prioritize making KiCad into as good of a mechanical drawing tool as a dedicated mechanical drawing tool. There's just other things that are specific to electrical CAD that we could be spending time on. And it always comes down to how do we spend our time. We don't have that large a team. And everything I say could change if we suddenly get to twice the number of developers. But looking at where we are right now, I think we're thinking about some kinds of simple constraints. We're thinking about things like an offset tool would be pretty easy. But the full parametric sketching that you get in a mechanical tool, I think, might be a little bit far off.

Peter: Yeah. I think it's probably easier to learn FreeCAD for anyone who's interested in this kind of capabilities. And I'm going to look into that as well. I have been playing around with FreeCAD. But I haven't needed to use it for a particular project yet. But this is something that I'm going to investigate closer. So you can see the synergy between these two open source tools. So I may be able to do something about that. All right. Joan, I've got one more question to complete this session. It has to do with sharing projects between KiCad users. So I wanted to ask you this. So now that both the schematic and the layout parts of KiCad use the same kind of format, and as far as I know, also these files are self-contained, it means that whatever footprints or symbols are required can be stored within the same schematic and layout file instead of relying to links to external libraries. Is it possible then to just package a KiCad project, perhaps in a zip file or somehow else, perhaps a single or maybe two as expression files, and then email them to a colleague who then will be able to open them up in their own KiCad instance and continue working without them having to chase library files elsewhere?

Jon: Yes. So there's a few exceptions. But in general, that works pretty well now. It works a lot better than it did in previous versions. So like you said, our new schematic file format stores the symbols inside the schematic, which means they can always be updated from an external library. But that external library doesn't need to be present for the schematic to open. And there's no separate cache library file like we had in previous versions of KiCad. So you can take a KiCad schematic file without any other files and send it around, and it will open. And in terms of the whole project, yes, you can absolutely package it up in a zip and send it around. We even have a feature to do that automatically from the project manager. You can click a button and create a zip file. And there are a few things to watch out for when you do that. One is 3D models. So if you use 3D models in the footprints, those currently aren't saved inside the footprints or inside the board. So you need to be able to find those on whatever computer in order to show the 3D preview or to export a step model. But other than that, it generally works pretty well to move designs around between different people on different computers. And you only would need to also have the libraries if you wanted to make updates to those libraries or pull in new changes from the libraries.

Peter: Great. And all of those files, those shareable files, they're all text-based files, right? Which means that you can use source control, and you've got everything there as well. So that's an additional, I guess, intermediary mechanism for sharing, not just email. Just--

Jon: Yes. Just check them in. We know a lot of users use source control with KiCad designs, and we encourage that. And one of the things we've done with the file formats in version 6 is made some tweaks to minimize the amount of what we call churn in the files. So useless changes to the files when you didn't actually change something in the design. We've eliminated almost all of that, and I think we've eliminated all of that in the board files now. So basically, they work a lot better with version control systems. In previous-- in KiCad 5, when you open a board and you change what layer you're looking at or you show and hide layers, all of that is saved in the board file. And so just by viewing a board, you can mark it as modified. And then if you're using a version control system, that gets messy. In KiCad 6, we've pulled all of those things out into a project file, and we actually have two project files now. One of them is designed to be checked in with the design files to your source control, and it contains all of the important project information and design rules and things like that. And the other file is kind of like a local state project file, and it contains things like what layer you are looking at and whether or not high contrast mode is turned on and PCB new and things like that. So what it means is you can close and reopen KiCad for the same design and get back your view exactly the way you had it. But you can also ignore this one file if you are checking it into source control or if you are zipping it up. And all of your changes that are just for how you view it are in this one file that you can exclude.

Peter: Perfect. OK. Is there some documentation where we can find out, for example, which is the file that contains your project specifics, say state of layers that you're looking at?

Jon: Yes, so the KiCad documentation is very much a work in progress. If anyone has gone to our documentation site, you'll know it's been a struggle to keep it updated as we make changes to the program. We're in the middle of an effort to prepare for the version 6 release by getting rid of all of the old information and writing new documentation for all of the new tools. Some of the documents haven't been updated since version 4, even, so they're quite out of date. One of them that has already been updated is the main documentation for the KiCad program. So our documentation is split up into different chapters for different subprograms. The one for the KiCad project manager program has been updated already. If you're on our documentation site, you just have to make sure that you're looking at the nightly documentation and not the stable release. But there we have a description of all the different file types that KiCad uses and some notes about which ones should be checked into source control if you use it and things like that.

Peter: I'll check it out. OK. That's it, John. Thank you very much. That was extremely helpful. Thank you for making the time to talk to me today.

Jon: Absolutely. It was great to talk to you and great to hear some of the questions.