Embroidermodder 2 is a free embroidery editor that still asks you to compile it

A desktop editor for stitch files, not a converter script

Embroidermodder is a graphical user interface for editing machine embroidery files, and the second version is the one the project is currently working on. The project homepage is libembroidery.org, and the repository describes itself as free machine embroidery software supporting a variety of formats.

The feature list is short and specific: edit and create embroidery designs, estimate the amount of thread and machine time needed to stitch a design, convert embroidery files to a variety of formats, upscale or downscale designs, and run on Windows, Mac and Linux.

Two of those deserve a note. The thread and machine time estimate is the feature that separates a design tool from a file viewer, because it answers the question a maker actually cares about before a design goes to the machine. The upscale and downscale capability is more subtle than it sounds: embroidery is stitch geometry, so rescaling is not a bitmap operation and the quality of the result depends on how the stitch paths are rewritten rather than on pixel dimensions.

The formats themselves are visible in the repository topics, which list dst, jef, pes among others. The documentation does not enumerate the complete supported format list in the visible section, so treat the topics list as an indication rather than a specification.

For the audience, this is for hobbyists and small production shops who design on their own machine, and for anyone who needs to look inside a design file they were given rather than only stitch it.

The build script hides the dependency graph

The recommended first build is a single script that also fetches dependencies, which is the right call for a project with this many platform specific prerequisites.

# Choose your system out of:
bash bin/build.sh Ubuntu
bash bin/build.sh MacOS
bash bin/build.sh Windows

The system argument selects the right package handling for that platform. After the first run, the documentation says calling the script without an argument is enough:

bash bin/build.sh

That is the whole quick start for most people. The script is in bin/, alongside the coverage script, and the fact that the repository keeps bin/, cmake/, extern/, src/, test/ and data/ at the top level tells you the layout of the project itself: application source in src/, third party code vendored in extern/, sample designs in data/samples, and the build system split between CMake files and the helper scripts.

The trade-off of an automated script is that it makes the first build easy and the second build opaque. Once the script has run, you are in a normal CMake project and the documentation expects you to work from there.

The dependency list is short enough to state: Qt version 6.0 or newer and CMake are the minimum, with KDE for the thumbnailer and Valgrind for debugging as optional extras.

Qt 6 and CMake are the two requirements that matter

Before building you need the source, Qt 6.0 or newer, and CMake. The documentation is explicit that the project uses CMake exclusively, and it notes that as of Qt6 CMake is well supported, so an IDE such as QtCreator will likely be able to pick up the project from the CMakeLists.txt.

On Ubuntu, the packages are installed with apt:

sudo apt-get install git build-essential cmake qt6-base-dev libqt6widgets6 \
    libqt6printsupport6 libqt6core6 libgl-dev libgl1-mesa-dev libglx-dev

The list of Qt6 libraries is a hint about the application itself. qt6-base-dev and libqt6core6 are the foundation, libqt6widgets6 is the GUI toolkit the interface is built on, and libqt6printsupport6 points at printing support. The three Mesa development packages cover OpenGL, which matters for a graphics editor.

There is a Fedora instruction set as well, and the documentation labels it UNTESTED:

sudo yum install git gdb gcc-c++ qt-devel kdelibs-devel valgrind

The Fedora line installs qt-devel rather than the Qt6 specific packages, and the header calling it untested is a fair signal about how much confidence to place in that path.

On macOS the documented route is short:

brew install qt6 qwt

The README does not explain what qwt is needed for, only that it is installed alongside qt6 on macOS.

Calling CMake directly when you want to control the build

The documentation walks through the manual build for anyone who wants to see the steps rather than let a script hide them.

mkdir build
cd build
cmake ..
cmake --build .

The out-of-source build in a build/ directory is the standard layout, and the same build/ directory is where the install commands are run later.

For a faster build on a machine with make, the last line can be replaced:

make -j4

which the documentation explains builds on 4 cores at once. That is a useful detail for the target audience: embroidery design work is often done on whatever laptop is to hand, and a linear build of a Qt application of this size is slow enough to be noticed.

