Bruhin Launches LibrePCB to Challenge KiCad Library Architecture

Introduction to LibrePCB A new, powerful and intuitive EDA tool for everyone — FOSDEM

FOSDEM

Legacy electronics design suites cannot be fixed through incremental patches because their underlying library models are fundamentally flawed, necessitating a ground-up rebuild around unique identifiers to enable automated dependencies and clean version control.

AI-assisted summary of Introduction to LibrePCB A new, powerful and intuitive EDA tool for everyone — original source. Check the original for full context.

Source published:

Key ideas

  • Urban Bruhin launched LibrePCB, an open-source EDA suite built from scratch in C++11 and Qt 5 for Linux, Windows, and macOS, targeting major workflow and library pain points found in legacy tools. (0:04)
  • LibrePCB replaces name-based references with permanent UUIDs across all entities (symbols, packages, pins, and pads), preventing broken links and enabling built-in automated dependency resolution. (4:13)
  • A multi-tiered library architecture formally decouples abstract components from symbol styles and physical footprint variants, preventing combinatorial explosion across devices and packages. (6:39)
  • The platform supports managing multiple independent PCB layouts from a single schematic within one project, keeping connectivity synchronized in real time across different package choices. (14:55)

Detailed notes

## Background Published on YouTube by the FOSDEM channel on February 5, 2018, this presentation features developer Urban Bruhin introducing LibrePCB at FOSDEM 2018. The talk serves as an introduction to LibrePCB, presenting it as a new, powerful, and intuitive open-source EDA tool designed to streamline electronics design for everyone.

## TL;DR Frustrated by the clunky library management, broken version control workflows, and path-configuration mazes of existing tools like KiCad and Eagle, Urban Bruhin built LibrePCB from scratch in C++ and Qt. The suite introduces UUID-based asset tracking, automated dependency resolution, and a clean separation between abstract schematic symbols and physical package variants. Bruhin demonstrates a live workflow featuring real-time schematic-to-PCB synchronization and the ability to maintain multiple distinct board layouts from a single schematic. While core systems like library management and Gerber export are functional, Bruhin outlines the roadmap toward a stable 1.0 release, prioritizing file-format stabilization and board-editor refinement.

## Atmosphere & style The presentation carries the classic, earnest charm of a grassroots open-source conference talk, marked by understated enthusiasm and technical pragmatism. Bruhin speaks with modest, unhurried Swiss precision, candidly acknowledging rough edges, placeholder circuits, and work-in-progress quirks in the board editor without defensiveness. The room feels engaged and technically discerning, resulting in an authentic demo environment where the relief of escaping legacy EDA friction genuinely resonates with the audience.

## Bulletin - [00:04](https://www.youtube.com/watch?v=vu-h5y6tK34&t=4s) Urban Bruhin launched LibrePCB, an open-source EDA suite built from scratch in C++11 and Qt 5 for Linux, Windows, and macOS, targeting major workflow and library pain points found in legacy tools. - [04:13](https://www.youtube.com/watch?v=vu-h5y6tK34&t=253s) LibrePCB replaces name-based references with permanent UUIDs across all entities (symbols, packages, pins, and pads), preventing broken links and enabling built-in automated dependency resolution. - [06:39](https://www.youtube.com/watch?v=vu-h5y6tK34&t=399s) A multi-tiered library architecture formally decouples abstract components from symbol styles and physical footprint variants, preventing combinatorial explosion across devices and packages. - [14:55](https://www.youtube.com/watch?v=vu-h5y6tK34&t=895s) The platform supports managing multiple independent PCB layouts from a single schematic within one project, keeping connectivity synchronized in real time across different package choices.

