Add DPI as a first-class user-configurable property

[daavidrgz]

Problem

gtheme has no consistent strategy for handling DPI across pattern templates. Some applications have their own DPI settings that are hardcoded in patterns, ignoring the user's actual display configuration. This leads to mismatched scaling across the desktop.

Current state by application

Component	DPI handling	Issue
Polybar	Own dpi-x/dpi-y settings	Hardcoded to 96, independent of system DPI
Rofi	Auto-reads Xft.dpi	Handles DPI on its own, no gtheme intervention needed
Dunst	per_monitor_dpi = false	All dimensions (padding, icon sizes, line height) hardcoded in pixels
Awesome	xresources.apply_dpi wrapper	Already handles DPI properly
Tint2	scale_relative_to_dpi = 1	Already handles DPI properly

For example, a user with Xft.dpi: 144 (1.5x scaling) will have fonts and UI elements scaled system-wide, but polybar stays at 96 DPI — resulting in a visually smaller bar compared to the rest of the desktop.

Proposed solution

1. Add dpi as a user property

Add DPI to the setup wizard (src/cli/setup.rs) in the Others section, alongside font settings:

• Prompt: "Select DPI (common values: 96, 120, 144, 168, 192)"
• Validator: positive integer within a reasonable range
• Property key: dpi
• Default: 96

This ensures DPI is configured during installation and stored in user_settings.toml:

dpi = '144'

2. Parameterize DPI in pattern templates that need it

For apps with their own explicit DPI settings that don't read the system DPI (like polybar), use the template placeholder:

dpi-x = <[dpi|96]>
dpi-y = <[dpi|96]>

This way the user sets their DPI once and it gets injected into every app that needs it on each theme apply.

Scope

• All desktop templates (simple, wip, hypr, japan, minimal, night, retro) should be audited for hardcoded DPI values
• Apps with their own DPI config that ignore system DPI (like polybar) should use <[dpi|96]>
• Apps that already read system DPI (rofi, awesome, tint2) don't need changes