Contributors are pointed to CONTRIBUTING.md first, which gives an overview of the structure and design of the project. That document is the right place to look before changing anything, because the repository keeps a mixture of hand written code in src/ and vendored third party code in extern/, and the two usually need different treatment.

The changelog.md and TO_DO.md files at the root are the other two references to read before committing to this codebase, particularly given how long the 2.0 line has been in progress.

Automated testing is a Linux only coverage script

Testing in this project is not a unit test suite you would point at a new function. It is a coverage script designed to run without human interaction, and the documentation is clear about its platform constraint.

The program itself is tested through a flag: the documentation says testing uses the --test or -t flag, and that the coverage script has been set up to allow testing without human interaction. It is called like this:

# This has only been designed to run on a linux-based system.
bash bin/coverage.sh

The purpose is stated plainly: this automated testing is run by a workflow file named test.yml, so that basic usage does not crash the program. That is a smoke test, not a correctness suite.

This is a genuine limitation for a project that ships on three platforms. A crash on Windows or macOS after a change will not be caught by the Linux only script, and the CI workflow it feeds is correspondingly Linux shaped. For a patch you intend to contribute, the practical consequence is that you have to run the application yourself on the platforms you cannot see in CI.

The repository also carries .travis.yml at the root, which suggests an older continuous integration configuration alongside the GitHub Actions workflow.

Install and uninstall are documented, and marked untested

The installation instructions exist, which is more than many desktop projects of this kind offer, and they are short.

For Linux, open a terminal in the build/ subfolder and run:

sudo make install

And to remove it, from the same directory:

sudo make uninstall

Above those two blocks the documentation prints a warning: this is untested. The project is stating plainly that the packaging step has not been validated, and any issue you hit while installing belongs to the category of known unknowns rather than of a broken instruction.

For Windows and macOS the visible documentation does not give install steps at all, only the build script arguments for those platforms. That asymmetry is consistent with the rest of the file: Linux is the platform the author develops and tests on, the coverage script is Linux only, and the Fedora package recipe is the one flagged untested.

The sample designs in data/samples are the quickest way to exercise a fresh build. Loading one of them and looking at the stitch paths, the thread estimate and the machine time estimate is a better first check than merely confirming that the window opens.

For a Windows or macOS user, the practical route is therefore the automated script, and the absence of a packaged installer means the project is not yet a consumer install.

Alpha status, zlib terms and a nightly tag

The project tells you its own maturity in the header, and the release list confirms it.

The README names the current version as v2.0.0-alpha1 and says plainly that it is under construction, with a request to wait for the 2.0.0 release for any serious use. The published tags include nightly, labelled as the build of 03 July 2026, and alpha3 from 2023-05-08, which suggests the alpha series advanced at least one version beyond what the README header shows.

The repository is not archived, and the last push was on 2026-10-07, so the code base is being worked on even though the visible version marker has not moved.

The licence is zlib, which is permissive and short. It allows use, modification and redistribution including in commercial products, with the requirement that the notice is not removed. For a tool that people may want to embed in a larger workflow, that is a favourable choice, and it applies to the code rather than to any embroidery designs produced with it.

The practical reading of all this: the format handling and design editing are usable today, the release naming is unstable, and the packaging is unproven. Anyone adopting it should treat the build script and the TO_DO.md list as part of the product, because they are.

Editorial conclusion

Use Embroidermodder 2 if you need to open, edit or convert machine embroidery designs on Windows, Mac or Linux and you are willing to build from source with Qt 6 and CMake. Do not put it in a production pipeline yet, since the README labels the install and uninstall path as untested and the project asks serious users to wait for the 2.0.0 release. Before building, run bash bin/build.sh for your system, then bash bin/coverage.sh on Linux to confirm the binary starts without crashing, and check the TO_DO.md and changelog.md files for what is still missing.

Frequently asked questions

Official sources

1. Embroidermodder/Embroidermodder on GitHub
2. License: Zlib
3. Project website
4. README
5. Releases