## Key takeaways - [00:04](https://www.youtube.com/watch?v=vu-h5y6tK34&t=4s) LibrePCB was created from scratch due to deep frustration with legacy EDA tools suffering from poor library management, clunky interfaces, and Git-unfriendly file formats. - [02:06](https://www.youtube.com/watch?v=vu-h5y6tK34&t=126s) Traditional EDA suites like KiCad and Eagle burden users with complex directory paths, environment variables, and manual dependency tracking. - [04:13](https://www.youtube.com/watch?v=vu-h5y6tK34&t=253s) All library elements—including symbols, packages, pins, and pads—use persistent UUIDs so display names can change without breaking project references. - [04:13](https://www.youtube.com/watch?v=vu-h5y6tK34&t=253s) LibrePCB features an integrated library manager with automated dependency resolution that downloads required upstream libraries seamlessly in the background. - [06:39](https://www.youtube.com/watch?v=vu-h5y6tK34&t=399s) Separating abstract components from symbol variants allows designers to switch between European (IEC) and American (IEEE) conventions without duplicating device data. - [06:39](https://www.youtube.com/watch?v=vu-h5y6tK34&t=399s) A dedicated package layer decouples logical pad mappings from physical footprint variants, avoiding combinatorial explosion across device variants. - [10:20](https://www.youtube.com/watch?v=vu-h5y6tK34&t=620s) Project data is split across fine-grained, human-readable S-expression files (.lp) with auto-generated .gitignore files to isolate design changes from transient GUI state. - [12:54](https://www.youtube.com/watch?v=vu-h5y6tK34&t=774s) At the time of presentation, core library and schematic systems were functional, while the board editor remained in active development lacking DRC and copper planes. - [14:55](https://www.youtube.com/watch?v=vu-h5y6tK34&t=895s) Designers can place abstract schematic components first and defer choosing concrete physical packages or footprint variants until layout. - [14:55](https://www.youtube.com/watch?v=vu-h5y6tK34&t=895s) A single schematic can drive multiple independent board layouts simultaneously, maintaining real-time netlist synchronization across all variants. - [17:57](https://www.youtube.com/watch?v=vu-h5y6tK34&t=1077s) A working Gerber generation engine is built directly into LibrePCB, allowing end-to-end output verifiable in tools like Gerbv. - [18:48](https://www.youtube.com/watch?v=vu-h5y6tK34&t=1128s) The primary development roadmap priorities are finalizing the file format specification against breaking changes and improving board editor ergonomics. - [20:07](https://www.youtube.com/watch?v=vu-h5y6tK34&t=1207s) Retrofitting a fundamentally decoupled, UUID-based library architecture onto legacy codebases like KiCad was considered impractical, justifying a clean-slate implementation. - [20:07](https://www.youtube.com/watch?v=vu-h5y6tK34&t=1207s) Manufacturer part numbers and distributor order codes are planned additions for the library system, while panelization and multi-view layouts remain future release goals.

## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=vu-h5y6tK34&t=4s) Origins and Motivation for a New EDA Tool

Urban Bruhin, a developer from Switzerland, introduces LibrePCB as a new, open-source EDA (Electronic Design Automation) tool suite built to provide a modern, intuitive electronics design workflow. LibrePCB is fully multi-platform, running on Linux, Windows, and macOS, and has been developed from scratch in C++ using the Qt framework. Bruhin kicked off the project around five years prior (circa 2013), hosting the source code publicly on GitHub.

The initial impulse to build an entirely new tool stemmed from profound frustration with the existing open-source and proprietary electronics software landscape at the time. Reflecting on the state of tools like KiCad half a decade earlier, Bruhin found that existing software suffered from fundamentally broken workflows. The most severe pain points centered on inflexible library architectures, awkward user interfaces, and file formats that actively resisted version control systems like Git—either because they relied on opaque binary blobs or generated messy, unmergeable text files.

- **Technology Stack:** Written from scratch in C++ and Qt - **Supported Platforms:** Linux, Windows, macOS - **Project Age:** In active development since roughly 2013 - **Repository:** Hosted as open source on GitHub

---

