Run without sway

[yavko]

It would be nice if the bar could run without the features that require sway if it isn't present, also for workspaces to use the standardized wlr_ext_workspace_unstable_v1 protocol. I would love to try this bar, but I run Hyprland and not sway.

But I'm willing to add support for Hyprland as a pr in the future, and it wouldn't be too hard as I have developed a crate to communicate with Hyprland.

[JakeStanger]

Hey, thanks for the interest! I'd definitely like to make the bar independent from Sway. The biggest roadblock for me at the moment is I'm not too familiar with Wayland or wlroots under the hood (Sway's IPC server proved the easy option).

The bar relies on Sway's IPC server in these places currently:

• On startup, to get output names. This is used to parse multi-monitor config options and for the Workspaces module
• In the workspaces module, to subscribe to workspace events
• In the launcher and focused modules, to subscribe to window events

The first one is the biggest hurdle. If I can get output names in a stable/reliable way that (ideally) doesn't vary between compositors, the bar can at least run under different compositors.

The workspaces can probably be ported to wlr_ext_workspace_unstable_v1 as you say, although I'll need to find out more about that.

The other two modules I've no idea currently - if you've any knowledge on how I could get window events agnostically let me know!

---

But I'm willing to add support for Hyprland as a pr in the future, and it wouldn't be too hard as I have developed a crate to communicate with Hyprland.

I've got quite a large refactor I'm finishing up at the moment so I'd recommend holding off for now, but I'm definitely interested in knowing more about this!

[yavko]

I'll try to find suitable protocols, but i know the outputs can definitely done with a wlr ext protocol, for the window events i think there might have been one though ill have to do more research

[yavko]

I've got quite a large refactor I'm finishing up at the moment so I'd recommend holding off for now, but I'm definitely interested in knowing more about this!

Sounds good!

[yavko]

For outputs the https://wayland.app/protocols/wlr-output-management-unstable-v1 protocol can be used!

[yavko]

And https://wayland.app/protocols/wlr-foreign-toplevel-management-unstable-v1 for window events!

[yavko]

Found a crate that provides bindings to wlr specific wayland protocols https://crates.io/crates/wayland-protocols-wlr (which uses wayland-scanner), though it may be better just to use wayland-rs' wayland-scanner and wayland-rs

[JakeStanger]

Awesome thanks for these! Getting output names through Wayland doesn't look too tricky, so I should be able to get the bar running outside Sway pretty quickly. I'll tackle the others after as I suspect those will need a bit more work

[JakeStanger]

First step! I've got a bit of tidying/testing to do before it gets pushed up, but I've got the bar running in Hyprland:

Monitor names and ordering look to line up with what Sway reports so that's great, and all modules except focused/launcher/workspaces should work straight away.

The animations even work for the popup which I guess makes sense, but is very cool to see!

[yavko]

Great progress! Can't wait for full support!

[JakeStanger]

Quick update. I've managed to get as far with the toplevel management as to get a list of windows out so just need to figure out properly listening to events, which is the hard bit.

Unfortunately it looks like the workspace protocol hasn't actually been merged into wlroots or sway yet so I won't be able to port that off the Sway IPC server. If the aforementioned Hyprland crate can handle that we can look at abstracting the calls behind a trait & being able to pick between the Sway/Hyprland/whatever else clients.

[yavko]

I think the way it should be done is to create a unix socket, and then it can receive events from it. For example someone can write a shell script that uses socat to listen to their wm, and then use socat to write to ironbar, so its wm independant.

[JakeStanger]

That's a clever idea and I'm all for that, but I think that should be added in the long-term as a fallback option. If I can feasibly add native support that means users don't need to set up a second process, which is definitely preferable (I'd rather the bar was batteries included).

If anybody on an unsupported compositor then wants to use the bar, they could then write a script.

[yavko]

Yeah thats how it should be done!

[JakeStanger]

I've just pushed a big update on the feat/wayland-protocols branch that integrates wlr-foreign-toplevel-management-unstable-v1 and ports the focused module over to it.

It seems to work in both Sway and Hyprland for me, but could you build it and see if it works for you too please?

[yavko]

Doesn't open

Details

