-
-
Notifications
You must be signed in to change notification settings - Fork 733
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Yet another swaybar ipc implementation #1244
Conversation
Implement a wrapper over Glib::Dispatcher that passes the arguments to the signal consumer via synchronized `std::queue`. Arguments are always passed by value and the return type of the signal is expected to be `void`.
Add a fixture for writing tests that require interaction with Glib event loop and a very basic test for SafeSignal.
Use `mode` (`waybar::Bar::setMode`) as a shorthand to configure bar visibility, layer, exclusive zones and input event handling in the same way as `swaybar` does. See `sway-bar(5)` for a description of available modes.
8edaf91
to
7f9e8a6
Compare
7f9e8a6
to
c503f06
Compare
This allows to apply the mode atomically and adds possibility of defining custom modes (to be implemented).
Read `layer`, `exclusive`, `passthrough` into a special mode "default". Drop `overlay` layer hacks, as it's easier to use `"mode": "overlay"` for the same result.
3108edf
to
5786a27
Compare
I just tested this one and it looks and works great! I used the following config:
This works as the expected behavior from sway-bar. Many thanks for that! If I could make a wish, I would love to be the bar visible if there is no other window on the screen. Is this possible with your custom mode configuration overrides? |
Something like
The behavior here is copied from swaybar and fully controlled by sway config. |
I testes this, but it doesn't work like #1241. The |
Are you sure you assigned correct bar ids and modes? Check example configs in the pr description; with this configuration it should toggle only the second bar. Also, there's a bug in sway that makes |
5786a27
to
137f854
Compare
@somini the PR description now documents the feature, the configuration and the expected behavior. Let me know if you still have problems or if you have any suggestions for making it easier to set up. |
@alebastr Thanks, I re-read the docs and now I understood. Here's my setup (same test as #1241).
Sway:
Waybar:
I see that #1241 was abandoned in favour of this, can confirm this works well too. |
LGTM, except one comment.
Assuming bar-0 will be good enough for me |
Try to use the default bar id (`bar-0`) if none is set.
2c9b7ed
to
549b2a1
Compare
Rebased, added default bar id and connection error handling. |
Intermittent CI failures without any useful diagnostics could be caused by the OOM killer. 1024MB is not really enough to run 3 parallel jobs with a modern C++ compiler.
Allow changing existing modes and adding new ones via `modes` configuration key. `modes` accepts a JSON object roughly described by the following type ```typescript type BarMode = { layer: 'bottom' | 'top' | 'overlay'; exclusive: bool; passthrough: bool; visible: bool; }; type BarModeList = { [name: string]: BarMode; }; ``` and will be merged with the default modes defined in `bar.cpp`. Note that with absence of other ways to set mode, only those defined in the `sway-bar(5)`[1] documentation could be used right now. [1]: https://github.com/swaywm/sway/blob/master/sway/sway-bar.5.scd
d62bc66
to
b6d0a4b
Compare
This feature makes waybar a client for the Sway bar IPC protocol and allows controlling some aspects of the bar behavior with
swaymsg
Documentation: i3 bar display modes,
sway-bar(5)
Quickstart
Prerequisites:
$XDG_CONFIG_HOME/config/waybar
is a JSON object)swaybar_command waybar
Configuration
"ipc": true
to the waybar configurationmode
,hidden_state
andmodifier
in the same bar configuration block asswaybar_command
bar-0
to the only bar instance and run waybar as/usr/bin/waybar -b bar-0
bar-0
provided via commandline argument and get the initial configurationswaymsg bar mode <mode> bar-0
,swaymsg bar hidden_state <show|hide> bar-0
(note the trailingbar_id
syntax)Multiple bars
Your
$XDG_CONFIG_HOME/config/waybar
is a JSON array with multiple bars defined.ipc
option to the corresponding config block. It will default to disabled.id
from sway config (the one specified in thebar
config block withswaybar_command waybar
) - add only"ipc": true
. Sway will pass the bar_id and the bar instance will use that value.id
(i.e. you have two bar configuration blocks in the sway config), set theid
in the waybar config for the corresponding bar instance ("id": "bar-1"
) and then use this identifier for theswaymsg
command invocation:swaymsg bar mode hide bar-1
Example configuration:
$XDG_CONFIG_HOME/sway/config
$XDG_CONFIG_HOME/waybar/config
The
bar_id
parameter is required for IPC subscription.Test commands (note the trailing
bar_id
syntax.bar <bar-id> mode ...
is broken in sway and will modify config for all the defined bars - swaywm/sway#6680):Non-blocking issues:
Defaults for
bar_id
- do we want to assumebar-0
or to take the first entry fromget_bar_config
result if it's not set explicitly?bar-0
is assumed if no other value is passed. The swaybar IPC client will try to get the initial configuration for the bar_id and disable itself if the sway config does not have the bar with that id.setVisible
should be controlled either via signals or via IPC. Allowing both at the same time makes things messy and inconsistent.setVisible
was changed to switch betweeninvisible
anddefault
modes. That addressed most of the problems, the only remaining is to remember the last visible mode and use it instead of thedefault
.Copy/move optimizations for SafeSignal
D-Bus method for changing mode or visibility when sway IPC is not available (but definitely not in this PR)
Support for custom modes/mode configuration overrides;
example: