Skip to content

Forge apps degrade badly on a plain text console (8 colours, no Nerd Font glyphs) #1

Description

@jetomev

Summary

The Forge apps are built for a modern terminal emulator with truecolour and a Nerd Font. On a plain Linux virtual console (Ctrl+Alt+F3, TERM=linux) the interface degrades badly — colours collapse, glyphs go missing, and visual structure is lost.

Found during grubForge v1.1.0 testing, when a text console turned out to be a genuinely supported way to run one of these apps.

Why this is not a niche case

A text console is exactly where you end up when the desktop is broken — which is exactly when you want a bootloader manager or a package manager. grubForge v1.1.0 explicitly documents sudo grubforge on a text console as the supported path when there is no authentication agent. So the console is not an edge case we tolerate; for at least one app it is a documented recovery path.

The same applies to installforge and welcomeforge when those arrive: an installer runs before any desktop exists.

The numbers

Linux console capability:

$ infocmp -1 linux | grep -E 'colors#|pairs#'
    colors#8,
    pairs#64,

Eight colours. What the apps currently ask for:

Repo distinct hex colours emoji used in the UI
forgekit 16
grubForge 27 ⚡ 🏠 🔧 🎨 🗂 🖥
alacrittyForge 15 ⚡ 🔧 🎨 ⌨ ⏳
bitlaForge 12 ⚡ ⚙ 📜

27 truecolour values collapsing into 8 is where "everything looks the same" comes from. Catppuccin Mocha is a low-contrast palette by design — several of its greys and blues land on the same console colour, so panel borders, dim text and body text become indistinguishable.

The emoji are a separate failure: the default console font has no glyphs for them, so they render as blanks or replacement boxes, and because they are width-2 characters that can also throw column alignment out.

What is actually wrong

  1. No downgrade path for colour. Styling is written as literal hex throughout. There is no notion of "this is the panel border colour" that could resolve differently on an 8-colour terminal.
  2. Glyphs assumed present. Nav icons, status icons (✓ ● ⚠ ✗) and box-drawing are hard-coded with no ASCII fallback.
  3. Nothing detects the situation. The apps do not look at TERM/COLORTERM and have no reduced mode to switch into.
  4. It is untested. No test matrix in any Forge repo has ever included a console run. This was found by accident.

Possible directions

Not decided — this is the discussion.

  • Semantic colour tokens in forgekit. Screens ask for border, muted, danger, accent rather than #313244. forgekit resolves them: full Catppuccin on truecolour, a hand-picked 8-colour mapping on TERM=linux. This is the piece only forgekit can do, and it is why this issue lives here.
  • A glyph table with ASCII fallbacks[ok], [!], nav emoji→letters or nothing — chosen once at startup.
  • Detect and adapt rather than requiring a flag, with an override (FORGE_ASCII=1 / --ascii) for people on terminals that lie about their capabilities.
  • Decide the target explicitly. "Readable and usable on TERM=linux" is a weaker promise than "looks identical everywhere", and is probably the right one. Worth writing down so it can be tested.

Sequencing

grubForge is scheduled to move onto forgekit as v2.0.0, and alacrittyForge, bitlaForge and nogForge are already on it or heading there. Doing this in forgekit first means every app inherits it rather than each one solving it differently — which is the argument for fixing it here before the grubForge migration, not after.

Reproducing

On any machine with one of these apps installed:

  1. Ctrl+Alt+F3 and log in
  2. Run the app
  3. Compare against the same app in a normal terminal

Tracked in the apps

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions