Feat/dock concave side corners

[tibssy]

Summary

This PR adds concave (inverted) dock corner support using negative radius values, similar to bar corner behavior.

Key Changes

• Allows negative dock radius values in config schema (kDockRadiusRange now supports -80..80)
• Implements dock concave shape mapping and geometry handling for all dock edges
• Updates dock rendering pipeline (panel, shadow, compositor blur tessellation) to use corner shape + logical inset data
• Keeps convex behavior unchanged for non-negative radius values
• Updates assets/translations/en.json descriptions for dock corner radius settings

Summary

Motivation

Users can now create a dock shape that visually blends into edges/surfaces (e.g. concave side cuts for bottom docks), similar to V4..

Type of Change

• Bug fix
• New feature
• Breaking change
• Refactoring
• Build / packaging

Related Issue

Testing

• just format
• ninja -C build-debug
• just lint
• just test
• python3 tools/i18n-check.py
• just configure release && just build release

Manual Coverage

• Verified concave dock corners with negative radius values

• Confirmed expected behavior for bottom dock with side concave cuts:

  • radius_bottom_left = -12
  • radius_bottom_right = -12

• Confirmed normal convex corners still behave as before when values are non-negative

• Tested on Niri

• Tested on Hyprland

• Tested on Sway

• Tested on another compositor:

• Tested with different bar positions and density settings

• Tested at different interface scaling values

• Tested with multiple monitors

Screenshots / Videos

recording_20260629_003202.mp4

Checklist

• This PR is ready for review, or it is marked as Draft.
• I read and followed the relevant guidance in CONTRIBUTING.md.
• I ran just format with clang-format v22+ installed, or this PR has no code changes.
• I ran the relevant build or test commands, or explained why they were not run.
• I self-reviewed the changes.
• I checked for new warnings or errors.
• I will update end-user documentation after merge, or this PR does not change user-facing configuration or behavior.
• I added or updated assets/translations/en.json, or this PR adds no new user-facing strings.
• I did not edit non-English translation files unless this PR is explicitly for translation tooling, an import/export sync, or a maintainer-requested locale change.
• I used the existing canonical names for config keys, IPC names, paths, and identifiers.

Additional Notes

• Addressed clang-tidy findings after rebase (dock_instance + workspace_alert_service modernize warnings).

[tibssy]

Rebased on latest main, addressed clang-format/clang-tidy follow-ups, and reran local validation (just format, just lint, just test, debug/release builds).

[ItsLemmy]

Thanks for the PR.

This works (by chance) because you have shadow enabled or use small radii and the inverted corners "live" in the shadow padding around the geometry. If you disabled shadows the inverted corners will clip.

computeSurfaceGeometry/computePanelGeometry don't account for logicalInset as they should.

Also since the concave corners only work on the screen edge corners, maybe the translations should say: "..., negative values carve a concave corner when this corner faces the screen edge""

[tibssy]

Thanks for the review @ItsLemmy

I’ve pushed a fix so computePanelGeometry now account for logicalInset, and I also updated the corner-radius wording to clarify the screen-edge behavior. I’m planning one more improvement before the final review, like moving away from negative radius values and adding an explicit toggle for concave edge corners, so users can enable this behavior directly.