Technical FAQ
This page covers different types of questions about Juna and it's architecture. Questions are gathered from various sources (reddit, discord, etc.)
1. Does Juna support image-based theming (wallpapers)?
No. Juna is a contract-first engine. We believe that generating colors from images often leads to low-contrast or unpredictable UI states. Juna expects a defined Base16 color palette (the contract), ensuring that your terminal and GTK apps always remain readable and mathematically consistent.
2. Will Juna break my existing programs.alacritty.settings?
Never. Because Juna uses Surgical Mapping, it only touches the colors attribute. Your custom fonts, keybindings, and window opacity settings are left untouched. Juna fills the gaps; it doesn't replace the foundation.
3. How do I override a single Juna color for one specific app?
Since Juna uses mkDefault, you don't need special Juna commands. Just define the color in your app's native NixOS/Home Manager option. Your definition will naturally take precedence over Juna's default pigments.
4. Why not just use Stylix?
If you want total, hands-off automation, Stylix is great. If you want to maintain Priority Sovereignty and avoid the performance overhead of recursive Nix functions, Juna is the better choice. Juna is for those who want their dots to stay theirs.
5. Can I use Juna without Home Manager?
Currently, Juna only provides modules for Home Manager as it provides the most granular control over user-space applications. However, it's planned to support system-wide theming in future.
6. Why not just pull from the tinted-theming/schemes repo automatically?
The "full suite" approach often leads to bloat and a lack of curation. Juna prioritizes predictability. While we respect the Base16 standard, Juna is designed to be a refined set of pigments rather than a dumping ground for hundreds of themes.
Furthermore, auto-pulling from external repos at evaluation time breaks the hermeticity of your Nix flake. Juna prefers a stable, versioned contract where themes are verified to work with our surgical mapping logic before they are shipped. That said, Juna’s internal metadata format is Base16-compatible, making it trivial to manually port any scheme from the tinted-theming ecosystem.
7. Is this description/docs AI-generated?
The technical architecture and the "Polite Guest" philosophy come directly from the developer’s intent to solve real friction in the Nix ecosystem. We use AI as a tool to polish the prose and ensure the technical depth is communicated clearly and concisely. Like a good linter for code, we use it to make the documentation as clean as the abstractions they describe. If it feels high-quality, it's because the underlying logic is sound.
8. "I don't see the difference—Stylix also lets you use Base16."
The difference is not in the data (Base16), but in the merge strategy.
Stylix is a management framework that wraps apps; Juna is a transparent overlay. Stylix often forces you into their specific override API or lib.mkForce because their internal modules compete for priority. Juna targets leaf nodes at priority 1000 (mkDefault).
The Litmus Test: In Juna, if you define a setting in your native home.nix application config, it "just works" without any extra boilerplate. In Stylix, you are often fighting the framework's own abstractions to get that level of control.
9. Is this just a theoretical project?
No. Juna was born directly from my personal production dotfiles.
I built it because I was tired of "Management Frameworks" that took too much control or slowed down my evaluation times.
Every design decision—from the surgical mkDefault mapping to the Base16 metadata contract—was forged to keep my own developer environment lean, fast, and predictable.
Juna isn't just a library; it's the extraction of a workflow that values simplicity above all else. This is the commit were prototype of Juna was born: commit