Move the macOS agent into komorebi-e2e-agent as macos.rs, answering the protocol of protocol.rs
with its own verbs (os_windows, displays, activate, minimize, close, move; a window is found by
its title), and remove the separate komorebi-macos-e2e crate that had copied the protocol. There
is one binary name and one port on every platform, so the host has one client and one description
of the protocol.
AppKit is for the main thread, so the macOS agent serves one connection at a time on it, where
the Windows one serves each on a thread. A spawned program on macOS gets a standard input that
stays open, as the test window leaves when its input closes. The crate is built for macOS and
Windows now and stubbed on Linux, as komorebi-testwin is.
The Windows guest has komorebi-e2e-agent; this is its macOS counterpart, speaking the same
protocol (one JSON line per request, raw bytes after it for put_file and get_file) so that the
host client is the same. Beyond exec, spawn and file transfer it answers with the windows the
accessibility API gives (title, frame, focus, minimized) and the displays with their work areas,
and it can activate, minimize, close and move a window.
It has to be started by a program that holds the Accessibility and Screen Recording grants, so
that the daemon it spawns is attributed to that program.
The workspace members, the path dependencies, the include_str! and test
fixture paths, the recorder's indexed source keys, and the Nix source
filter and path literals follow the new layout. Cargo.lock is unchanged.
It is a development tool: a bare cargo build leaves it out, publish is off, and no release
ships it. Its manifest uses the workspace dependencies it shares and keeps its own version.
The unified line starts the 0.2.0 development cycle and is not released yet, so the one
workspace version (every package takes it through version.workspace = true) is the
pre-release 0.2.0-dev instead of 0.2.0. The release revision sets it to 0.2.0.
Cargo.lock only changes the version of the workspace's own packages. The schema
descriptions and the macOS schema links keep naming v0.2.0: they document the schema of
the release this line leads to. The update widget of the bar compares version strings, so
a dev build never offers the 0.1.x releases as an update.
Verified: cargo metadata --offline succeeds; cargo test -p komorebi --test linux_version
passes; komorebic --version prints 0.2.0-dev. The other gates were not re-run for this
one-line change.
The workspace members and the path dependencies of komorebi-client, komorebic,
komorebi-daemon, komorebi-linux, komorebi-macos and komorebi-hotkeys name the directories
of the previous revision (komorebi-windows, komorebi-linux, komorebi-macos,
komorebi-hotkeys at the top level); the dependencies of the moved crates on the shared
crates are one directory shorter. cargo metadata --offline succeeds with an unchanged
Cargo.lock. Source files that include files by relative path are fixed later in this
stack.
komorebic-linux, komorebi-client-linux, komorebic-macos, komorebi-client-macos and
komorebi-bar-macos were #[path] includes of the unified komorebic, komorebi-client and
komorebi-bar modules, kept only so the old package names kept building. The unified
packages are the only ones now, so the five directories and their workspace members are
gone (Cargo.lock loses their dependency entries).
Things that named the old packages follow: the clarify entries of the two per-tree
deny.toml files, tools/fast-check, tools/mac-check.sh and tools/kde-closure-check (it now
walks komorebic and komorebi-client), and the doc comment of komorebic/src/main.rs.
komorebi-for-kde/nix/root-crates.json gains komorebic, komorebi-client and
crates/komorebi-version, because those are root crates the KDE build depends on now.
komorebi-for-mac/komorebi/src/pan.rs read its transcripts from the deleted
komorebic/fixtures; they are byte-identical to the root komorebic/fixtures, so the three
paths point there.
Not touched here (done in the flake and justfile revisions of this stack): the nix
flakes and justfiles of the trees, which still name the removed packages, and docs/dev.
Verified: Windows cargo clippy --locked --all-targets -D warnings (default members) passes;
KDE cargo test -p komorebi -p komorebic -p komorebi-client -p komorebi-linux passes; macOS
cargo check --target aarch64-apple-darwin (fake CC) of komorebi, komorebi-macos, komorebic,
komorebi-client, komorebi-bar passes; tools/kde-closure-check passes. The nix flakes were
not run.
version-linux (komorebi-for-kde/version, shadow-rs 2) and version-macos
(komorebi-for-mac/version, shadow-rs 1) had the same build.rs and the same lib.rs. They
are now one package, crates/komorebi-version (lib name version, shadow-rs from the
workspace), and the KDE and macOS daemons, their command lines and the unified komorebic
depend on it under the key version. The extern crate lines of komorebic/src/main.rs that
renamed the two crates are gone, and the two deny.toml clarify entries name the new
package.
komorebi-daemon/tests/linux_version.rs read the version out of the old crate's Cargo.toml
text, which no longer has a number (it is inherited); it now expects the package version,
which is the workspace version.
Verified: cargo test -p komorebi -p komorebic -p komorebi-client -p komorebi-linux (KDE
side, native Linux) all pass, including the version test; cargo check --target
aarch64-apple-darwin of the macOS packages with the fake C compiler passes. Windows and
nix were not run for this revision (Windows does not use the crate; nix runs at the end of
the stack).
Every package of the workspace now takes its version from [workspace.package]
(version.workspace = true) instead of its own number. The numbers before were
0.1.42 (Windows libraries and packages), 0.1.0 (KDE, the macOS version crate,
komorebi-shortcuts and the e2e guest crates) and 0.1.1 (macOS libraries); the
unified release is 0.2.0 for all of them.
Cargo.lock only changes the version of the workspace's own packages.
Not changed here: the version text in schema doc comments and the generated
schemas (next revision), and the shim packages, which are deleted later and
only pick up the number meanwhile.
Verified: cargo metadata --offline --locked succeeds.
Review finding 3. crates/komorebi-core was a member but not in default-members,
so a bare cargo test or cargo clippy at the root did not build it and its tests
(27, 30 with the schemars feature) never ran in the Windows set. komorebi-daemon
was already in the list. cargo test -p komorebi-core passes with and without
--features schemars: komorebi-layouts keeps Layout::Custom without the Win32
dependency, so no cfg needed fixing. (The komorebi-config crate prints an
unused-import warning of its own when built alone with default-features off,
pre-existing and not an error in the workspace build, where features unify.)
Verified: cargo test -p komorebi-core: 27 passed; with --features schemars: 30
passed; tools/fast-check (native, Windows clippy -D warnings, KDE, macOS) PASS.
Step 8 (Option A of docs/dev/unified-binaries.md). The main.rs of komorebi-windows, komorebi-linux and
komorebi-macos becomes daemon.rs of the library (pub fn run; komorebi:: paths are crate:: paths now, the
inner attributes and the unit tests move with it), and their [[bin]] is gone, so each is a library only.
The new package komorebi (komorebi-daemon/, version 0.1.42) is the one binary: its main calls
komorebi_windows::daemon::run, komorebi_linux::daemon::run or komorebi_macos::daemon::run by cfg_select! on
the target OS, through target-gated dependencies (one key per library, cargo allows one path per key),
and forwards the features deadlock_detection and schemars. The binary name komorebi now comes from exactly
one package. The four KDE integration tests that run the binary (no_kwin, socket, hot_reload, version)
move to komorebi-daemon/tests/linux_*.rs; the version test compares with the KDE version crate, since
the package version is now shared. Old names: komorebi-windows, komorebi-linux and komorebi-macos still
build, as libraries (no binary any more: use -p komorebi). The flakes build -p komorebi with the KDE and
macOS packages, the source filters take komorebi-daemon (manifest, main.rs, linux tests), the Windows
filter leaves its linux tests out, deny.toml clarify entries gain komorebi, the release workflow's cargo wix
and the justfile version lookup name komorebi, tools/fast-check checks -p komorebi on KDE and macOS.
Behaviour: the same code runs, the same binary name; the Windows executable is rebuilt from the library
(BEHAVIOUR for the e2e gate: the Windows e2e must run).
Gates run: Windows clippy --all-targets -D warnings PASS; KDE check; macOS fake-CC check of -p komorebi
-p komorebi-macos PASS (type check only); KDE cargo test -p komorebi -p komorebi-linux -p komorebic -p
komorebi-client -p komorebi-hotkeys -p komorebi-core: 903 passed, 0 failed (the four moved tests and the
unit test of daemon.rs included); CLI docs oracle identical x3; bar schema harness identical both bars;
kde-closure-check ok; nix evaluation of the root and both nested flakes PASS; by evaluation an edit of
komorebi/src/daemon.rs changes the Windows derivations only, of the KDE daemon.rs kfde only, of the macOS
one neither (the shared komorebi-daemon/src/main.rs changes all, as expected). Not run: nix builds, VM,
e2e, any Mac run.
Merge of wip-u-core (kfde: komorebi-core with Container, Workspace<P>, Monitor<P>) and wip-u-pkg-mig3.
Conflicts and how they were resolved:
- komorebi-for-kde/Cargo.toml, komorebi-for-kde/Cargo.lock: deleted, as in the migration (one root
workspace); kfde's only edit there, the komorebi-core workspace dependency, is applied as a path
dependency in the crate manifest.
- komorebi-for-kde/komorebi/Cargo.toml: the migration's manifest (inlined dependencies, package name
komorebi-linux, [lib]/[[bin]]) plus kfde's komorebi-core dependency and the komorebi-core/schemars
feature.
- Cargo.lock: the migration's lock re-resolved with cargo metadata --offline: the only change is the
new komorebi-core 0.1.42 entry; no version of any other package moved (compared by name/version with
both parents; kfde's Windows lock differs only by the komorebi -> komorebi-windows rename).
- komorebi-bar/src/widgets/komorebi.rs: deleted (the Windows bar moved to komorebi-bar/src/windows/);
kfde's one-line edit (title: value.title() instead of value.title().ok()) applied to
komorebi-bar/src/windows/widgets/komorebi.rs.
- komorebi-for-kde/nix/root-crates.json: crates/komorebi-core added (tools/kde-closure-check now ok with
11 root crates).
Gates run: tools/fast-check --since wip-u-pkg-mig3: native tests, Windows clippy -D warnings, KDE check+lib+schemas, macOS fake-CC check, nix evaluation (root and both nested flakes) PASS; KDE cargo test -p komorebi-linux -p komorebic -p komorebi-client -p komorebi-hotkeys -p komorebi-core: 902 passed, 0 failed; CLI docs oracle identical x3; bar schema harness byte-identical for both bars (its Window::title stub now returns Option); bar-core tests 3+6; kde-closure-check ok; by evaluation an edit of the Windows bar or daemon leaves the kfde derivations unchanged, a KDE edit leaves Windows unchanged, and an edit of crates/komorebi-core changes Windows and kfde but not macOS. Not run: nix builds, VM, e2e (the Windows daemon changed: kfde's e2e gate applies), any Mac run.
komorebi-for-kde/*, komorebi-for-mac/* crates become members of the root Cargo workspace: one
Cargo.lock (901 packages; the 859 Windows entries are unchanged, checked by name and version), the
two nested [workspace] manifests and lock files are deleted, their inherited dependencies are written
out per crate (script S/pkg-merge.py), KDE's .cargo/config.toml (COMMIT_HASH default) moves to the
root .cargo/config.toml (non-forcing, nix still wins). default-members is the Windows set, so a bare
cargo command (and crane, which passes no --workspace) builds only Windows crates; the KDE and macOS
crates are selected with -p. Crates only KDE used were re-resolved newer by cargo; pinned back to the
KDE lock (zbus, zbus_macros 6.1.0, zbus_utils 6.0.0, zruntime 0.2.1, sysinfo 0.40.0). Two small
differences remain: unicode-width 0.2.2 (KDE locked 0.2.3) and libz-sys 1.1.31 (macOS locked 1.1.30).
The root flake and the two nested flakes still read the old workspaces and do not evaluate at this
revision: they are fixed in the next one, which must land with this one (nix cannot be half-merged).
Not behaviour.
Gates run: Windows clippy --all-targets -D warnings (default-members) PASS; KDE check + 294 lib + 5
schemas PASS from the root workspace; macOS fake-CC check of the four macOS packages --locked PASS.
Not run: nix (broken until the next revision), VM, e2e. tools/fast-check now detects the merged
layout.
New crate crates/komorebi-core, a member of the root workspace (KDE and
macOS take it by path when they adopt it). It holds Container<W>, moved
from komorebi-for-kde/komorebi/src/container.rs (KDE is the base) and
made generic: W is any type that implements ContainerWindow, a small
trait for what the container asks of a platform window (its id, the
executable name, hide and restore, and the hide and restore that
load_focused_window uses, which on Windows leave the border alone).
Container keeps no Backend calls; hiding and restoring is the window's
own business.
The serialised form is unchanged: id, locked (which may be missing when
read, as on Windows), windows with elements and focused. The schemars
schema of Container<W> is named Container whatever W is
(schemars(rename)), so schema.json keeps its definition name; a test
checks it. The tests of container.rs that need no daemon moved with it,
over a stub window, plus tests for the JSON, the hide/restore calls and
the missing locked field.
No daemon uses it yet: the next revisions converge KDE and Windows.
Verified: cargo test -p komorebi-core --features schemars (native):
13 passed, 0 failed. Not run: Windows, KDE, macOS builds (nothing
depends on the crate yet).
New crate crates/komorebi-settings (workspace member, Cargo.lock +1
package, no new third-party dependency). Settings<P> is a shared part and a
platform part P; Handle<P> holds the current value as an Arc that readers
snapshot once per unit of work and writers replace through update (writers
serialised, one publish, nothing published if the edit panics). Handle::scoped
sets one field and restores the previous value on drop only if the field
still holds the value it set, replacing the save-and-restore store pairs in
the daemons (Windows WINDOW_HANDLING_BEHAVIOUR, KDE ANIMATION_ENABLED_GLOBAL).
Shared starts with the border and the per-platform defaults; the rest follows
in the next revision. See docs/dev/settings.md.
No daemon uses the crate yet.
Verified: native cargo test -p komorebi-settings: 9 passed (snapshot
isolation, concurrent updates lose nothing, no torn reads under a writer,
scoped restore and 'change made meanwhile wins'); clippy clean for the crate.
komorebi-config warns about an unused import when built without its schemars
feature (not touched here). KDE, macOS and Windows trees not touched.
New crate crates/komorebi-backend (edition 2024, root workspace member, depends only on komorebi-layouts for Rect).
- WindowId and MonitorId: opaque u64 newtypes. KDE and macOS ids convert with from_u32/to_u32; a Windows HWND/HMONITOR goes through from_hwnd/to_hwnd, which keep the bits of the isize unchanged (isize as usize as u64), so no handle is lost whether or not it fits in 32 bits (the e2e samples stay below 2^32, which is an observation, not a guarantee).
- WindowInfo and MonitorInfo: plain data; only id, pid, rect, minimized and alive are required, the rest (title, class, exe, path, fullscreen, maximized, normal; name and serial id of a monitor) are Option (seam.md consequence 6).
- Error: WindowGone(id) (finding 9: macOS uses a failed write as its signal that a window died), Unsupported(Capability) and Platform(cause).
- Backend: only the operations of seam.md section 2.1 that at least two platforms have (5 queries, 9 commands), a Capability query for workspaces, maximize, opacity and focus-follows-mouse (their methods default to Unsupported), begin_batch/end_batch with a no-op default plus the Batch guard (finding 8), the documented set_rect contract (a request; reads after a write return what the platform defines, consequence 2 as corrected) and the thread contract (any non-main thread, no waiting for the platform's main thread: consequences 3 and 4, written as TARGET rules). Every doc comment says which platforms implement the method.
Verified: native cargo test -p komorebi-backend (2 unit tests, 3 doctests, 0 failed) and cargo clippy -p komorebi-backend --all-targets -- -D warnings clean. The Windows/KDE/macOS gates are not affected yet (new crate, nothing depends on it).
Skeleton of the shared bar crate (D25/D26): an empty library and the oracle that every later move of bar code is held to. tests/schema_oracle.rs pins the checked-in schema.bar.json of the Windows bar (9,090 lines, FNV-1a 0x557301341968bff9) and of the macOS bar (3,774 lines, 0xc99e02949424e5d7), so any change to either file, intended or not, fails the test until the pin is updated in a reviewed revision. Once config.rs moves into the crate the test generates the schema and compares it with the file instead.
The pins are of the files as they are after the previous revision (the regenerated Windows file) and are the values the out-of-tree harness (S/bar2/regen.sh over the real sources) reproduces: macOS byte-identical, Windows byte-identical to the regenerated file.
Verified: native cargo test -p komorebi-bar-core: 2 passed, 0 failed; Windows cargo clippy --workspace --locked --all-targets -D warnings clean; macOS fake-CC cargo check --locked --workspace --all-targets finished, 0 errors.
Merge revision: wip-main (history merges, fixes, step 0, steps 1, 2, 4 and 5, flake work, seam document) and wip-step3 (komorebi-config: matching types, behaviour enums, AspectRatio/PerAnimationPrefixConfig, asc and the application configuration data, placement types, the one StaticConfig with per-platform schema views, the daemons wired to it). Conflicts between step 3's edits and step 4's restructuring of komorebic (the schema-printing arms moved into the WindowsCommands/MacosCommands/KdeCommands matches) and in the Cargo.lock files are resolved here once, instead of through 35 separate rebases.
A new workspace member crates/komorebic-core, the home of the clap definitions the three komorebic packages share (step 4, D20-D22). This revision only has the docgen renderer: DocFormat keeps what differs between the trees (KDE pins the width at 100, fences with ```text, ends with a newline and writes a page for a subcommand of a subcommand; Windows and macOS set no width) and the list of commands that get no page, which is the same in all three. Nothing uses it yet.
Verified: native cargo test -p komorebic-core: 3 passed, 0 failed.
A new platform-neutral crate, crates/komorebi-transport (edition 2024, member of the root workspace), that will hold the command transport shared by the three daemons (D23/D24). It starts with allowed_while_paused(&SocketMessage) -> bool: the four messages (TogglePause, State, GlobalState, Stop) a daemon still handles while it is paused. It is a free function and not a method of the protocol enum because it is daemon policy, not wire format. Nothing calls it yet. A unit test lists the four and checks that other messages are refused.
Verified: cargo test -p komorebi-transport: 1 passed, 0 failed (native, tier 1). The tree gates run in the revisions that adopt it.
Add crates/komorebi-config (edition 2024, root workspace member) with the feature-gated schema module that prints a schema the way komorebic does (pretty JSON plus a newline). No type has moved yet: the crate depends on komorebi-layouts, komorebi-themes and komorebi-protocol, which every type that follows needs.
Verified: native cargo test -p komorebi-config compiles (tier 1). Cargo.lock gains only the new package. Windows, KDE and macOS trees do not depend on the crate yet.
Merge revision: wip-main (history merges, fixes, step 0 path dependencies, step 1 komorebi-collections, KDE A3 fixes, flake phase 2) and wip-step2 (the komorebi-protocol crate, goldens and the unified SocketMessage used by all three trees). Conflicts in the root Cargo.toml members line, the trees' Cargo.toml dependency tables and the Cargo.lock files are resolved in this revision by keeping both sides' additions.
Moves the identical ring.rs and lockable_sequence.rs out of komorebi/src into the crate (rename). Necessary edits: lib.rs with pub use Lockable and a hidden pastey re-export; #[macro_export] on impl_ring_elements! using $crate::pastey::paste!; the doc test now says komorebi_collections::ring::Ring. The Windows tree gets the path dependency, re-exports (pub use komorebi_collections::{ring, lockable_sequence, Lockable}, #[macro_use] extern crate), forwards its schemars feature, and drops pastey again. Windows is bundled here because it is the tree the files move out of.
Verified: fast-check native, Windows clippy --all-targets -D warnings, KDE and macOS checks: PASS.
New crates/komorebi-collections (edition 2024; deps pastey, serde, optional schemars feature, dev serde_json_lenient) added to the root workspace members, with an empty lib.rs. Cargo.lock for this revision alone is not refreshed (it is in the next revision).
Verified: cargo test -p komorebi-collections --offline built (0 tests yet).
Windows ring.rs is replaced by the KDE copy (doc comments, tests, pastey::paste!, std::collections::VecDeque path). pastey 0.2 added to the root workspace deps and komorebi/Cargo.toml (paste stays: windows_api.rs and komorebic use it). The VecDeque imports in container.rs and workspace.rs only served the old macro text and are removed.
Verified: fast-check Windows clippy --all-targets -D warnings: PASS (tests compiled, not run: Windows-only).
Add crates/komorebi-protocol (edition 2024, member of the root workspace) with empty modules message, platforms, types, animation and pathext. The client transport stays out of the crate (D16). Cargo.lock gains the new package only.
Verified: native cargo build -p komorebi-protocol succeeds. Windows, KDE and macOS gates not run for this revision (no tree depends on the crate yet).
komorebi-e2e-agent runs in the interactive session of the guest and answers
the host over a forwarded TCP port: exec, spawn, os_windows (DWM frame, cloak
and focus), displays, window verbs and file transfer. komorebi-testwin is a
plain Win32 window with a stable exe name and class and a control channel on
stdin. Both cross-build from Linux and pass clippy; neither has run in a
guest yet.
A ghost was a live thumbnail of its window, so it showed whatever the window
painted: the stretched old frame, then the blank frame a window paints while
it lays itself out again (Explorer shows its toolbar and nothing else for a
few hundred milliseconds), then the new layout, replacing the picture all at
once after the animation was over, and it stayed on screen about 300ms past
the end of the move while it waited for that. Every ghost also had a host
window of its own that was moved with SetWindowPos on every frame through a
channel to a thread that polls for commands every 8ms.
Take a picture of the window with PrintWindow before anything is done to it
(cropped to the visible frame, with the corners rounded) and show it through
a cloaked window of our own that DWM can take a thumbnail of and scale on the
GPU. All ghosts are composed onto one layered, click-through host window that
covers the virtual screen, and is only above other windows while a ghost is
alive so that it does not get in the way of the taskbar's auto-hide:
animating a ghost is one DwmUpdateThumbnailProperties call on the animating
thread, which has no thread affinity. The number of registered thumbnails is
counted and traced so that a leak of compositor handles can be seen.
The real window is cloaked and resized at the start of the animation, on a
thread of its own, and asked to paint itself at its new size straight away
(taking a picture of it makes it render synchronously) while the ghost is on
screen, so that it has the whole animation to lay itself out unseen. At 55%
of the way through, the window is shown again under the ghost (with the one
pixel size change that windows which render through a swap chain need for
their compositor to rebuild its render target) and the ghost fades out over it
while still moving, so the picture dissolves into the window instead of being
replaced after. A window that is slow to take its new size is not waited for:
it is shown once it is ready, or, if the animation ends first, waited for with
the ghost over it and then faded out over a few frames. Windows that are
minimized or gone are not ghosted.
This commit moves layout-related code into a new workspace crate
komorebi-layouts, with the intention of re-using it all in komorebi for
Mac instead of maintaining two separate implementations.
I was getting really tired of having to switch between display inputs to
different platform-specific machines to be able to make and test changes
on komorebi for Windows and komorebi for Mac.
With this commit, the `flake.nix` provides a Nix devShell and crane
build for users to make and validate changes with `cargo check`, `cargo
clippy` and `cargo build` with the Windows MSVC toolchain on Linux and
macOS.
This commit makes it possible to send commands from the bar by using the
mouse/touchpad/touchscreen.
Komorebi or custom commands can be sent by clicking on the mouse's
primary, secondary, middle, back or forward buttons.
As the primary single click is already used by widgets, only primary
double clicks can send commands. This limitation is due to Egui also
triggering 2 single clicks before a double click is triggered. Egui does
not have an implementation for stopping event propagation out of the box
and would be too much work to include.
Similarly, commands can be sent on every "tick" of mouse scrolling,
touchpad or touchscreen swiping in any of the 4 directions. This "tick"
can be adjusted to fit user's preference.
This is due to the fact, that Egui does not have an event for when a
mouse "tick" occurs. It instead gives a number of points that the user
scrolled/swiped on each frame.
PR: #1403
This commit adds a simple egui helper application which shows a list of
shortcuts defined in a user's whkdrc file. Parsing AHK files is not
supported.
In addition to listing out shortcuts defined in the whkdrc file, the top
line allows users to add filter a filter to narrow down the list of
commands and key bindings to the ones they are interested in.
A new komorebic command "toggle-shortcuts" has been introduced which
will first attempt to kill "komorebi-shortcuts.exe", and then exit if
the kill signal was successful (ie. a process was closed), or proceed to
open "komorebi-shortcuts.exe" if the kill signal was not successful (ie.
no process was closed, so we should open one).
"komorebi-shortcuts.exe" has been added as a floating application in
lib.rs to allow for users to use the "komorebic move" command to
manipulate its position via their existing keyboard bindings.
This commit adds some dependency injection to the monitor reconciliator
module to make it easier to test the behaviour when different kinds of
data are returned from win32_display_data.
This commit adds the timezone on the time and date widgets as a new
setting.
In case the timezone is invalid, the output is replaced with an error
message.
Use a custom format to display additional information.
resolve#1312
This commit makes all schemars::JsonSchema derives optional. After
analyzing the output of cargo build timings and llvm-lines, it was clear
that the majority of the 2m+ incremental dev build times was taken up by
codegen, and the majority of it by schemars.
Developers can now run cargo commands with --no-default-features to
disable schemars::JsonSchema codegen, and all justfile commands have
been updated to take this flag by default, with the exception of the
jsonschema target, which will compile with all derives required to
export the various jsonschema files.
Incremental dev build times for komorebi.exe on my machine are now at
around ~18s, while clean dev build times for the entire workspace are at
around ~1m.
LGUG2Z
dependabot[bot]
Lucas de Linhares
Csaba