 Okay. Welcome everybody to my talk about LiberPCB. My name is Urban Bruhin from Switzerland and yeah. So first, what's LiberPCB? It's actually similar to Horizon and EDA tool, new open-source EDA tool. It's multi-platform, so it's works on Linux, Windows and Mac OS, and it's written from scratch in C++ and Qt. I started the development in about five years ago. So yeah, and there's the code is on GitHub, so you can check it out. First, the reason why I created the new EDA tool, and basically also the frustration about existing tools. Five years before now, think about how Kikad was then and so on, and it was, I was really frustrated about the existing tools. And the main reason is basically the library system, which is very limited in other tools, and also the file format, especially when using version control systems. Other EDA tools, yeah, they have a file format. If it's, maybe it's binary, then yeah, good luck. But if you have luck, then it's text-based, but still not very good suited for version control. And also the usability is often not very great of the tool. So about something about the library management. One thing is other tools have different library file formats for different kind of library types. So for example, one library type for components, one for footprints, and so on. And I think this is not really nice for users because maybe the tool sometime has add support for spice models or something like that. It also introduces a new file format for libraries. And yeah, and the other thing is tools do not really completely handle library management. So there is often no integrated tool to install and update libraries. If libraries have dependencies, so the tool does not handle this. So you as a user need to handle dependency management. And the project library management is also a little bit complicated sometime. So the result is actually the user has a lot of work to handle or to manage his libraries he wants to use. And that's quite a pain. So for example, as an eager user, if you maybe know this website where you search for libraries, download something, and install it manually. Or in KitKat, in the schematic editor, this is the library configuration dialog or in the board editor. I see a lot of file paths there and some environment variables and path substitutions and project specific libraries, global libraries, and so on. And I asked myself, why is it so complicated? I just want to use these libraries. So my answer is it doesn't have to be that complicated. So in Libre PCB, I integrated the library manager and to update and install libraries. And it also has a simple library dependency management system. So if you download a library, which library A, which depends on library B, library B is automatically installed when you install library A. And probably the most important thing is the application basically handles everything for you. So you don't have to care about libraries. They just work. So because there is no reason to make this very complicated. And another thing is actually similar to the Horizon tool. The problem of other tools is they reference many things just by name. And in some tools, it's even not possible to reference library elements between or across libraries. So you can't use components from library A with a symbol from library B and so on. And the result is there are often broken references when changing names or name conflicts. And many duplicates because, yeah, they cannot be shared between libraries. And the solution is actually the same as in Horizon. We use UUIDs for every entity in the library. So every symbol, every pin, every pad, everything has a UUID which never changes. So you can change the names and so on. And it doesn't have any effect. It doesn't break anything. And it's also possible to reference libraries across reference entities across different libraries. So for example, if you take a look at the file format of Libre PCB, which is based on S expressions, you can see that there are many UUIDs there. For example, a symbol looks like that. At the top is the UUID of the symbol itself. And the name is just the property which you can change anytime. And the same for every pin. So another problem of existing library systems is there is no way to have different symbols for the same component. So for example, a resistor can have an American or a European symbol. And but there is no solution for that in many tools. And these results in duplicated components with exactly same functionality but different symbol. For example, in Eagle, it looks like this. So if you have a resistor component and it's a resistor symbol, and the resistor has, for example, three devices, it looks like that. And if you want to have an American resistor symbol, you have to create an American resistor component. And you can't use the device from the European resistor. So you have to copy them. And maybe there is even another variant of the symbol. And you have many duplicates of devices. And this is quite a mess. So the quality of library gets worse and worse. So the solution of Libre PCBs, there is an entity called Component Symbol Variant. So there is only one component for a resistor. And it can have as many representation variants as you like. So you can create one for the European symbol, one for the American, or whatever you want. Similar problem is with packages or footprints. Because libraries do not have an abstraction layer for packages. For example, this TO220 package, this is three times the same package, but three different footprints. And this is quite common. For example, you have different footprints for different mounting variants or different size of pads, because one for reflow soltering, one for hand soltering, and so on. But libraries do not provide a way to abstract this. And so the result is every device needs to know every footprint variant of their package. For example, if you have a voltage regulator in a TO220 package, there's one relation between them. If you have one more device using that footprint, you have one more relation. But if you have some different footprint for the same device, for example, this time without the mounting hole, you have many to many relations. And let's add one more device and more footprints. And you can see you have many to many relation between devices and footprints. And that's quite a nightmare in a library system. So Libre PCB adds an entity called package, which doesn't know anything about footprints directly, but only what pads it has. And a device references only a package, and the package can contain as many footprint variants as you like. So the next problem is version control systems. It's quite hard to version control EDA files, because often important and unimportant data is mixed. So you cannot just check in the important data, but not the unimportant. And it's often even unclear rich files to put on the version control and which not. And the typical result is you have local changes, even if you didn't modify anything in a project or very large diffs, and merging is for sure impossible. And Libre PCB solves this by using many smaller files instead of one single big file. So you have higher granularity, and you can easily distinguish between important and unimportant data. And one very simple improvement is the tool automatically creates a git ignore file, so the user doesn't need to know which files to check in or not. And another thing is, and this is a diff of a Kicad PCB file. I just created a PCB, opened the editor, zoomed around, switched some, toggled some layers on and off, saved the project, and looked at the diff. And this is the diff. And you can see there are changes, which actually you don't want to check in these, because they are only irrelevant data. And at the bottom, there is actually the diff is one bit of some number. I don't know the exact reason of it. And this brings me to the next point. Files are not really human readable. So diffs are hard to understand, version control system are hard to use on these files. So my solution is basically, first, don't just consider text-based file formats as human readable. Not every text-based file format is human readable. You need to control every tiny detail of the file format to make it as readable as possible. And in Libre PCB, I consider parts of files which are not really human readable as box, and box need to be fixed. So the current project status is actually the library management works pretty good. The library editor has only basic features. It works kind of, but not very good. And schematic editor is also working pretty good, except some important features like copy and paste. And the board editor is at the moment work in progress. So there are no planes, no air wires, no design rule check, and so on. But Gerber export is possible, basically. And, of course, available libraries, there aren't many libraries available. But the most important thing is the file format is not yet considered as stable. So you can use Libre PCB already for some simple PCBs, but don't expect that you can open the files, for example, in a year with the newer version. So to get started, there are nightly builds available at the moment for Linux and Windows, and also some documentation. Okay, now let's show a short demo. This is actually just the app image I started, directly downloaded from the Internet. And this is the only the first time it says to create workspace. Then the project, the control panel says you need to install some libraries. So you open the library manager, and these are the libraries available in the Internet. And, for example, I want to install this library. It also selects the library here because they are dependencies. And if I unselect this, this is also gone. So let's install these libraries. They are downloaded from the Internet. And here we have some libraries. Okay, so now let's create a new project. Then the schematic editor is here. And as an example, I just add some components so you can see how the workflow would be. For example, capacitors are now available in the European symbol or the American symbol. So you can just add the American variant. Or you can also choose only a component or an exact device. It doesn't matter. So this one is just an ancient MOSFET without choosing already a footprint. So maybe ground VCC, make some connections, whatever. It doesn't make sense, but... So, okay. And now in the board editor, we can see there are three parts which are missing on the board right now. So we can choose, for example, the resistor, choose the exact device, add it, and the other devices. And for example, the MOSFET, we have two devices available at the moment. And for the TO220 device, we can also choose between the different mounting variants. So let's add this one. And one cool feature is also you can copy a board. Then you have two times the same board and can work independently on them. So you can... For example, in this board, you want to use the other device. You can just switch to the other one. Or you can also choose just the other mounting variant. And also the board and the schematic is also in sync. It's always in sync. So for example, if I remove one resistor, it disappears from both boards in the time. Yeah, so it's like an eagle, basically. And yeah, you can... Okay, that's... Sorry? Oh, okay. Right now, it's also no possible, in the laboratories, we do delete from the board, but it's planned to do that. So if I delete something, it appears in this list because it's not added to this board, but here it's still available in the other board. So okay, and after, let's say you have... Okay, that's just... Because I said already, the board editor is in work in progress, so there are some strange things. And there is even a very simple Gerber exporter without any option, but you just click Generate and open the direction. And if you don't trust me, the files are generated in this. Yeah, so you can just open them with Gerview, for example, and here it is. So very simple, but it works. Okay, so I think this is... So now the next steps. The first, the highest priority at the moment is to stabilize the file format, so do the last breaking changes and to create the first stable release. And for that, I also need to make the board editor really usable because it doesn't make fun like that. But it's already possible to order PCBs, so... And yeah, the next step is add more functionality, but yeah. So contributors welcome, of course, and yeah, that's it. What's it written in? The language, C++ 11 and Q5. Why not just participate? Okay, the question was again, why not instead contributing to QCCAT? And actually my answer is similar to the Horizon one because I think the library system is that important part of the EDA tool and it's a very fundamental low-level part and it's very hard to change this concept. And I think in Libre PCB, the concept is completely different than in QCCAT, so... I don't see Wayne going like this instead of... This is a problem. Okay, but... It's subject for discussion later. Yeah, yeah. More questions? So your question is the generic devices, where to order them then? So yeah, so the question is the part numbers. Are they part... Order codes and exact part numbers and so on? If they are included in the library and the current answer is at the moment, it's not part of the library, but I already have plans how to integrate it, so it will be in the library later. Yeah. So I can follow, for example, as a follower of the PGA and I want to go to the other direction and then keeping the overview. It's quite hard if you only have one view. Sorry, where is all the... No, the views that you see, perhaps the whole layout where you are and where you want to start and where you want to end and you see, you have another window where you are in a much larger scale. I'm not sure. You're asking about the board editor or... Does it happen? Can you have multiple views? Okay, okay. Is it intended to have multiple views of the same board, basically, with other regions? It's not planned this time, but of course it would be useful. Yeah. Okay, let's thank Orban again.