EWW bar with leftWM - get tiled like a normal window

[somemarco]

Hi community,

I currently try to move to leftWM and thought I choose for the Bar EWW as it seemed to be a viable choice.
I tried with multiple theme's however on the ones which work at least partly the Bar gets managed by leftWM like a normal tiled window. In my setup when I restart (mod + shift + r) the current screen with nvim (which has the theme/leftwm config open) gets split and on the right the bar gets displayed.

Theme from community I tried the Amber theme as it was the only one I was able to find in the community repository with EWW. The polybar option works as expected. The only other one i was able to find with leftWM and EWW is https://github.com/VuiMuich/leftwm-theme-serika , which when enabled has the same issue that the bar is tiled like a normal window.

I'm running on Fedora Silverblue 40 and have compiled leftWM from the main branch from this morning (e.g. has the fix in it for Scratchpads command execution with args). EWW is also from the master branch compiled. The dependend system libraries (X etc) are installed and available.

Tried different options, and searched quiet a bit. It seems like it should work but it doesn't and i fail to see where the problem originates from.

Does anyone has an idea or a working theme/config I could give a try?

my current LeftWM config:

#![enable(implicit_some)]
#![enable(unwrap_newtypes)]
(
    backend: xlib,
    log_level: "debug",
    modkey: "Mod4",
    mousekey: "Mod4",
    workspaces: [],
    tags: [
        "- -",
        "-󰖟-",
        "-󰊢-",
        "-4-",
        "-5-",
        "-6-",
    ],
    max_window_width: None,
    layouts: [
       // shortened, is default
    ],
    layout_definitions: [
       // shortened, is default
    ],
    // changed from Tag to Workspace for bar trobuleshooting
    layout_mode: Workspace,
    insert_behavior: Bottom,
    scratchpad: [
        (name: "Alacritty", value: "alacritty", x: 0.055, y: 65, width: 0.89, height: 0.34),
        (name: "Music", value: "alacritty", args: ["-e", "spotify_player"], x: 0.055, y: 65, width: 0.89, height: 0.89),
    ],
    window_rules: [],
    disable_current_tag_swap: false,
    disable_tile_drag: false,
    disable_window_snap: true,
    focus_behaviour: Sloppy,
    focus_new_windows: true,
    single_window_border: true,
    sloppy_mouse_follows_focus: true,
    create_follows_cursor: None,
    auto_derive_workspaces: true,
    disable_cursor_reposition_on_resize: false,
    keybind: [
       // shortened, is default
        // Custom
        (command: ToggleScratchPad, value: "Alacritty", modifier: ["modkey"], key: "t"),
        (command: ToggleScratchPad, value: "Music", modifier: ["modkey"], key: "m"),
    ],
    state_path: None
)

[Eskaan]

This could be a configuration issue with eww, but you can also set a window rule forcing it to spawn as dock:

(window_class: "eww", spawn_as_type: Dock),

To get the window class/title (my example above is just a guess), run xprop in a terminal and click on the eww window (see linked wiki for what to look at).

[somemarco]

Thanks for the fast reply!
The Amber Theme specifies I think this correctly :windowtype "dock".
I have added the suggested window rule to the leftwm config and restarted leftWM, however the tiling still happens as a normal window.

The command output from xprop confirms that the windows_class in the window rule should also have worked (WM_CLASS(STRING) = "eww", "Eww") - but it somehow doesn't end up as a 'dock'. I tried also with an simple eww.yuck file which basically only displays an "Hello World" label. There the result is similar the supposed "dock" gets rendered as a window either occuping the whole screen or a split tile of it.

Do you have any further pointers where the problem could reside? I also checked the EWW docs, issues, discussions but didn't find much on the leftWM/EWW combination.

❯ xprop
_NET_WM_OPAQUE_REGION(CARDINAL) = 0, 0, 618, 1058
_NET_WM_DESKTOP(CARDINAL) = 1
WM_STATE(WM_STATE):
                window state: Normal
                icon window: <field not available>
_NET_WM_STATE(ATOM) = _NET_WM_STATE_SKIP_TASKBAR, _NET_WM_STATE_SKIP_PAGER
WM_HINTS(WM_HINTS):
                Client accepts input or input focus: True
                Initial state is Normal State.
                window id # of group leader: 0xc00001
_GTK_THEME_VARIANT(UTF8_STRING) =
XdndAware(ATOM) = BITMAP
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0x0, 0x0, 0x0, 0x0
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 12582917, 12582918
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0xc00004
WM_CLIENT_LEADER(WINDOW): window id # 0xc00001
_NET_WM_PID(CARDINAL) = 3484543
WM_LOCALE_NAME(STRING) = "en_US.UTF-8"
WM_CLIENT_MACHINE(STRING) = "<redacted>"
WM_NORMAL_HINTS(WM_SIZE_HINTS):
                program specified minimum size: 1920 by 30
                program specified base size: 0 by 0
                window gravity: Center
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_CLASS(STRING) = "eww", "Eww"
WM_ICON_NAME(STRING) = "Eww - bar0"
_NET_WM_ICON_NAME(UTF8_STRING) = "Eww - bar0"
WM_NAME(STRING) = "Eww - bar0"
_NET_WM_NAME(UTF8_STRING) = "Eww - bar0"

