Add DPI as user-configurable property

[Copilot]

gtheme lacks a consistent DPI handling strategy. Applications like Polybar use hardcoded DPI values independent of system configuration, causing mismatched scaling across desktop components.

Changes

• Added DPI validator (Section::validate_dpi) that accepts integers 48-384
• Extended setup wizard with DPI prompt in Others section after font settings
• Property stored in user_settings.toml as dpi = '<value>'

Usage

Templates can now inject user's configured DPI:

[bar/main]
dpi-x = <[dpi|96]>
dpi-y = <[dpi|96]>

The placeholder syntax <[dpi|96]> uses the user's value or defaults to 96 if not configured.

Scope

This PR provides the property infrastructure. Desktop template patterns in gtheme-desktops repository can now be updated to use <[dpi|96]> instead of hardcoded values.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• github.com (HTTP Only)
  • Triggering command: /usr/bin/ssh /usr/bin/ssh -o SendEnv=GIT_PROTOCOL git@github.com git-upload-pack 'daavidrgz/gtheme-desktops.git' (packet block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Add DPI as a first-class user-configurable property</issue_title>
<issue_description>## 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</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Add DPI as a first-class user-configurable property #1

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.