``` 2022-10-05T03:18:28.107317Z INFO ironbar: Ironbar version 0.5.2 2022-10-05T03:18:28.107336Z INFO ironbar: Starting application 2022-10-05T03:18:28.192483Z INFO ironbar: Creating bar on 'eDP-1' The application panicked (crashed). Message: internal error: entered unreachable code Location: /home/yavor/.cargo/git/checkouts/swayipc-rs-8bf762d2a36edf0b/6464c41/async/src/socket.rs:19 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ BACKTRACE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ⋮ 7 frames hidden ⋮ 8: core::panicking::panic::hbe0e36c7510ee8e3 at /rustc/060e47f74a91b28c3db28d80a6a9d6841ca51026/library/core/src/panicking.rs:48 9: as core::future::future::Future>::poll::h05919756fef3461f at : 10: as core::future::future::Future>::poll::h4987e99dd62068a7 at : 11: as core::future::future::Future>::poll::hf31b4c41a592f1e8 at : 12: as core::future::future::Future>::poll::h7da629fd7657bb3d at : 13: std::thread::local::LocalKey::with::h41d1f7ba92474673 at : 14: tokio::park::thread::CachedParkThread::block_on::h9d696311f351feff at : 15: tokio::runtime::handle::Handle::block_on::h08591b114eab6b5d at : 16: tokio::runtime::enter::exit::h94fd083791e0bdce at : 17: tokio::runtime::scheduler::multi_thread::worker::block_in_place::hb3e5015292147077 at : 18: >::spawn_controller::hc99723603e4e8cb9 at : 19: ironbar::bar::add_modules::hce6abb4336c8e147 at : 20: ironbar::bar::create_bar::h8f4116077ad20c08 at : 21: as core::future::future::Future>::poll::h226fe8e8312e4b75 at : 22: std::thread::local::LocalKey::with::h9192df796939cc66 at : 23: tokio::park::thread::CachedParkThread::block_on::hb1d4ea8b0205ef49 at : 24: tokio::runtime::handle::Handle::block_on::h20203de41fc3dea0 at : 25: tokio::runtime::enter::exit::h61e669521ce6f409 at : 26: tokio::runtime::scheduler::multi_thread::worker::block_in_place::h5632fbba6c484958 at : 27: ::connect_activate::activate_trampoline::ha6554fc4c3946ece at : 28: g_closure_invoke at : 29: g_signal_emit_valist at : 30: g_signal_emit at : 31: g_application_run at : 32: ::run_with_args::h331634c7871cb578 at : 33: as core::future::future::Future>::poll::h40cf4dbf09a0680d at : 34: std::thread::local::LocalKey::with::h8575ab078cb14c73 at : 35: tokio::park::thread::CachedParkThread::block_on::h76a1d49c024562f8 at : 36: tokio::runtime::scheduler::multi_thread::MultiThread::block_on::hc865733a62c9d202 at : 37: tokio::runtime::Runtime::block_on::h4509df460ce7e0e1 at : 38: ironbar::main::ha7f6c29b79275860 at : 39: std::sys_common::backtrace::__rust_begin_short_backtrace::ha6f017eed1811fac at : 40: std::rt::lang_start::{{closure}}::h9b65f9fe3470925a at : 41: core::ops::function::impls:: for &F>::call_once::hed7373fa9659f259 at /rustc/060e47f74a91b28c3db28d80a6a9d6841ca51026/library/core/src/ops/function.rs:280 42: std::panicking::try::do_call::h60869ea5a827d812 at /rustc/060e47f74a91b28c3db28d80a6a9d6841ca51026/library/std/src/panicking.rs:492 43: std::panicking::try::he306a2f2634a9efa at /rustc/060e47f74a91b28c3db28d80a6a9d6841ca51026/library/std/src/panicking.rs:456 44: std::panic::catch_unwind::hd1d792c621528cfe at /rustc/060e47f74a91b28c3db28d80a6a9d6841ca51026/library/std/src/panic.rs:137 45: std::rt::lang_start_internal::{{closure}}::h30ae6a495b5c3af9 at /rustc/060e47f74a91b28c3db28d80a6a9d6841ca51026/library/std/src/rt.rs:128 46: std::panicking::try::do_call::h6f1b5a7cf2085723 at /rustc/060e47f74a91b28c3db28d80a6a9d6841ca51026/library/std/src/panicking.rs:492 47: std::panicking::try::haed14f11242573f1 at /rustc/060e47f74a91b28c3db28d80a6a9d6841ca51026/library/std/src/panicking.rs:456 48: std::panic::catch_unwind::he2604d2aa152a0fc at /rustc/060e47f74a91b28c3db28d80a6a9d6841ca51026/library/std/src/panic.rs:137 49: std::rt::lang_start_internal::h8856a10dcbd75374 at /rustc/060e47f74a91b28c3db28d80a6a9d6841ca51026/library/std/src/rt.rs:128 50: main at : 51: __libc_start_main at : 52: _start at /build/glibc/src/glibc/csu/../sysdeps/x86_64/start.S:115 Run with COLORBT_SHOW_HIDDEN=1 environment variable to disable frame filtering. ```

