 Okay, for our next talk, we have Lukas Klammer who will be talking to us about Horizon EDA. This is our fourth EDA package of the day. You should consider yourself incredibly fortunate, and let's hear round of applause for Lukas. So welcome everyone to my talk on Horizon EDA. So for those who don't know yet, Horizon is a full-featured EDA package for PCB design. That's everything from library management to schematic entry, PCB layout, and 3D export. So this talk marks the release of version 1.0 after about three years of development, and like this talk as an opportunity to take a look back and see what decisions drove the development in the past three years. So when starting, I had to make a few decisions up front that would ultimately guide the rest of the development. So first and foremost was keeping it simple. Since an EDA package of that complex, of that size is something inherently complex, so most of the work was basically keeping complexity low enough. So and that meant not having any funky class hierarchies in the inner core data model, since for example, mirroring a symbol and mirroring a package on the board is something that takes very different operations. Keeping simple also meant, keeping direct mapping from user interface to data, as I think that if the user interface and the data model are aligned, then that really helps to keep complexity down and avoid bugs in that regard. Since I was starting from scratch, I decided to do a breadth-first implementation. So basically implement something that's usable for all aspects so that I could validate my architecture and get feedback early on. So I didn't like develop the schematic editor from start to finish. And then I think about the board editor, I developed a minimum viable version of every component first. That also implied not being afraid to rewrite stuff, since that project is a learning experience for me, a code that was written some time ago, now isn't that good anymore since I now know more stuff. And last but not least, having fun is also an important part, since I'm not getting paid for this, I'll have to keep myself motivated and having fun is the best way to do so. So that wrapped the back time back to September 2016. That's when the first commit happened, not public yet. At that time, I decided to write the program in Python and see for the OpenGL rendering, since that's what I knew at that time. And I started with the simple editor, since the plan was to have more or less the same editor for everything from symbol to schematic and board and so on. And symbol was the one that had these dependencies. That went for about a month or so until I got fed up with Python's weeks typing. So I decided to scrap that and rewrite everything in C. It only lasted for about a month as well, since I then got fed up by G object, since I used GDK for the UI and tried to pass my own data type through a G object callback, and I just couldn't be bothered to do this. So I decided to give that C++ thing a try and was pleasantly surprised. So in November, I got the symbol and schematic editor done, and at that time the schematic editor already had all the stuff it has today, like knowing about nets and buses and so on. So pretty good actually. Then in December 2016, everything that required layers like pads like package and board came, and I also made it to run Windows, which mostly involved some wrappers for UIT stuff, and on that year, I met Raphael from the Libre PCB project. He's also here, and I talked about the project with him since I saw the Libre PCB on the Congress Wiki that year, and he encouraged me to release it since I was a bit hesitant due to the audio state. In January 2017, I cleaned some things up and wrote text editors for some of the non-graphical stuff like entities and units that defined the pins of a part and put it on GitHub. And so that's what it looked like then, the schematic editor, so many things are still that way today, and the board editor as well. So the first thing that happened after the release was adding a project manager, since back then you had to launch each editor from the command line, which was a bit unconvenient for many users. And in May 2017, I then added DRC since you basically can't live without DRC if you wanted to do an actual board, and my approach for doing this was to just dump the whole board as polygons, and then use the excellent Clipper library to just offset and intersect the polygons, and that was a pretty easy and correct way to get DRC running. Then in June 2017, I added the parametric padstacks and packages, since up until that point, you had to draw each padstack individually, so if you wanted to have a pad of different size you had to redraw it, and I sort of set by adding a small stack-based language that modified the padstack in place so that the user can just type in the dimensions as usual. And September 2017 was a pretty big month since I added the pool manager that allowed for managing all of the library elements without CLI at all, and I also managed to integrate KCAD Router, which was about 2,000 lines of code on my side, and like 20,000 from the KCAD Router, and so that was a pretty good return of investment, since the KCAD Router really helps to make the board editor actually usable for actual projects. In October, then came Copper Plains and a 3D view that at that time only could show the board without any packages, and that was mostly driven by me wanting to do OpenGL the proper way, so actual 3D, then just the 2D rendering for schematic and board, and that view just works by dumping the board as polygons and triangulating them and rendering them, so pretty basic stuff, and I think it was also less than 2,000 lines of code. Since the 3D view is pretty much ornamental without packages showing, I added step import and end export, and for the import, I used the code, the OpenCascade, with the code from PyCAD to use OpenCascade to triangulate, to convert a step model into triangles, and then render that, and the step export was adapted from KCAD to step. April 2018, then saw the start of a master thesis, which was an X-plane transmitter, so a moderately complex design with FPGAs, and DTA converters to differential pairs, and about 10 gigahertz in output frequency, so that was the first real-world project, that was also not too simplistic. That then motivated me to speed up DRC by making it multi-threaded, which was pretty easy, since DRC just involves intersecting polygons, and there are quite many of them, so just spawn threads and let them do the work, that helped a lot, and then also added export for bill of materials, and later in that year, I unified the pull-in project manager, since users ran the TAPI that they had two entry points for the application, and now we only have one application, they then click on the desktop as they expected. And October 2018, also configurable colors, since users were complaining about the color scheme, not suiting their preferences, and I didn't want to force my taste on everyone else, so I decided to make it configurable, so that could have happened, so users might wish for that earlier, but it was one of the things that wasn't that much fun, so it had to wait for a while. January 2018, or January 2019, then saw some other improvements, such as parametric search in the pool, since with that many passives in there, you will need to have a proper way to search for them, and my approach for doing this was to add a parametric search at your SNL from distributors, and so you can search capacitors by value and tolerance and so on. I then also added a proper PDF export, actually PDF export has been in there since more or less day one, but that just exported what was sent to OpenGL, so if you had a polygon, you got triangles in the PDF, and the new PDF export actually exports polygons and also makes text searchable, and adds a proper table of content, so you can easily navigate your sheets, and I also added the incremental pool update, since if you change something, it had to rescan all the files to update them into the SQLite database, and that took 10 to 15 seconds each time you edited something, and with that change it just updated what actually changed, since for the first implementation, the focus was on getting it correct and not fast, and then I decided to add more speed with that one. So in November 2019, I then added the part info API from Kitspace, so that you can see the stock at DigiKey and other distributors right in the part browser, so you know which parts are actually on the shelf, especially important for passives, where there are quite a lot with similar specs, and you want to pick that one that has the most stock. And last but not least, and so now we are at the present date, in January 2020 or February, where after exactly three years since the public commit, I released version 1.0, so since we are now at the current date, I'd like to talk a bit about something else, namely taking care of dependencies, since pretty much every other open source project, Horizon EDA wouldn't have been possible without dependencies, and I think it's an imperative for every open source developer to treat their dependencies as part of their project, since if the dependency has a bug and you just complain to you, you can't tell them it's the dependencies fault, they want you to fix it. There are actually quite a numerous bugs that got fixed as a direct consequence of my development on Horizon EDA, so the most important one that GTK is an open GL area, which I rely heavily on for displaying schematic boards and basically everything broke in very strange ways when your application had one then more window open that had a GL area in them, took quite a while to debug, but eventually fixed it, and another Windows later thing was Lipkid 2 that had a regression that broke, that made a tech fault due to reallot input path, that was also quite interesting to debug, and a rather odd bug was that 0MQ, which I use for IPC, I decided to use the current locale when formatting port numbers, so when the current locale at that time was set to locale that had a thousand separators, the port number would include a thousand separators, which would then break everything, and that was also quite easy to get fixed, and not a direct dependency, but I noticed that Ccache, which I use for speeding up compilation, stopped recognizing the headers, and that was also a regression that got unnoticed, but was also quite easy to fix, and in general my whole experience in dealing with the other projects was quite positive, since I was always able to provide a very concise test case, and that they were easy to fix. So you might be wondering what's next, that might be a bit un-exciting, since my development will go on as usual with no really big banks plans so far, so I'll do what's on my mind and what users suggest, and that's it, and now we have time for questions. So the question was how I imported the bits and pieces from Kaikai I use, I just copy pasted their code in there, and made a few adjustments to make it compatible in my environment, but it's not linked in any way, so I'll have to update it manually, and there also was a, related to that, there was a bug in the router that made it not recognize large clearances, I noticed that bug, it took me a few hours to fix it, the next day I had a look at Kaikai's commit history and found that they fixed the bug a few months ago. How have users responded to your policy of only including orderable parts in the library? Okay, so the question was how users have responded to my policy of only including orderable parts in the library, for the response have been a bit mixed, somewhere a bit, some found it a bit too restrictive, but I think it really makes a bomb export a lot easier. Yes, so since I am from Stuttgart, and there, okay, so the question is if there were any projects done with it, they weren't done by me, so at Stuttgart there's at the duale Hochschule, there's a Formula Student team that built electric race cars, and since a year or so they're using Horizon EDA for their board work. So what should Kaikai look to import from Horizon? So the question was what Kaikai could learn from Horizon EDA, so I think that's a bit a difficult question to answer since my decision for not working on Kaikai and starting my own project was like that I wasn't as same as with library, I wasn't satisfied with the library concept and that's something that you pretty much can't import since it's the very foundation of the program and if you change that, that wouldn't be Kaikai anymore, and so some things that might be, so as Clement suggested, might be the length tuner, I unfortunately don't have a slide for it, but it gives you a progress bar like indication of many tracks, so that allows you to easily tune differential buses. So the question was if there's a migration path to import Kaikai projects, unfortunately not, so but what you can import is packages. So since the projects at the current state mostly developed by me and my time is limited, so I think I can spend my time otherwise that's more productive. So I think it's most, so the question was what third import options are on the roadmap, so I think what makes most sense is to import library elements like symbols and packages. So right now the package import works quite well and I'm looking into doing the doing a symbol import, so Kaikai would be would be the biggest option since their file format is pretty reasonable.