Feature: allow anchoring the bar to the left/right screen edge (vertical side-dock) #15

New issue

Closed

opened 2026-09-05 01:37:25 +08:00 by Breadway · 0 comments

Breadway commented

2026-09-05 01:37:25 +08:00

Owner

Request

Support a vertical bar docked to the left or right edge of the screen, as an alternative to the current horizontal top/bottom bar.

Why this isn't just a theme.toml tweak today

[bar.window].anchors already accepts left/right as enum values, but only as edge pins for a horizontal bar — e.g. ["top", "left", "right"] anchors a horizontal bar's ends to both side edges. There's no orientation axis:

width is "fill" | int px and height is always a plain int px (bread-theme/src/shell/types.rs WindowSpec) — there's no "fill vertically, fixed width" mode analogous to today's "fill horizontally, fixed height".
apply_window_spec() in breadbar's src/main.rs (~line 100) always treats height as the bar's fixed chrome dimension and width/anchors as the fill axis; a ["left", "top", "bottom"] anchor set would stretch the window vertically via gtk4-layer-shell, but nothing in the CSS or widget layout would follow — bar content (workspaces, clock, stats) is packed in horizontal Boxes left-to-right the whole way through, with no vertical/stacked equivalent.
The generated CSS (ShellTheme::css()) bakes min-height from the height token; a side-docked bar would need min-width instead, and every chip/pill/slot layout would need a vertical stacking mode.

Scope (rough)

bread-ecosystem/bread-theme: extend WindowSpec/schema so a theme can declare orientation (or derive it from anchors — e.g. anchored to exactly one of left/right without top+bottom both filling horizontally implies vertical), with a thickness dimension replacing the fixed height for that axis.
breadbar: orientation-aware apply_window_spec() (swap which axis is Fill vs fixed), CSS emission (min-width vs min-height), and vertical-stacking layout for bar.slots (workspaces/clock/stats top-to-bottom instead of left-to-right).

Confirmed via code read (2026-09-05): no existing scaffolding for this — it's a real feature, not a config gap like the sibling [panel]/[osd] issues filed alongside this one.

## Request Support a vertical bar docked to the left or right edge of the screen, as an alternative to the current horizontal top/bottom bar. ## Why this isn't just a theme.toml tweak today `[bar.window].anchors` already accepts `left`/`right` as enum values, but only as *edge pins for a horizontal bar* — e.g. `["top", "left", "right"]` anchors a horizontal bar's ends to both side edges. There's no orientation axis: - `width` is `"fill" | int px` and `height` is always a plain `int px` (`bread-theme/src/shell/types.rs` `WindowSpec`) — there's no "fill vertically, fixed width" mode analogous to today's "fill horizontally, fixed height". - `apply_window_spec()` in breadbar's `src/main.rs` (~line 100) always treats `height` as the bar's fixed chrome dimension and `width`/anchors as the fill axis; a `["left", "top", "bottom"]` anchor set would stretch the *window* vertically via gtk4-layer-shell, but nothing in the CSS or widget layout would follow — bar content (workspaces, clock, stats) is packed in horizontal `Box`es left-to-right the whole way through, with no vertical/stacked equivalent. - The generated CSS (`ShellTheme::css()`) bakes `min-height` from the `height` token; a side-docked bar would need `min-width` instead, and every chip/pill/slot layout would need a vertical stacking mode. ## Scope (rough) 1. **bread-ecosystem/bread-theme**: extend `WindowSpec`/schema so a theme can declare orientation (or derive it from `anchors` — e.g. anchored to exactly one of `left`/`right` without `top`+`bottom both filling horizontally` implies vertical), with a `thickness` dimension replacing the fixed `height` for that axis. 2. **breadbar**: orientation-aware `apply_window_spec()` (swap which axis is `Fill` vs fixed), CSS emission (`min-width` vs `min-height`), and vertical-stacking layout for `bar.slots` (workspaces/clock/stats top-to-bottom instead of left-to-right). Confirmed via code read (2026-09-05): no existing scaffolding for this — it's a real feature, not a config gap like the sibling `[panel]`/`[osd]` issues filed alongside this one.

Breadway

2026-09-05 01:37:26 +08:00