[JakeStanger]

Thanks for trying. I can see in the backtrace it's trying to load the workspaces module which is still sway-only (as is the launcher module). Can you check your config and test again please?

If you get focused working I will work on porting the other two.

[yavko]

Strange i removed it from my config

[JakeStanger]

If that's the case could you please share:

• The contents of your config directory
• The contents config file you believe is being loaded

I can then try and investigate what's going on. At the moment I've got nothing to go on.

[JakeStanger]

I've ported over the launcher module, although there's some glaring room for optimisation at the moment, which I'll look at before next release.

[heisfer]

Seems like launcher, focus, sysinfo, clock and tray is working on hyprland. (upper is waybar and little bit below is ironbar)

[heisfer]

At first for me too new update didn't work (sway ipc error) but for some reason git didn't pull new updates (I checked if I was in a right branch). but after deleting and re downloading it worked so..

[JakeStanger]

I'm going to merge the changes into master as-is as I think they're ready, but I'm holding off the workspaces module until the linked hyperland-rs bug is resolved.

[yavko]

👍

[yavko]

I'm going to merge the changes into master as-is as I think they're ready, but I'm holding off the workspaces module until the linked hyperland-rs bug is resolved.

The Hyprland-rs bug was fixed, I can publish a alpha release if you'd prefer to use a release instead of master, as atm I'm still polishing it for a full major release, tho API has mostly stabilized

[JakeStanger]

Awesome! I won't be able to get a release out until there's a Hyperland-rs release since crates.io doesn't let you publish git/path deps. I can start working on support and get that pushed up to its own branch/master soon though

[yavko]

Ah, I'll work on getting a release out once im back home. Thanks for telling me!

[yavko]

Awesome! I won't be able to get a release out until there's a Hyperland-rs release since crates.io doesn't let you publish git/path deps. I can start working on support and get that pushed up to its own branch/master soon though

I've release an alpha release, its now on crates.io as well! https://github.com/hyprland-community/hyprland-rs/releases/tag/0.3.0-alpha.0

[JakeStanger]

PR finally pushed!

No configuration should be needed to get it working. If anybody on Hyprland can give it a go and double-check it all works (I've only tested inside a Hyprland session nested in Sway with the default config) please let me know how it goes.

It also comes with some general improvements to the workspaces module.

[yavko]

I know you just merged this, but I released a full release of Hyprland-rs like 10 mins ago 💀 https://github.com/hyprland-community/hyprland-rs/releases/tag/0.3.0

[JakeStanger]

That's cool, I've got a few other deps to update so I'll just add it to the list

[yffengdong]

I tested in wayfire, it support now except workspace archlinux

[yavko]

I tested in wayfire, it support now except workspace archlinux

Wayfire doesn't have IPC does it?

[yffengdong]

I tested in wayfire, it support now except workspace archlinux

Wayfire doesn't have IPC does it?

Doesn't have, and they may use dbus about workspace, for now use api, may support workspace protocol after https://github.com/WayfireWM/wayfire/issues/49#issuecomment-650819625

[yavko]

I tested in wayfire, it support now except workspace archlinux

Wayfire doesn't have IPC does it?

Doesn't have, and they may use dbus WayfireWM/wayfire#49

Yeah, so support can't be added, unless wayfire also supports the unfinished workspaces protocol, which would also require support for it to be added here.