sway/workspaces default padding/margin issue.

[aspauldingcode]

When I set sway workspaces onto my bar, the bar suddenly gets THICC.

This is happening with no css changes. However, theres a problem. The problem is, the css configuration doesn't allow me to fix it. Setting padding and margin to 0 for workspaces and buttons, doesn't fix the issue for me. I was able to temporarily fix it months ago by setting a negative margin size. However, this caused graphical issues. In addition, it doesn't work anymore. I am using Waybar v0.10.3 on NixOS 24.05 with swayfx version 0.4 (based on sway 1.9.0).

For the sake of trying to explain the problem, I will color the background red.

The buttons are WAY too big by default, and I am unable to make them any smaller. I'm going to add a small margin around the button, so they will be visible seperately for each workspace.

if I remove the workspaces. the height of the bar goes to normal.

you may not see the height difference. So, here is a dramatic comparison. no css, with workspace: no css, without workspace:

all I have to do is add:

    "sway/workspaces" = {
      disable-scroll = true;
      all-outputs = true;
    };

to my nix waybar configuration, and add no css, and suddenly we have a completely disfunctional bar.

[RobertMueller2]

Well, but it can be configured to be slim.

This is a bar at the top, the grey stuff is just my background, so not really the waybar anymore. It's accepting the height of 16 without a warning, so it's all a matter of styling.

The superscripted letter reaches beyond ascent to the top and leaves no padding or margin.

The space in the teal area towards the bottom is not unreasonable, that's the area between descent and bottom. There needs to be some space for that, I don't know if there are any fonts covering this area, but if there were, the remaining space would become minimal, probably as close the À to the top.

The trick might be to set 0 paddings and margins for the whole hierarchy, gtk seems to be a bit strange regarding that, not really considering * for everything, and sometimes styles for elements in a hierarchy gets lost. The whole hierarchy can be discovered using GTK_DEBUG=interactive.

Regarding the complaint about the unsound default, I'm inclined not to agree. There is no explicit default styling for any of the modules, why start here? It's unfortunate workspaces ends up with widget, box, button, label, that's a lot of nested GUI elements and some space usage for a default is to be expected.

I think this is mostly a documentation issue. Perhaps resources/style.css could be edited as well. Just my personal 2 cents.

I'm using this config for visualisation:

{
    "ipc": "true",
    "id": "bar-0",
    "layer": "top", // Waybar at top layer
    "position": "top", // Waybar position (top|bottom|left|right)
    "height": 16, // Waybar height (to be removed for auto height)
    // Choose the order of the modules
    "modules-center" : [ "sway/workspaces" ],
    // Modules configuration
    "sway/workspaces": {
         "disable-scroll": true,
         "all-outputs": true,
         "format": "{name}jÀ<span font-family=\"FontAwesome\">{icon}</span>",
         "format-icons": {
             "1": "",
             "01": "",
             "11": "",
             "2" : "",
             "02" : "",
             "12" : "",
             "3" : "",
             "03" : "",
             "13" : "",
             "4" : "",
             "04" : "",
             "14" : "",
             "5" : "",
             "05" : "",
             "15" : "",
             "6" : "",
             "06" : "",
             "16" : "",
             "7" : "",
             "07" : "",
             "17" : "",
             "8" : "",
             "08" : "",
             "18" : "",
             "9" : "",
             "09" : "",
             "19" : "",
//           "urgent": "",
//           "focused": "",
             "default": ""
         }
     },
}

* {
    border-radius: 0;
    font-family: terminus;
    min-height: 0;
}

window /* white */
{
    background-color: #ffffff;
}

window box /* red */
{
    background-color: #ff0000;
    padding-top: 0px;
    padding-bottom: 0px;
}

window box box /* green */
{
    background-color: #00ff00;
}

window box box widget /* blue */ {
    background-color: #0000ff;
}

window box box widget box /* yellow */ {
    background-color: #ffff00;
}

window box box widget box button /* pink */ {
    background-color: #ff00ff;
}
window box box widget box button label /* teal */ {
    background-color: #00ffff;
}

window,
window box,
window box box,
window box box widget,
window box box widget box,
window box box widget box button,
window box box widget box button label {
    padding-top: 0px;
    padding-bottom: 0px;
    margin-top: 0px;
    margin-bottom: 0px;
    min-width: 0px;
    border: 0px;
}

#workspaces {
    /* margin-top: 8px; */
    margin-left: 4px;
    margin-right: 4px;
    min-height: 0;
}

[RobertMueller2]

What's quite funny though, using ∫ (which reaches the bottom) changes the rendering. With it, Waybar needs at least 17 pixels, and there is some space within the label, not too much though. I think that deserves some investigation. This is caused by Gtk and I'm not sure if waybar can do anything about it, and if it doesn't happen in Gtk 4 there isn't much point, but let's see what happens.

Still quite slim though:

[RobertMueller2]

I can sort of reproduce the last bit with a minimal gtk4-rs application, which was largely copied from the gtk4-layer-shell example.

As soon as I include ∫, the height of the label and window grows from 15 to 17 pixel. There might be a valid reason for all this, but with my limited understanding of font rendering I'd expect a label to be at least as tall as the distance between top and bottom.

But: assuming that 17 pixel is the "real size" between top and bottom, the smaller value of 15 in gtk4 or 16 in gtk3 would in fact be the wrong one. I'm not sure, but since ∫ might not be that common in layer shell application, I'd rather leave it at that.

From my point of view, the remaining padding after styling everything is not a Waybar issue, though.

repro code

``` use gio::prelude::*; use gtk4::prelude::*; use gtk4_layer_shell::{Edge, Layer, LayerShell}; // https://github.com/wmww/gtk-layer-shell/blob/master/examples/simple-example.c fn activate(application: >k4::Application) { // Create a normal GTK window however you like let window = gtk4::ApplicationWindow::new(application); // Before the window is first realized, set it up to be a layer surface window.init_layer_shell(); // Display above normal windows window.set_layer(Layer::Top); // Push other windows out of the way window.auto_exclusive_zone_enable(); // The margins are the gaps around the window's edges // Margins and anchors can be set like this... window.set_margin(Edge::Left, 40); window.set_margin(Edge::Right, 40); window.set_margin(Edge::Top, 20); // ... or like this // Anchors are if the window is pinned to each edge of the output let anchors = [ (Edge::Left, true), (Edge::Right, true), (Edge::Top, true), (Edge::Bottom, false), ]; for (anchor, state) in anchors { window.set_anchor(anchor, state); } // Set up a widget let label = gtk4::Label::new(Some("")); //label.set_markup("jÀ∫"); label.set_markup("jÀ"); window.set_child(Some(&label)); let x = window.show(); println!("{:?}|{:?}", window.preferred_size(), label.preferred_size()); x } fn main() { let application = gtk4::Application::new(Some("sh.wmww.gtk-layer-example"), Default::default()); application.connect_activate(|app| { activate(app); }); application.run(); } ```