Skip to content

Configurable zoom keybindings (zoom-in unreachable via the "+" key on non-US keyboard layouts) #2706

@pvojnisek

Description

@pvojnisek

Before submitting

Area

Desktop / keybindings

Problem or use case

On a Hungarian keyboard layout, the zoom-in shortcut is effectively unreachable.

On this layout + is typed as Shift+3, but Ctrl+Shift+3 does nothing. Zoom-in only fires via Ctrl+Shift+ó — because ó sits on the physical key position that US layouts use for =/+. Ctrl+- (zoom out) and Ctrl+0 (reset) work fine.

So zoom-in technically works, but it is bound to a key whose label has nothing to do with +, which makes it undiscoverable. This matches how Chromium binds zoom shortcuts (by physical key position), so it is not strictly a bug — but it leaves users on non-US layouts without a discoverable, usable zoom-in.

Environment: T3 Code 0.0.23, Linux (Pop!_OS / COSMIC, Wayland), Electron AppImage, Hungarian keyboard layout, 2880×1800 HiDPI laptop panel.

Proposed solution

Allow zoom keybindings to be configured in Settings — a section that shows the current zoom shortcuts and lets the user rebind them.

Why this matters

Anyone on a non-US physical layout (Hungarian, German, French, etc.) currently cannot comfortably discover or use zoom-in. On a HiDPI laptop panel, zoom is not optional — it is what makes the app usable at all.

Smallest useful scope

A full keybindings UI is not required. The minimal fix: in the zoom keydown handler, also accept event.key === '+' / '=' (the produced character), not only the physical event.code. Then Ctrl+Shift+3 — the way + is actually typed on a Hungarian layout — works alongside the existing physical-key binding. Configurable keybindings would be the fuller solution.

Alternatives considered

  • Ctrl+Shift+ó works, but is undiscoverable.
  • Launching the AppImage with --force-device-scale-factor=N works, but is CLI-only and not adjustable from the UI.
  • Temporarily switching the OS keyboard layout to US to zoom, then back — impractical.

Risks or tradeoffs

The minimal event.key addition is low-risk. A full keybindings system is larger scope and overlaps with the open auto-zoom work (PR #406), so the two would need coordination.

Examples or references

Contribution

  • I would be open to helping implement this

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions