Breadway/breadbar
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

surface: pin satellite window width instead of just requesting it

Browse source 
surface::apply()'s SurfaceWidth::Px handling only called
set_default_width(), which is advisory — a wide child (an unwrapped
app-name label, or a long summary/body with nothing narrower than its
natural width to wrap against) overrides it, so breadbar-notif (320px)
and breadbar-osd (180px) could render wider than their theme's
configured width instead of wrapping. This is the exact 'wide child
overrides set_default_width' trap main.rs's capsule Width::Px handling
already learned and documented; apply() predates that fix and never
got it.

Add the same set_size_request(px, -1) pin used there. history.rs's
360px override of the shared breadbar-notif namespace has to override
both calls now, not just set_default_width, since the pin from
apply() would otherwise win over a bare default-width override.
This commit is contained in:
Breadway 2026-08-25 16:19:15 +08:00
parent 02ed92ae9d
commit 1d30818510
2 changed files with 21 additions and 7 deletions
Download patch file Download diff file Expand all files Collapse all files

6
src/notifications/history.rs
View file

@ -180,8 +180,12 @@ pub fn build_window(store: Store) -> Ui {
// Overrides `[surfaces."breadbar-notif"].width` (320px, the live-toast
// popup's width — see `surface::apply`'s doc comment): the history
// window genuinely wants a different width on the same namespace, and
// that isn't something the manifest schema models today.
// that isn't something the manifest schema models today. Both calls
// must be overridden, not just `set_default_width` — `apply()` also
// pins `set_size_request` to the toast's 320px, and a bare width alone
// would lose to that pin the same way it lost to a wide child before.
window.set_default_width(360);
window.set_size_request(360, -1);
window.set_keyboard_mode(KeyboardMode::OnDemand);
crate::theme::bind_auto(&window);

22
src/surface.rs
View file

@ -19,12 +19,15 @@ use gtk4_layer_shell::{Edge, Layer, LayerShell};
/// gtk4-layer-shell's own defaults rather than panicking, matching every
/// other "malformed/incomplete theme" fallback in this system.
///
/// Does not set `set_default_width` for a namespace shared by more than one
/// window with genuinely different widths (`breadbar-notif`'s live toast is
/// 320px, its history sibling is 360px, and only the toast's width is
/// modeled in `[surfaces.*]` — see the Phase 0 constant inventory); callers
/// that need a different width than the theme's own set it explicitly
/// afterward.
/// The width applied here is not authoritative for a namespace shared by
/// more than one window with genuinely different widths (`breadbar-notif`'s
/// live toast is 320px, its history sibling is 360px, and only the toast's
/// width is modeled in `[surfaces.*]` — see the Phase 0 constant inventory);
/// callers that need a different width than the theme's own set it
/// explicitly afterward. Because a `Px` width is pinned with BOTH
/// `set_default_width` and `set_size_request` (see below — the latter is
/// what actually holds against a wide child), such a caller must override
/// both, not just `set_default_width`, or the pin from here wins.
pub fn apply(window: &gtk4::Window, namespace: &str) {
let theme = crate::theme::shell_theme();
let Some(surf) = theme.surfaces().get(namespace) else {
@ -74,5 +77,12 @@ pub fn apply(window: &gtk4::Window, namespace: &str) {
if let SurfaceWidth::Px(px) = surf.width {
window.set_default_width(px);
// set_default_width alone is only a preference — a wide child (an
// unwrapped app-name label, or a long summary/body before GTK has
// any allocation narrower than its natural width to wrap against)
// overrides it, so the window renders wider than the theme's
// requested px and stops matching the theme. Same trap, same fix,
// as main.rs's capsule `Width::Px` handling — see its comment.
window.set_size_request(px, -1);
}
}