Run without sway about ironbar HOT 34 CLOSED

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

from ironbar.

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

from ironbar.

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

from ironbar.

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

from ironbar.

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

from ironbar.

I tested in wayfire, it support now except workspace
archlinux

from ironbar.

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.

from ironbar.

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!

from ironbar.

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!

from ironbar.

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

from ironbar.

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

from ironbar.

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

from ironbar.

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!

from ironbar.

Great progress! Can't wait for full support!

from ironbar.

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.

from ironbar.

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.

from ironbar.

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.

from ironbar.

Yeah thats how it should be done!

from ironbar.

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?

from ironbar.

Doesn't open

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: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h05919756fef3461f
      at <unknown source file>:<unknown line>
  10: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h4987e99dd62068a7
      at <unknown source file>:<unknown line>
  11: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::hf31b4c41a592f1e8
      at <unknown source file>:<unknown line>
  12: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h7da629fd7657bb3d
      at <unknown source file>:<unknown line>
  13: std::thread::local::LocalKey<T>::with::h41d1f7ba92474673
      at <unknown source file>:<unknown line>
  14: tokio::park::thread::CachedParkThread::block_on::h9d696311f351feff
      at <unknown source file>:<unknown line>
  15: tokio::runtime::handle::Handle::block_on::h08591b114eab6b5d
      at <unknown source file>:<unknown line>
  16: tokio::runtime::enter::exit::h94fd083791e0bdce
      at <unknown source file>:<unknown line>
  17: tokio::runtime::scheduler::multi_thread::worker::block_in_place::hb3e5015292147077
      at <unknown source file>:<unknown line>
  18: <ironbar::modules::workspaces::WorkspacesModule as ironbar::modules::Module<gtk::auto::box_::Box>>::spawn_controller::hc99723603e4e8cb9
      at <unknown source file>:<unknown line>
  19: ironbar::bar::add_modules::hce6abb4336c8e147
      at <unknown source file>:<unknown line>
  20: ironbar::bar::create_bar::h8f4116077ad20c08
      at <unknown source file>:<unknown line>
  21: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h226fe8e8312e4b75
      at <unknown source file>:<unknown line>
  22: std::thread::local::LocalKey<T>::with::h9192df796939cc66
      at <unknown source file>:<unknown line>
  23: tokio::park::thread::CachedParkThread::block_on::hb1d4ea8b0205ef49
      at <unknown source file>:<unknown line>
  24: tokio::runtime::handle::Handle::block_on::h20203de41fc3dea0
      at <unknown source file>:<unknown line>
  25: tokio::runtime::enter::exit::h61e669521ce6f409
      at <unknown source file>:<unknown line>
  26: tokio::runtime::scheduler::multi_thread::worker::block_in_place::h5632fbba6c484958
      at <unknown source file>:<unknown line>
  27: <O as gio::auto::application::ApplicationExt>::connect_activate::activate_trampoline::ha6554fc4c3946ece
      at <unknown source file>:<unknown line>
  28: g_closure_invoke<unknown>
      at <unknown source file>:<unknown line>
  29: g_signal_emit_valist<unknown>
      at <unknown source file>:<unknown line>
  30: g_signal_emit<unknown>
      at <unknown source file>:<unknown line>
  31: g_application_run<unknown>
      at <unknown source file>:<unknown line>
  32: <O as gio::application::ApplicationExtManual>::run_with_args::h331634c7871cb578
      at <unknown source file>:<unknown line>
  33: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h40cf4dbf09a0680d
      at <unknown source file>:<unknown line>
  34: std::thread::local::LocalKey<T>::with::h8575ab078cb14c73
      at <unknown source file>:<unknown line>
  35: tokio::park::thread::CachedParkThread::block_on::h76a1d49c024562f8
      at <unknown source file>:<unknown line>
  36: tokio::runtime::scheduler::multi_thread::MultiThread::block_on::hc865733a62c9d202
      at <unknown source file>:<unknown line>
  37: tokio::runtime::Runtime::block_on::h4509df460ce7e0e1
      at <unknown source file>:<unknown line>
  38: ironbar::main::ha7f6c29b79275860
      at <unknown source file>:<unknown line>
  39: std::sys_common::backtrace::__rust_begin_short_backtrace::ha6f017eed1811fac
      at <unknown source file>:<unknown line>
  40: std::rt::lang_start::{{closure}}::h9b65f9fe3470925a
      at <unknown source file>:<unknown line>
  41: core::ops::function::impls::<impl core::ops::function::FnOnce<A> 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<unknown>
      at <unknown source file>:<unknown line>
  51: __libc_start_main<unknown>
      at <unknown source file>:<unknown line>
  52: _start<unknown>
      at /build/glibc/src/glibc/csu/../sysdeps/x86_64/start.S:115

Run with COLORBT_SHOW_HIDDEN=1 environment variable to disable frame filtering.

from ironbar.

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.

from ironbar.

Strange i removed it from my config

from ironbar.

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.

from ironbar.

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.

from ironbar.

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..

from ironbar.

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.

from ironbar.

👍

from ironbar.

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

from ironbar.

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

from ironbar.

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

from ironbar.

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.

from ironbar.

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

from ironbar.

I tested in wayfire, it support now except workspace archlinux

Wayfire doesn't have IPC does it?

from ironbar.

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
WayfireWM/wayfire#49 (comment)

from ironbar.