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
swaymsgDocumentation: i3 bar display modes,
sway-bar(5)Quickstart
Prerequisites:
$XDG_CONFIG_HOME/config/waybaris a JSON object)swaybar_command waybarConfiguration
"ipc": trueto the waybar configurationmode,hidden_stateandmodifierin the same bar configuration block asswaybar_commandbar-0to the only bar instance and run waybar as/usr/bin/waybar -b bar-0bar-0provided via commandline argument and get the initial configurationswaymsg bar mode <mode> bar-0,swaymsg bar hidden_state <show|hide> bar-0(note the trailingbar_idsyntax)Multiple bars
Your
$XDG_CONFIG_HOME/config/waybaris a JSON array with multiple bars defined.ipcoption to the corresponding config block. It will default to disabled.idfrom sway config (the one specified in thebarconfig 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 theidin the waybar config for the corresponding bar instance ("id": "bar-1") and then use this identifier for theswaymsgcommand invocation:swaymsg bar mode hide bar-1Example configuration:
$XDG_CONFIG_HOME/sway/config
$XDG_CONFIG_HOME/waybar/config
The
bar_idparameter is required for IPC subscription.Test commands (note the trailing
bar_idsyntax.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-0or to take the first entry fromget_bar_configresult if it's not set explicitly?bar-0is 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.setVisibleshould be controlled either via signals or via IPC. Allowing both at the same time makes things messy and inconsistent.setVisiblewas changed to switch betweeninvisibleanddefaultmodes. 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: