`Feature Request: Color-coded & customizable logs, UI custom config fields, and /quota endpoint`

[Montazeran8]

1. Color-coded and customizable log output

Currently, the desktop UI shows all log lines in the same color, making it hard to distinguish between INFO, WARN, and ERROR at a glance. It would greatly improve usability if:

• INFO lines were displayed in green
• WARN lines in yellow/orange
• ERROR lines in red

Additionally, allowing users to customize these colors (e.g., via a simple settings panel or config keys like log_color_info, log_color_warn, log_color_error) would be even better, as it accommodates different visual preferences and accessibility needs.

2. UI field for arbitrary config parameters

At present, adding parameters like force_http1: true, block_doh: true, or other custom options requires manual editing of config.json. The UI's “Save Config” button strips unknown fields (as discussed in #877 and elsewhere), which is confusing and frustrating for users who rely on those parameters.

A dedicated “Custom Parameters” section in the UI – for instance, a simple key-value editor – would solve this permanently. Parameters added there should survive round‑trips through the UI save button, allowing users to manage any config option (present or future) without touching the raw JSON file.

3. /quota endpoint on Code.gs

Following the maintainer's own suggestion (“adding a /quota endpoint to Code.gs that calls UrlFetchApp.getRemainingDailyQuota() could show the bucket size up front”), it would be incredibly helpful to add a minimal doGet handler to Code.gs. Hitting https://script.google.com/macros/s/.../exec/quota would return the remaining daily UrlFetchApp quota as plain JSON, e.g.:

{"remaining": 15432}

This would make it trivial for users to check the exact quota left, debug flag/limit issues, and decide when to switch to another script ID.

I’d be happy to test any of these features or provide more detailed specifications if needed. Thank you for considering these improvements!

[therealaleph]

Reviewed via Anthropic Claude.

Excellent feature trio @Montazeran8. Honest scoping per item:

1. Color-coded logs — easy & high-value. egui has RichText::color(). ~30 lines in src/bin/ui.rs to parse the log line's level prefix and tint accordingly. Custom color keys in config.json doable but I'd ship as 4 hardcoded levels first (INFO=green, WARN=amber, ERROR=red, DEBUG=gray) and only add config knobs if there's pull. Queued for v1.9.x.

2. UI "Custom Parameters" panel — design problem. Two routes:
a. Pass-through preserve: add #[serde(flatten)] extra: HashMap<String, Value> to Config so unknown fields round-trip. Cheap (~5 lines) but doesn't help discoverability — users still need to know the field name. The fix for #877's surprising-strip behavior.
b. Full custom-params editor: row-based key-value UI, type detection (bool/int/string/array). ~150 lines of UI code. Risk: users add typos that don't map to anything (paralel_relay instead of parallel_relay) and it silently no-ops.

Likely shipping (a) soon, deferring (b). (a) alone fixes the bug in #877 — at least your parallel_concurrency: 10 would round-trip even though it's unrecognized.

3. /quota endpoint on Code.gs — agreed, my own suggestion. Implementation:

// doGet entry — when called with ?path=quota
if (e.parameter && e.parameter.path === 'quota') {
  return ContentService.createTextOutput(
    JSON.stringify({ remaining: UrlFetchApp.getRemainingDailyQuota() })
  ).setMimeType(ContentService.MimeType.JSON);
}

Catch: UrlFetchApp.getRemainingDailyQuota() is only available within the executing script's context — i.e., it returns the quota for the owning Google account, not the deployment-specific quota. So one call per script_id is meaningful. Not a blocker, just a clarification for the UI display.

Queued. Plus a mhrv-rs quota CLI subcommand that hits all configured script_ids and prints a table.

For all three: timeline depends on user demand. (1) easiest, will probably land in next 1–2 patch releases. (2a) will land alongside (1). (2b) and (3) may land later or get split into smaller PRs.

Leaving open as the tracking issue. Thanks for the structured writeup — exactly the kind of issue that makes prioritization easy.