[02:06](https://www.youtube.com/watch?v=vu-h5y6tK34&t=126s) The Pain of Existing Library Management

Examining existing EDA software reveals deep structural flaws in how component libraries are stored, shared, and configured. Many legacy tools force different file formats onto different types of library assets—one format for schematic symbols, another for PCB footprints, and potentially yet another if SPICE simulation models are introduced later. Furthermore, existing suites routinely offload the burden of library maintenance onto the end user. They lack integrated package managers, leaving engineers to manually track down zip files from vendor websites, place them in arbitrary directories, and resolve component dependencies by hand.

Bruhin illustrates this cognitive overload by highlighting the configuration panels in Eagle and KiCad. In KiCad's footprint and schematic library managers, users are greeted by dense grids of hardcoded absolute paths, environment variables, path substitution aliases, and confusing distinctions between project-specific and global library tables. When an engineer simply wants to place a part, navigating this maze of file paths creates needless friction.

As Urban Bruhin summarizes his reaction to these traditional workflows: “I asked myself why so complicated I just want to use these libraries so my answer is it doesn't have to be that complicated.”

---

[04:13](https://www.youtube.com/watch?v=vu-h5y6tK34&t=253s) UUID-Based References and Automated Dependencies

LibrePCB addresses these library shortcomings by integrating a built-in library manager directly into the application, complete with an automated dependency resolution engine. When a user chooses to install a library that relies on upstream symbols or components, LibrePCB fetches and configures all required dependencies automatically in the background.

```mermaid flowchart TD accTitle: LibrePCB Architecture accDescr: Diagram showing how UUID-based references eliminate broken links across decoupled library entities.

subgraph LibraryA["Library A"] CMP["Component UUID"] end

subgraph LibraryB["Library B"] SYM["Symbol UUID"] PIN["Pin UUIDs"] end

subgraph LibraryC["Library C"] PKG["Package UUID"] PAD["Pad UUIDs"] end

CMP -->|"persistent reference"| SYM CMP -->|"persistent reference"| PKG SYM --- PIN PKG --- PAD ```

A core architectural flaw in legacy tools is referencing items across libraries strictly by human-readable names, which causes broken references whenever an item is renamed, triggers name collisions, and prevents parts in one library from cleanly sharing assets with another. LibrePCB instead assigns permanent Universally Unique Identifiers (UUIDs) to every individual entity in the library system—including symbols, components, packages, pins, and pads.

Because entity identities are decoupled from their display labels, users can rename symbols or pins at will without breaking downstream projects. This UUID scheme is expressed cleanly within LibrePCB's S-expression (`.lp`) file format, where the unique identifier acts as the primary key and the display name is merely an editable metadata attribute.

As Urban Bruhin emphasizes regarding this seamless setup: “probably the 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”.

---

[06:39](https://www.youtube.com/watch?v=vu-h5y6tK34&t=399s) Decoupling Symbols and Packages: Variants vs. Combinatorial Explosion

Conventional tools often lack the semantic hierarchy needed to represent real-world electronic components cleanly. For instance, a basic resistor may need an IEEE/American zigzag symbol or an IEC/European rectangular symbol. In software like Eagle, achieving this requires creating entirely separate component entries for each visual style, which then forces the designer to duplicate every associated device mapping and package footprint across each component clone.

LibrePCB solves this duplication crisis by introducing a formal separation between the abstract **Component** and its **Symbol Variants**. There is only one central resistor component in the database, but it can hold multiple interchangeable graphical representations (such as European and American styles) without replicating any device metadata.

```mermaid flowchart LR accTitle: Device and Package Abstraction accDescr: Flowchart illustrating how LibrePCB avoids many-to-many relationship explosions between devices and footprint variants.

subgraph Devices["Devices"] D1["Device 1 (e.g. LM7805)"] D2["Device 2 (e.g. LM317)"] end

subgraph PackageEntity["Package Abstraction"] PKG["Package: TO-220 (Defines Pad UUIDs)"] end

subgraph Footprints["Footprint Variants"] FP1["Vertical / Standard"] FP2["Horizontal / Flat"] FP3["Hand-soldering Pads"] end

D1 --> PKG D2 --> PKG PKG --> FP1 PKG --> FP2 PKG --> FP3 ```

A parallel issue plagues physical footprints. Physical components such as a TO-220 voltage regulator frequently require multiple footprint variations—for vertical mounting, horizontal mounting, or oversized pads designed specifically for hand-soldering rather than reflow ovens. Without an intermediate abstraction layer, every single device variant must maintain an explicit link to every single physical footprint variant, triggering an unmanageable $N \times M$ combinatorial explosion of relationships.

LibrePCB resolves this by inserting a dedicated **Package** entity. The package defines the logical pad layout and pin assignments, allowing devices to link solely to the package. The package itself then encapsulates as many alternative footprint implementations as needed.

---

[10:20](https://www.youtube.com/watch?v=vu-h5y6tK34&t=620s) Designing File Formats for Human Readability and Git

Version-controlling board designs is notoriously painful in existing EDA suites because files routinely mix essential design data with volatile UI state. Checking in a PCB often produces massive diffs containing local changes even when no traces or schematics were modified. Bruhin demonstrates this by showing a diff from a KiCad board file where simply panning, zooming, and toggling visibility layers altered internal view state and flipped individual floating-point bits, creating false modifications.

LibrePCB counters this by distributing project data across multiple smaller, specialized files rather than dumping an entire design into one monolithic file. This high granularity makes it straightforward to distinguish critical board changes from transient editor state. To prevent common tracking mistakes, LibrePCB automatically initializes a suitable `.gitignore` file inside every newly created project directory.

Beyond splitting files, Bruhin stresses that text-based storage does not automatically equal human readability: “not every text-based file format is human readable you you need to control every tiny detail of the file format to me to make it as readable as possible and in LibrePCB I consider parts of files which are not really human readable as bugs and bugs need to be fixed”.

---

[12:54](https://www.youtube.com/watch?v=vu-h5y6tK34&t=774s) Development Status and Live Demonstration

Reviewing the software's readiness, Bruhin explains that while foundational subsystems are solid, LibrePCB is still early in its journey toward a 1.0 release:

- **Library Management:** Highly functional with automatic dependency resolution. - **Library Editor:** Functional for basic creation tasks, but still limited in scope. - **Schematic Editor:** Stable and usable for basic schematics, though missing convenience features like copy-and-paste. - **Board Editor:** Actively under heavy development; lacking copper planes, airwires (ratsnest), and a Design Rule Check (DRC), though basic Gerber export already works. - **Stability Warning:** The on-disk file format is not yet finalized or guaranteed to be forward-compatible across future releases.

Bruhin runs a live demonstration using an official standalone Linux AppImage downloaded directly from the web. Launching it for the first time, the application prompts the user to establish a workspace directory. Upon opening the main control panel, the interface alerts the user that no libraries are currently installed. Opening the built-in Library Manager presents an online repository catalog. Selecting a desired component library automatically marks and installs its required upstream dependencies, confirming that the automated package management functions out of the box without requiring manual file manipulation.

[14:55](https://www.youtube.com/watch?v=vu-h5y6tK34&t=895s) Live Demo: Schematics, Multi-Board Layouts, and Real-Time Sync

Urban Bruhin walks through a live demonstration of LibrePCB, starting by opening some downloaded libraries and creating a brand new project. Moving into the schematic editor, he places a few sample components to demonstrate how intuitive the workflow is. He highlights the flexibility of the library system right away: for basic parts like capacitors, users can seamlessly choose between European and American schematic symbols. Furthermore, designers do not have to commit to physical packages upfront; they can place an abstract component—such as a generic n-channel MOSFET without assigning a footprint—or select an exact device immediately. He wires up a simple circuit with a resistor, transistor, and ground, admitting with a chuckle that the dummy circuit “doesn't make sense,” but serves to illustrate the process.

```mermaid flowchart TD accTitle: LibrePCB Schematic and Multi-Board Workflow accDescr: Diagram showing how a single schematic feeds multiple independent board layouts in LibrePCB.

subgraph Schematic["Schematic Editor"] SCH["Schematic Circuit<br/>(Generic or Exact Components)"] end

subgraph Boards["Board Editor Options"] B1["Board Layout 1<br/>(e.g., SMD Variant)"] B2["Board Layout 2<br/>(e.g., TO-220 Through-Hole)"] end

SCH -->|"Synchronized in Real Time"| B1 SCH -->|"Synchronized in Real Time"| B2 ```

Switching over to the board editor, LibrePCB displays a dock listing unplaced parts that are missing from the PCB layout. Bruhin assigns specific packages and packages devices on the fly, picking a resistor and choosing from two available device options for the MOSFET. For the TO-220 package, he demonstrates selecting between different mounting variants (such as vertical or bent horizontal mounting). He then reveals a standout feature: users can duplicate a board layout to maintain multiple independent PCB designs within the same project. One board can use surface-mount devices while the duplicate can use alternative through-hole footprints or different mounting orientations. Despite these independent packaging choices, the underlying connectivity remains strictly synchronized with the schematic. As Bruhin observes, “And also the important the schematic is also in think is always in sync so for example if I remove on the resistor it disappears from both ports in the time yeah yeah it's so it's like an eagle basically.”

- **Symbol flexibility:** Supports switching between American and European schematic symbols at placement time. - **Packaging decoupling:** Designers can place logical symbols first and defer choosing footprints or packaging variants until layout. - **Multiple boards per project:** Projects can hold more than one board design side by side, allowing different form factors or mounting variants for the same schematic. - **Live synchronization:** Deleting or altering parts in the schematic instantly propagates across all corresponding boards in the project.

[17:57](https://www.youtube.com/watch?v=vu-h5y6tK34&t=1077s) Board Editor Status and Gerber Export

Bruhin encounters a minor hiccup when attempting to delete a part directly from the board layout, taking the opportunity to remind the audience about the software's development status. He explains that deleting a component from a board removes its placement rather than deleting the electrical symbol, returning it to the list of unplaced board items while leaving it untouched on any alternative board layouts. He candidly acknowledges that the layout workspace is still an active work in progress: “I say it already the board editor is in working progress so there are some yeah strange things.”

To prove that the pipeline is already functional end-to-end, Bruhin shows off the built-in Gerber exporter. Even though it is currently a bare-bones implementation lacking detailed customization dialogs, it functions reliably with a single click. He presses generate, opens the output directory, and invites the audience to verify the result: “And if you didn't don't trust me the files are generated in this so yeah so you can just open them we care for you for example and here it is so very simple but it works.” He opens the exported files in Gerbv, displaying the rendered PCB layers on screen.

[18:48](https://www.youtube.com/watch?v=vu-h5y6tK34&t=1128s) Development Roadmap and Tech Stack

Looking ahead, Bruhin details the immediate milestones required before LibrePCB can reach general readiness. The team's top focus is finalizing and stabilizing the underlying file format to ensure that users do not experience breaking changes after release. Following that, polishing the board editor into a comfortable, mature tool is essential, as Bruhin admits that using the current incomplete editor “doesn't make fun like that,” even though it is technically mature enough to produce Gerber files and order physical PCBs. He invites community members to join the effort before opening the floor to questions: “The first the highest priority at the moment is to stabilize the file format so to the loss breaking changes and to create the first stable release.”

In response to the first audience question regarding the implementation details, Bruhin explains that LibrePCB is engineered in modern C++11 and utilizes the Qt 5 framework for its cross-platform graphical user interface and core libraries.

- **Primary milestone:** Finalize the file format specification and eliminate breaking schema changes. - **Secondary milestone:** Enhance board layout ergonomics, routing tools, and editing features to deliver an enjoyable user experience. - **Implementation stack:** Built using modern C++11 and Qt 5. - **Community call:** Welcomes outside contributors and developers to accelerate core feature development.

[20:07](https://www.youtube.com/watch?v=vu-h5y6tK34&t=1207s) Q&A: Architectural Differences with KiCad, Part Numbers, and Views

An audience member asks why Bruhin decided to build a brand new EDA tool from scratch rather than contributing his efforts to existing open-source projects like KiCad. Bruhin explains that his reasoning mirrors the rationale given by the Horizon EDA project: EDA software is fundamentally constrained by its library architecture, and retrofitting a fundamentally different library paradigm onto an established codebase is virtually impossible. Addressing this deep structural divide, Bruhin explains: “Because I think the library system is that important part of over EDI tool and it's it's a very fundamental low-level part and it's very hard to change this concept and I think in liebherr PCB the concept is completely different than in kicad.”

```mermaid flowchart LR accTitle: KiCad vs LibrePCB Library Design Philosophy accDescr: Flow comparison showing KiCad's symbol-footprint mapping compared to LibrePCB's multi-layered semantic component model.

subgraph KiCad["KiCad Traditional Approach"] direction TB KSYM["Schematic Symbol"] -->|"Direct association / netlist mapping"| KFP["PCB Footprint"] end

subgraph LibrePCB["LibrePCB Structured Approach"] direction TB LSYM["Abstract Component / Symbol"] --> LDEV["Device Model"] LPKG["Package & Footprint Options"] --> LDEV LDEV -->|"Integrated Parts & Assembly Variants"| LBRD["Board Layouts"] end ```

The Q&A continues with audience questions regarding component sourcing and multi-panel board visualization:

- **Order codes and manufacturer part numbers:** When asked whether distributor order numbers and exact manufacturer part numbers are embedded inside the library system, Bruhin clarifies that they are not included yet. However, he emphasizes that clear plans are already in place to integrate ordering codes and part numbers directly into the library architecture in a future update. - **Multiple board views and panels:** An attendee asks whether LibrePCB intends to support having multiple synchronized views of the same board (such as viewing specific sub-regions or setting up multi-board panelization). Bruhin responds that although it is not currently planned for the initial release, having multi-view board support would certainly be a valuable addition down the line.

## Notable quotes > [10:20](https://www.youtube.com/watch?v=vu-h5y6tK34&t=620s) in LibrePCB I consider parts of files which are not really human readable as bugs and bugs need to be fixed — Urban Bruhin

## Mentioned Urban Bruhin, LibrePCB, FOSDEM, KiCad, Eagle, Horizon EDA, Git, GitHub, C++, Qt, Linux, Windows, macOS, AppImage, Gerbv, SPICE

## Video description by Urban Bruhin

At: FOSDEM 2018 Room: K.4.201 Scheduled start: 2018-02-03 16:00:00+01

[Source](https://www.youtube.com/watch?v=vu-h5y6tK34)

中文简报

Bruhin推出LibrePCB,挑战KiCad的元件库架构 传统电子设计软件无法通过渐进式补丁来修复,因为其底层元件库模型存在根本性缺陷,必须围绕唯一标识符进行彻底重构,以实现自动化依赖项处理和清晰的版本控制。 由于对KiCad和Eagle等现有工具中笨拙的元件库管理、易损坏的版本控制工作流以及复杂的路径配置深感不满,Urban Bruhin使用C++和Qt从零构建了LibrePCB。该套件引入了基于UUID的资源跟踪、自动化依赖项解析,并将抽象原理图符号与物理封装变体清晰分离。Bruhin现场演示了原理图与PCB实时同步的工作流,以及基于单一原理图维护多个不同电路板布局的功能。尽管元件库管理和Gerber导出等核心系统已可正常使用,但Bruhin仍概述了迈向1.0稳定版的路线图,并将文件格式稳定化和电路板编辑器优化列为优先事项。 Urban Bruhin推出了LibrePCB,这是一款面向Linux、Windows和macOS、使用C++11与Qt 5从零构建的开源EDA套件,旨在解决传统工具中存在的主要工作流和元件库痛点。 (0:04) LibrePCB在所有实体(符号、封装、引脚与焊盘)中均采用永久UUID取代基于名称的引用,从而防止链接失效,并实现了内置的自动化依赖项解析。 (4:13) 多层级元件库架构将抽象元器件与符号样式及物理封装变体正式解耦,防止了器件与封装之间出现组合爆炸。 (6:39) 该平台支持在单个项目内由单一原理图管理多个独立的PCB布局,并在不同封装选择下保持连接关系的实时同步。 (14:55)

Source quotes

[10:20] Urban Bruhin: in LibrePCB I consider parts of files which are not really human readable as bugs and bugs need to be fixed

Original transcript

[0:04] okay welcome everybody and to my talk [0:10] about Liberty City [0:11] my name is whip unproven from I'm so [0:15] from Switzerland and yeah [0:19] so first what sleeper PCB it's actually [0:25] similar to horizon and EDI twill a new [0:29] open-source EDI tool and it's multi [0:34] platform so it works on Linux Windows [0:37] and Mac OS and it's written from scratch [0:40] in C++ and cute and I started [0:46] development in about five five years ago [0:50] so yeah and there's the code is on [0:54] github so you can check it out and first [1:00] the reason why I created a new EDA tool [1:04] basically also the frustration about [1:07] existing tools and five years before now [1:14] think about how kicad was then and so on [1:18] and it was I I was really frustrated [1:21] about the existing tools and the main [1:25] reason is basically the library system [1:27] which is very limited in other tools and [1:31] also the file format especially when [1:34] using version control systems and other [1:37] EDI tools yeah they have a file format [1:41] if it's maybe it's binary then yeah good [1:47] luck but if you have locked and it's [1:50] text-based but still not very good suite [1:54] for version control and also the [1:57] usability is often not very great of the [2:01] tool so about something about the [2:06] library management and one thing is [2:09] other tools have different library file [2:14] formats for different kind of library [2:16] types so for example one [2:18] library type 4 components one for [2:21] footprints and so on and I think this is [2:25] not really nice for users because maybe [2:29] the tool some some time has adds support [2:33] for spice models or something like that [2:35] it also introduces a new file format for [2:38] libraries and yeah and the other thing [2:42] is tools do not really completely handle [2:44] library management so there is often no [2:48] integrated tool to install and update [2:50] libraries and if libraries have [2:53] dependencies so the the tool does not [2:57] handle this so you as a user needs to [3:00] handle dependency management and the [3:04] project library management is also a [3:07] little bit complicated sometime so the [3:12] result is actually the user has a lot of [3:15] work to handle or to manage his [3:17] libraries he wants to use and that's [3:19] quite a pain so and for example as a [3:24] Eagle user you maybe know this website [3:27] where you search for libraries download [3:30] something and install it manually or in [3:33] kicad in the schematic editor and this [3:38] is the library configuration dialog or [3:41] in the food and board editor and I see a [3:47] lot of file paths there and some [3:51] environment variables and tough [3:54] substitutions and project specific [3:57] libraries global libraries and so on and [3:59] I asked myself why so complicated I just [4:05] want to use these libraries so my answer [4:10] is it doesn't have to be that [4:12] complicated [4:13] so in labor PCB I integrated the library [4:16] manager and to update and install [4:20] libraries and it also has a simple [4:23] library dependency management system so [4:26] if you download a library which like [4:29] library a which depends on library [4:31] the library's automatically installed [4:34] when you install lively library a and [4:37] probably the the most important thing is [4:41] the application basically handles [4:44] everything for you [4:45] so you don't have to care about [4:47] libraries they just work so because [4:51] there is no reason to make this very [4:53] complicated and another thing is [4:57] actually similar to the horizon tool and [5:00] the problem of other tools is they [5:02] reference many things just by name and [5:05] in some tools it's even not possible to [5:08] reference library elements between [5:11] across library so you can't use a [5:14] component from library a with a symbol [5:19] from library B and so on and the result [5:23] is there are often broken references [5:26] when changing names or name conflicts [5:29] and many duplicates because yet they [5:33] cannot be shared between libraries and [5:36] the solution is actually the same as in [5:39] horizon we use new your IDs for every [5:42] kind of every entity in the library so [5:46] every symbol every pin every pet [5:48] everything has a new ID which never [5:51] changes so you can change the names and [5:54] so on and it doesn't have any effect it [5:58] doesn't break anything so and it's also [6:02] possible to reference libraries across [6:05] LA a reference entities across different [6:09] libraries for example if you take a look [6:14] at file format of liberal PCB which is [6:18] based on s expressions you can see that [6:21] there are many new you IDs there for [6:23] example a symbol looks like that at the [6:27] top is the new UI T of the symbol itself [6:29] and the name is just a property which [6:32] you can change anytime and the same for [6:36] every pin [6:39] so another problem of existing library [6:43] systems is there is no way to have [6:48] different symbols for the same component [6:50] so for example a resistor can have an [6:55] American or European symbol and but [7:00] there is no solution for that in in many [7:02] tools and this results in duplicated [7:05] components with same exactly same [7:08] functionality but different symbol in [7:12] for example in Eagle it looks like this [7:16] so if you have a resistor component and [7:19] it's resistor symbol and the resistor [7:22] has for example three devices and it [7:26] looks like that and if you want to have [7:29] an American resistor simple you have to [7:34] create an American resistor component [7:37] and you can't use the device from the [7:40] European resistor so you have to copy [7:42] them and maybe there is even another [7:45] variant of this symbol and you have many [7:48] duplicates of devices and this is quite [7:53] a mess so the quality of library gets [7:55] worse and worse yeah [7:58] so the solution of Libra PCBs there is [8:03] an entity called components and simple [8:07] variant so there is only one component [8:10] for a resistor and it can have as many [8:15] representation variants as you like so [8:18] we can create one for the European [8:21] symbol one for the American or what [8:24] whatever you want a similar problem is [8:30] with packages or footprints because [8:34] libraries do not have an abstraction [8:36] layer for packages for example this [8:38] to-220 package this is three times the [8:43] same package but three different [8:44] footprints and this is quite common for [8:46] example you have different footprints [8:49] for the different mounting variants or [8:51] different [8:53] sighs of pet because one for reflow [8:56] soldiering one throwhand soldiering and [8:59] so on but libraries do not provide a way [9:02] to abstract this and so the result is [9:07] every device need to know every [9:09] footprint variant of their package for [9:12] example if you have a voltage regulator [9:16] in a to-220 package and there's one [9:24] relation between them if you have one [9:27] more device using that footprint you [9:29] have one more relation but if you have [9:32] some different footprint for the same [9:34] device for example this time without the [9:37] mounting hole you have many too many [9:40] relations and let's add one more device [9:45] and more footprints and you can see you [9:48] have many too many relation between [9:51] devices and footprints and that's quite [9:53] a nightmare in a library system so [9:56] liberal PCB adds an entity called [9:59] package which doesn't know anything [10:02] about footprints directly but only what [10:05] pads it has and a device reference is [10:08] only a package and the package can [10:10] contain as many footprint variants as [10:13] you like so the next problem is version [10:20] control systems and it quite hard to [10:24] version control ETA e-files because it [10:29] often important and unimportant data is [10:32] mixed so you cannot just check in the [10:36] important data but not unimportant and [10:39] it's often even unclear if files to put [10:42] on the version control and which not and [10:45] typical results is you have local [10:48] changes even if you didn't modify [10:50] anything in a project or very large [10:53] diffs and merging is for sure impossible [10:58] and leave a PCP solves this by using [11:02] many smaller files instead of one thing [11:05] with big file [11:06] so it's you have higher granularity and [11:10] you can easy to distinguish between [11:14] important unimportant data and one very [11:18] simple improvement is that will [11:21] automatically create a technophile so [11:23] the user doesn't need to know which [11:26] files to check in or not and another [11:31] thing is and this is a death of a key [11:34] cat [11:35] PCB file I just created the PCB open it [11:38] the editor zoomed around switched some [11:41] troublesome layers on and off save the [11:44] project and looked at the TIF and this [11:46] is to death and you can see there are [11:49] changes which actually you don't want to [11:51] check in these because they are only [11:53] irrelevant data and the at the bottom [11:58] there is actually the def is one bit of [12:01] some number I don't know the exact [12:04] reason of it and this brings me to the [12:08] next point files are not really human [12:10] readable so Tiff's are hard to [12:14] understand and version control system [12:17] and they are hard to use on these files [12:20] so my solution is basically first don't [12:25] just consider text-based file formats as [12:27] human readable not every text-based file [12:30] format is human readable you you need to [12:33] control every tiny detail of the file [12:35] format to me to make it as readable as [12:37] possible and in debrief usually I [12:41] consider parts of files which are not [12:43] really human readable as box and box [12:46] need to be fixed so the current project [12:54] status is actually the library [12:56] management works pretty good the library [13:00] editor has only basic features it works [13:05] kind of but not very good and schematic [13:09] editor is also working pretty good [13:11] except some important features like copy [13:14] and paste and the board editor is a is [13:17] at mole at the moment work in progress [13:20] so there are no plane set no errors no [13:24] designer rule check and so on but [13:27] caliber export is possible basically and [13:30] of course the available libraries are [13:33] there aren't many flavors available but [13:37] and the most important thing is the file [13:40] format is not yet considered as stable [13:43] so you can use Libre fees be already for [13:46] some simple PCBs [13:48] but don't expect that you can open the [13:51] files for example in a year with the [13:54] newer version so to get started there [14:01] are nightly build available at the [14:03] moment for Linux and Windows and also [14:07] some documentation [14:09] ok now let's show a short demo this is [14:15] actually just at image I started [14:18] directly downloaded from the internet oh [14:20] and this is the only the first time it [14:25] says to create workspace then the [14:29] project [14:30] the control panel says you need to [14:33] install some libraries so you open the [14:36] library manager and these are the [14:37] libraries available in the Internet and [14:40] for example I want to install this [14:42] library it also selects the library here [14:45] because they are dependencies so and I [14:49] if I also like this this is also done so [14:52] let's use all these libraries they are [14:55] downloaded from the internet and here we [14:58] have some whatever some libraries ok so [15:04] now let's create a new project [15:11] then the schematic editor is here and as [15:16] an example I'd just add some components [15:19] so you can see how the workflow would be [15:22] for example capacitors are now available [15:26] in the European symbol or the American [15:30] symbol you know so you can just add [15:32] american variant or you can also choose [15:37] only a component or an exact device it [15:40] doesn't matter so this one is just an [15:43] n-channel MOSFET without choosing [15:46] already a footprint [15:47] so maybe ground you see make some [15:53] connections whatever doesn't make sense [16:00] but so ok and now in the board editor we [16:07] can see there are three parts which are [16:11] missing on the board right now so we we [16:14] can choose for example the resistor [16:16] choose the exact device edit and the [16:21] other devices and for example the MOSFET [16:25] we have two devices available at the [16:27] moment and for the tio 220 device we can [16:33] also choose between the different [16:35] mounting variants so let's add this one [16:38] and one cool feature is also you can [16:43] copy abort then you have two times the [16:46] same port and can work independently on [16:49] them so you can so for example in this [16:52] port you want to use the other device [16:56] you can just switch to the other one or [16:59] you can also choose just other mounting [17:03] variant and also the important the [17:07] schematic is also in think is always in [17:11] sync so for example if I remove on the [17:14] resistor it disappears from both ports [17:18] in the time yeah yeah it's so it's like [17:22] an eagle basically [17:24] and yeah you can okay [17:28] that's sorry oh okay it's right now it's [17:38] also not possible in [17:40] liberal-conservative to delete from the [17:42] board but it's planned to do that so if [17:46] I delete something it appears in this [17:49] list because it's not added to the to [17:51] this board but here it's still available [17:53] in the other world so okay and after [17:57] let's say you have okay that's just [18:00] because the I I say it already the board [18:04] editor is in working progress [18:06] so there are some yeah strange things [18:09] and there is even a very simple gerber [18:14] exporter without any option but you just [18:18] click generate and open the direction [18:21] and if you didn't don't trust me [18:24] the files are generated in this so yeah [18:29] so you can just open them we care for [18:33] you for example and here it is so very [18:40] simple but it works okay so I think this [18:47] is yeah so now the next steps the first [18:55] the highest priority at the moment is to [18:59] stabilize the file format so to the loss [19:01] breaking changes and to create the first [19:04] stable release and for that I also make [19:09] lead to make the board editor really [19:11] usable because it doesn't make fun like [19:16] that and but it's already possible to to [19:20] order PCB so and yeah the next step is [19:27] add more functionality but yeah so [19:31] contributors welcome of course and yeah [19:35] that's it [19:43] [Applause] [19:51] the language C++ 11 and cute five okay [20:07] the question was again why not at an [20:10] inset contributing to Cricut and [20:13] actually my answer is similar to the [20:16] horizon one because I think the library [20:21] system is that important part of over [20:24] EDI tool and it's it's a very [20:26] fundamental low-level part and it's very [20:31] hard to change this concept and I think [20:35] in liebherr PCB the concept is [20:36] completely different than in kicad so [21:15] okay but [21:55] so [22:00] so so your question is that the generic [22:05] device is where to order them dinner so [22:23] yeah so the question is the part numbers [22:27] are they a part order codes and for [22:30] exact partner numbers and so on if they [22:34] are included in the library and the [22:36] current answer is at the moment at the [22:39] moment it's not part of the library but [22:41] I already have plans how to integrate it [22:43] so it will be in the library later so [23:08] yeah [23:45] and I'm not sure you're asking about the [23:49] port editor or okay okay is it intended [23:56] to have multiple views of the same port [23:59] basically with other regions and it's [24:05] it's not planned this time but of course [24:10] it would be useful yeah [24:18] [Applause]