[Eskaan]

Did you try to set a window rule for it?

[somemarco]

Yes as noted I added the suggested window_rule to the leftwm config, the result remains the same. The bar/dock gets tiled like a normal window.

In the output above from xprop its also visible that somehow the dock/bar from eww ends up to be classed as _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL. which looks wrong to me and not according to the eww.yucks definition and the leftwm window_rule.

current config.ron from Leftwm:

#![enable(implicit_some)]
#![enable(unwrap_newtypes)]
(
    // switched to x11rb from xlib for bar troubleshooting
    backend: x11rb,
    log_level: "debug",
    modkey: "Mod4",
    mousekey: "Mod4",
    workspaces: [],
    tags: [
        "- -",
        "-󰖟-",
        "-󰊢-",
        "-4-",
        "-5-",
        "-6-",
    ],
    max_window_width: None,
    layouts: [
       // removed to reduce output size
    ],
    layout_definitions: [
       // removed to reduce output size
    ],
    // changed from Tag to Workspace for bar troubleshooting
    layout_mode: Workspace,
    insert_behavior: Bottom,
    scratchpad: [
        (name: "Alacritty", value: "alacritty", x: 0.055, y: 65, width: 0.89, height: 0.34),
        (name: "Music", value: "alacritty", args: ["-e", "spotify_player"], x: 0.055, y: 65, width: 0.89, height: 0.89),
    ],
    window_rules: [
        (window_class: "eww", spawn_as_type: Dock),
    ],
    disable_current_tag_swap: false,
    disable_tile_drag: false,
    disable_window_snap: true,
    focus_behaviour: Sloppy,
    focus_new_windows: true,
    single_window_border: true,
    sloppy_mouse_follows_focus: true,
    create_follows_cursor: None,
    auto_derive_workspaces: true,
    disable_cursor_reposition_on_resize: false,
    keybind: [
        // removed to reduce output size
        // Custom
        (command: ToggleScratchPad, value: "Alacritty", modifier: ["modkey"], key: "t"),
        (command: ToggleScratchPad, value: "Music", modifier: ["modkey"], key: "m"),
    ],
    state_path: None
)

[somemarco]

I tried a couple of more things and noticed that in above config the backend is misspelled and corrected it. With that the basic EWW example works! 😃

I now switched back to the default to verify and it doesn't seem to work.

So as of now:

• With the default backend XLib it does not work. ⚠️
• With the rust based backend X11rb it does work. ✅

Will do some further cleanup and tests to try to confirm or disprove that the changed backend makes the difference.

EDIT:
@Eskaan: Thanks a lot for your support! It works now with the rust based backend!

Did reboots and cleanups and was able to confirm above behaviour.
For reference the version/commits used:

Distribution: Fedora Silverblue 40

❯ rpm-ostree status
State: idle
Deployments:
● fedora:fedora/40/x86_64/silverblue
                  Version: 40.20240412.n.0 (2024-04-12T08:13:30Z)
               BaseCommit: 33868bd22cefb70fc9b160a1aa15bc52d97c30968f547e390de22e7ebae422bd
             GPGSignature: Valid signature by 115DF9AEF857853EE8445D0A0727707EA15B79CC
          LayeredPackages: alacritty conky containernetworking-plugins dmenu feh
                           git-credential-libsecret git-lfs gnome-pomodoro gtk-layer-shell keybinder3
                           libdbusmenu-gtk3 neovim nu picom pinentry-tty polybar rofi wireguard-tools

LeftWM build from Commit: 3f3849d
EWW build from Commit: ebe5f34

[Eskaan]

Congrats to @Syudagye, this is the first thing your backend does better. Now someone has to search for the issue with Xlib.

[somemarco]

One thing I noticed now with the X11rb backend is that the Scratchpads are not being overlayed as Scratchpads but just get spawned as normal windows in the active layout.

Didn't find an open issue/wiki notes on this. Is this a new/unknown issue?

[Syudagye]

Congrats ***@***.***, this is the first > thing your backend does better. Now someone has to search for the issue with Xlib.

I'm glad to see this !

One thing I noticed now with the X11rb backend is that the Scratchpads are not being overlayed as Scratchpads but just get spawned as normal windows in the active layout. Didn't find an open issue/wiki notes on this. Is this a new/unknown issue?

Is you scratchpad set to floating ? I believe by default it juste spawns a normal window indeed, and tiles it with the other. If it's floating on xlib and not x11rb with the same config it's probably a new issue yes

[somemarco]

Yes the only config i changed was the backend, so on XLib its floating, on X11rb its tiled with the same scratchpad config.

Also noticed two other things: the window_rule which sets for the eww bar windows the type to Dock is still required - however would like to triple check if everything is correct on eww side.

The other thing is that I noticed that the compositor (picom) transparency does not work if backend is X11rb, if its XLib it works.

For both things would verify the problem again and then create an issue with details (config, versions, etc).

I'm today/tomorrow short on time so probably will do that on monday.

Thanks again for the support!