It’s not a secret that KiCad is the most popular EDA tool in the open-hardware community, and therefore many LibrePCB users worked with KiCad before. To help them getting started with LibrePCB, we implemented an importer for KiCad libraries so those already created library elements don’t need to be created again with LibrePCB.

In addition, even non-KiCad users could use this feature to import library elements from publicly available KiCad libraries instead of creating them manually. Thanks to the large KiCad community, there are a lot of such libraries! 😀

Drawing footprints can be error-prone — one wrong X- or Y coordinate of a pad and the package might not be solderable. To review your footprints more easily, the footprint editor allows you to set the package drawing from a datasheet as background image, so you’ll immediately see if any pad of polygon is off.

The image can either be directly captured as a screenshot, pasted from the clipboard, or loaded from a file:

Circuit design means reading datasheets a lot. For most parts more complex than a resistor or capacitor, you need to read its datasheet or other documentation.

Therefore the library editor now allows you to add datasheet URLs to components and devices. Those will then be available in the context menu in the schematic editor for easy access. In addition, parts which have an MPN & manufacturer specified also offer a Search datasheet menu item which will look for a datasheet in the Internet.

Whenever possible, datasheets are downloaded and opened with the local PDF reader. They are cached to keep them available without accessing the Internet again.

From time to time people ask whether LibrePCB contains an autorouter. Though there are different opinions about whether autorouters are useful or not, and even though LibrePCB still doesn’t have one built-in, luckily you can now use an external autorouter like Freerouting for LibrePCB boards!

This is possible by supporting the Specctra DSN/SES exchange format, which also allows routing a LibrePCB board manually with an external tool to circumvent the still rudimentary integrated trace routing tools.

In addition to the already mentioned features, there have been several more noteworthy features implemented which increase productivity a lot:

Thanks to a contribution from mi4code, LibrePCB on Windows now automatically uses a dark theme if Windows itself is set to a dark theme. Also for macOS and Linux (which already supported dark theme) there are some dark theme improvements and fixes.

Please note that for this release we had to make some changes to our deployment:

The following features are planned to be contained in either LibrePCB 1.2 or 2.0:

In addition, the plan is to start moving away from C++ towards the Rust programming language. Generally I like to work with proven, mature, stable, widely available tooling which was one reason to choose C++ more than 10 years ago when I started with LibrePCB. C++ is simply available on any platform and code written 10 years ago is still working fine today, so we can focus on new features rather than keeping the code compatible with new toolchain versions. However, more than a decade later, the situation is a bit different:

Given the advantages of Rust over C++, I think we should really give it a try and do a first attempt of integrating Rust into the LibrePCB code base. Of course a complete migration is totally out of scope — we have to start with small steps and gather experience with C++ interoperability.

However, our biggest problem at the moment is the user interface. As you might have noticed, LibrePCB consists of many individual windows and modal dialogs, packed full of controls. With every new feature, the UI gets more and more cluttered and thus more complicated (beside the inconvenience of having many windows opened at the same time). This does not follow our vision of an easy to use, intuitive UI.

Unfortunately, with our current UI toolkit (QtWidgets) it’s almost impossible to design more dynamic, flexible, responsive UIs. Also it consumes a lot of time, even simple things in the UI require to write tons of error-prone code. In addition, the platform-dependent look of Qt often leads to issues like unreadable text colors or layouting errors. All these things caused the development of new features to stuck because either something is almost impossible to implement with Qt, or I’m afraid of writing so much code for it.

As an example, one item in this custom list view requires ~580 lines of code:

To pave the way for new features (and in general to future-proof LibrePCB), I was therefore looking for alternatives to QtWidgets. Unfortunately there aren’t many options:

Of course there are many other UI frameworks out there, but nothing really suitable for LibrePCB (no C++ API, too bloated, not cross-platform, …​).

At first glance, QML seemed to be the only reasonable way to go, despite its own issues. However, after playing around with Slint too, I was impressed by its very neat declarative language and the powerful toolchain — compared to QML, it’s a real pleasure and very efficient to create UIs. The interaction with C++ is very basic, but seems to cover the most important use-cases. And even though many features are missing (e.g. menus, tooltips, drag&drop, …​), lots of things could be implemented manually.

During my experiments, I tried to quickly create a listview like the one from the library manager. Compared to the ~580 lines of code for QtWidgets, a custom list item in Slint takes only ~200 lines of code, and it’s even more responsive (e.g. hover effects):

Now I’m convinced we should give Slint a real chance, thus it’s part of the LibrePCB 2.0 roadmap.

I hope you are now as excited as I am! 😀