WhiskeyTuesday/omawrite-win

why?

2

stars

1

commits

Shell

primary language

Aug 17, 2026

updated

README

omawrite-win

My name is Ozymandias, King of Kings; Look on my Works, ye Mighty, and despair! Nothing beside remains.

Cross-compiles omawrite — the markdown editor that ships with Omarchy 4 "Quattro" — for Windows.

omawrite on Windows, dark

Nobody asked for this but here it is anyway. Claude wrote the rest of this README and I'm not going to bother removing all the em-dashes and stuff. Enjoy!

The disappointing part

It was easy.

The entire port is 42 lines, and 30 of those are #ifndef. Not one line of the editor, the syntax highlighter, or any QML needed to change. It builds in about fifteen seconds.

The only platform-specific code in the whole application was the xdg-desktop-portal block in src/systemtheme.cpp and that already had a Qt-native fallback sitting directly underneath it, because Qt reports the system colour scheme via QStyleHints::colorScheme() on every platform. So the "port" is mostly deleting a D-Bus call and letting the code that was already there do its job. QProcess, QSaveFile, QStandardPaths, and the print pipeline are all portable as written.

The mildly interesting part

You do not need to build Qt.

Every guide to cross-compiling Qt for Windows from Linux opens by telling you to spend several hours compiling Qt for Windows from Linux. You don't have to. Fedora's mingw SIG ships the entire stack prebuiltmingw64-gcc-c++, mingw64-qt6-qtbase, mingw64-qt6-qtdeclarative, the lot — so the toolchain is a dnf install in a container and nothing but your own code ever gets compiled.

The one gap is that Fedora doesn't package windeployqt, so deploy.py stands in for it: walk the PE import table with objdump -p, resolve each name against the sysroot, recurse until the closure is complete. About 60 lines. It works.

./build-windows.sh     # -> dist/   (~109M folder)
./make-sfx.sh          # -> two single-file .exe wrappers (~26M each)

Docker is the only requirement. The first script clones upstream, applies the patch, builds the image, cross-compiles, deploys the runtime, and strips it.

make-sfx.sh produces two flavours:

omawrite-portable.exeUnpacks to %TEMP%, runs, cleans up. Installs nothing.
omawrite-setup.exeUnpacks once to %LOCALAPPDATA%, makes shortcuts, launches.

Portable pays the unpack cost on every launch, which is fine for a look and tiresome as a daily editor. Neither passes file arguments through, so double-clicking a .md won't route to it; the installed copy is a normal .exe and will.

There's also run-wine.sh, which drives the build under Xvfb + wine and screenshots it, because I wanted to know whether it worked before I had anywhere to run it.

Does it actually work

I tested it on a real Windows 11 VM not just wine (but nothing else):

Launch, DLL + QML closureworks
Open / Save / Ctrl+Sworks
Print to PDFworks
Dark / light following the OSworks
Ctrl+N (new window)works

Print is worth a note, because it's the only place omawrite does real markdown rendering — it builds a fresh QTextDocument and calls setMarkdown(), so the PDF has actual heading hierarchy. The editor itself never does this. It's a syntax highlighter over raw text: block markers like # stay visible but dimmed, and inline markers like ** are hidden by painting them in the background colour at 1pt with negative letter-spacing so they collapse to zero width. Headings are bolded, never resized. It's a nice effect and it is not WYSIWYG.

Size

165M → 26M.

  • strip --strip-unneeded on everything. Fedora ships those DLLs with full debug symbols; libstdc++-6.dll alone was 25M.
  • Dropped the four Controls styles omawrite never imports (FluentWinUI3, Imagine, Universal, Fusion).
  • LZMA2 solid-block at -mx=9.

The floor is Qt. icudata74.dll is 30M on its own and only a static rebuild with -no-icu removes it, which costs hours of compiling to save a folder you were going to ignore anyway. I declined. You should too.

Caveats

  • Built against Qt 6.8.3 (what Fedora packages), not upstream's 6.11. Nothing in the source needs the newer API, but that's an assumption, not a proof.
  • Unsigned, so SmartScreen will object. More infoRun anyway.
  • Omarchy theme sync is meaningless off Omarchy. You get Windows light/dark and nothing else.
  • Windows blocks the Personalization UI without activation, which makes testing the theme switch annoying. set-light.cmd / set-dark.cmd write the registry value directly and sidestep it entirely.

Licensing

omawrite is MIT (© David Heinemeier Hansson). Qt here is LGPLv3, linked dynamically, which is the arrangement LGPL is happy with. The bundled iA Writer Mono is OFL 1.1. If you ever switch this to a static Qt build, that changes and you'll owe relinkable objects to anyone you hand a binary to.

Upstreaming

The patch is guarded so the Linux build is bit-for-bit unaffected — verified, it still links libQt6DBus. If anyone at Omacom wants it, it's right there in windows-port.patch and applies clean to master.


Round the decay of that colossal wreck, boundless and bare, the lone and level sands stretch far away.

Contributors

WhiskeyTuesday/omawrite-win

why?

2

stars

1

commits

Shell

primary language

Aug 17, 2026

updated

README

omawrite-win

My name is Ozymandias, King of Kings; Look on my Works, ye Mighty, and despair! Nothing beside remains.

Cross-compiles omawrite — the markdown editor that ships with Omarchy 4 "Quattro" — for Windows.

omawrite on Windows, dark

Nobody asked for this but here it is anyway. Claude wrote the rest of this README and I'm not going to bother removing all the em-dashes and stuff. Enjoy!

The disappointing part

It was easy.

The entire port is 42 lines, and 30 of those are #ifndef. Not one line of the editor, the syntax highlighter, or any QML needed to change. It builds in about fifteen seconds.

The only platform-specific code in the whole application was the xdg-desktop-portal block in src/systemtheme.cpp and that already had a Qt-native fallback sitting directly underneath it, because Qt reports the system colour scheme via QStyleHints::colorScheme() on every platform. So the "port" is mostly deleting a D-Bus call and letting the code that was already there do its job. QProcess, QSaveFile, QStandardPaths, and the print pipeline are all portable as written.

The mildly interesting part

You do not need to build Qt.

Every guide to cross-compiling Qt for Windows from Linux opens by telling you to spend several hours compiling Qt for Windows from Linux. You don't have to. Fedora's mingw SIG ships the entire stack prebuiltmingw64-gcc-c++, mingw64-qt6-qtbase, mingw64-qt6-qtdeclarative, the lot — so the toolchain is a dnf install in a container and nothing but your own code ever gets compiled.

The one gap is that Fedora doesn't package windeployqt, so deploy.py stands in for it: walk the PE import table with objdump -p, resolve each name against the sysroot, recurse until the closure is complete. About 60 lines. It works.

./build-windows.sh     # -> dist/   (~109M folder)
./make-sfx.sh          # -> two single-file .exe wrappers (~26M each)

Docker is the only requirement. The first script clones upstream, applies the patch, builds the image, cross-compiles, deploys the runtime, and strips it.

make-sfx.sh produces two flavours:

omawrite-portable.exeUnpacks to %TEMP%, runs, cleans up. Installs nothing.
omawrite-setup.exeUnpacks once to %LOCALAPPDATA%, makes shortcuts, launches.

Portable pays the unpack cost on every launch, which is fine for a look and tiresome as a daily editor. Neither passes file arguments through, so double-clicking a .md won't route to it; the installed copy is a normal .exe and will.

There's also run-wine.sh, which drives the build under Xvfb + wine and screenshots it, because I wanted to know whether it worked before I had anywhere to run it.

Does it actually work

I tested it on a real Windows 11 VM not just wine (but nothing else):

Launch, DLL + QML closureworks
Open / Save / Ctrl+Sworks
Print to PDFworks
Dark / light following the OSworks
Ctrl+N (new window)works

Print is worth a note, because it's the only place omawrite does real markdown rendering — it builds a fresh QTextDocument and calls setMarkdown(), so the PDF has actual heading hierarchy. The editor itself never does this. It's a syntax highlighter over raw text: block markers like # stay visible but dimmed, and inline markers like ** are hidden by painting them in the background colour at 1pt with negative letter-spacing so they collapse to zero width. Headings are bolded, never resized. It's a nice effect and it is not WYSIWYG.

Size

165M → 26M.

  • strip --strip-unneeded on everything. Fedora ships those DLLs with full debug symbols; libstdc++-6.dll alone was 25M.
  • Dropped the four Controls styles omawrite never imports (FluentWinUI3, Imagine, Universal, Fusion).
  • LZMA2 solid-block at -mx=9.

The floor is Qt. icudata74.dll is 30M on its own and only a static rebuild with -no-icu removes it, which costs hours of compiling to save a folder you were going to ignore anyway. I declined. You should too.

Caveats

  • Built against Qt 6.8.3 (what Fedora packages), not upstream's 6.11. Nothing in the source needs the newer API, but that's an assumption, not a proof.
  • Unsigned, so SmartScreen will object. More infoRun anyway.
  • Omarchy theme sync is meaningless off Omarchy. You get Windows light/dark and nothing else.
  • Windows blocks the Personalization UI without activation, which makes testing the theme switch annoying. set-light.cmd / set-dark.cmd write the registry value directly and sidestep it entirely.

Licensing

omawrite is MIT (© David Heinemeier Hansson). Qt here is LGPLv3, linked dynamically, which is the arrangement LGPL is happy with. The bundled iA Writer Mono is OFL 1.1. If you ever switch this to a static Qt build, that changes and you'll owe relinkable objects to anyone you hand a binary to.

Upstreaming

The patch is guarded so the Linux build is bit-for-bit unaffected — verified, it still links libQt6DBus. If anyone at Omacom wants it, it's right there in windows-port.patch and applies clean to master.


Round the decay of that colossal wreck, boundless and bare, the lone and level sands stretch far away.

Contributors

Languages

Shell

54.6%

Python

28.4%

Batchfile

17.0%