Waybar: Only show waybar when modifier key is pressed

[vially]

Is there any way to configure sway/waybar so that it behaves similar to i3's mode hide?

Sway already supports mode hide for their swaybar. I was wondering if it would be possible to implement the same for waybar?

Basically what I'm looking for is having this sway configuration work as expected:

bar {
  mode hide
  swaybar_command waybar
}

[rif]

This is the feature that I'm also waiting for to be able to make the switch to waybar, great tool!

[toger5]

Would be great to have that feature!

[toger5]

Seems like there is already some kind of hide functionality built in the code (the toggle function).
It probably just needs to listen to some kind of sway events.
See the main function:
https://github.com/Alexays/Waybar/blob/67593b8c0fb9fe9e51eb99b9bc578e0c280b4c5f/src/main.cpp#L8
It seems that there is a USRSIG which is used for the toggle.
I tired with a little c program

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <signal.h>

int main(void)
{
    kill(/*the Pid*/, SIGUSR1);
}

and the bar actually gives the space to the compositor.

[toger5]

Also this is realted to #157.
Basically the c program i posted is eqivalent to killall -SIGUSR1 waybar which can be bound to some shortcut. But it is still not possible to toggle when holding $mod.

[xPMo]

I've been poking around in sway's IPC docs and here's what I've learned. I will use this as an example config:

bar {
    id bar1
    modifier $mod
}

By default, bar1 is started in mode dock. Pressing and releasing $mod sends no events while the bar is in this mode. Now suppose that by a binding or a swaymsg call, that the command bar mode invisible was run. An event of type barconfig_update is sent, the json object sent has fields including "mode": "invisible", and "id": "bar1". Pressing and releasing $mod while the bar is in this mode also sends no events. Similarly for mode "overlay".

Now, if either bar mode hide or (while the bar is in "dock" mode) bar mode toggle is sent, an event of type "barconfig_update" is sent with field "mode": "hide", just like before.

While the bar is in mode "hide", pressing and releasing $mod will send events of type bar_status_update. The objects will be: {"id": "bar1", "visible_by_modifier": [bool]}, where [bool] is true or false.

---

Either:

• the barconfig_update events are ignored, and all users must usebar { mode hide } so that bar { modifier $mod } works consistently, and waybar uses another mechanism to toggle dock/hide mode
• or these bar-mode events are used to control the layer-shell state in a sway-bar compatible way.

There are a number of benefits to the second option:

• in a session with multiple bars, waybar can use its bar ID to identify its state, as opposed to PID
• users don't have to set bar mode hide in their sway config
• being totally ipc-compatible with sway's first-party bar makes it easy to migrate from swaybar.

The downsides to the second option:

• allowing a compositor-specific module to control the visibility/layer-shell properties of waybar is a really deep integration. This would tie waybar down to sway far more than the current sway/mode, sway/workspaces, or sway/window modules do, possibly at the expense of future compositor support.

EDIT: @Alexays, comments on feasibility? Am I off the mark here?

EDIT2: Optimally, https://github.com/swaywm/wlr-protocols/issues/41 would be adopted so waybar can change layers without destroying its surface.

[l3s2d]

Not sure if I'm off the mark here, but another, albeit more complex, option would be to implement a control program for waybar, i.e. waybarctl. This would be useful for a few reasons:

• Allow external programs to interact with waybar while it's running, instead of having waybar rely on polling for everything
• This might address the current issue by doing something like
  
  
  
  • bindsym $key waybarctl show
  
  
  • bindsym --release $key waybarctl hide
  
  

[xPMo]

This might address the current issue by doing something like

• bindsym $key exec waybarctl show
• bindsym --release $key exec waybarctl hide

This works for normal keys, but not modifiers. If you want to bind this to Mod4 (for example), you can use bindsym Super_L exec waybarctl show (and similar with --release). However, while the first gets run consistently when the key is pressed, the --release binding is ONLY run if another shortcut is not run first. So if you have the show/hide bindings as above, running any command (like $mod+l to focus left) will show the bar and not hide it when Mod4 is released.

This can be worked around by having _another_ IPC client which reads the bar_status_update events and then calls waybarctl, but it seems wasteful to attach a whole other process when waybar already has a connected socket.

[nyyManni]

I was playing around with this feature in my fork, and have got it into a shape where it is mostly good enough for my use.

In order to not tie Waybar too much into sway, I created a "meta-module" sway/hide which does not actually have any visible GUI, but just hooks into bar_status_update events from sway and toggles the visibility of the bar accordingly. This way the core of waybar is kept "non-sway-aware". The only thing added to the core was the support for showing the bar in an overlay mode (, which also would solve #491).

There are still problems, though. The biggest one I am facing right now is that when the bar is in overlay mode (on top of tiled windows) and hidden by the gtk style option, the invisible bar still sucks the mouse events from the area. In other words for example the tab bar in my browser is difficult to use with a mouse as the invisible bar covers about 75% of it. (I am still ok with it, as I mostly use keyboard shortcuts anyway, but...)

Ideas on how to solve the invisible overlay stealing mouse clicks would be welcome, as that would make the feature more suitable for daily use.

[xPMo]

@nyyManni Have you tried setting waybar to use the bottom layer?

[nyyManni]

@xPMo I am setting the layer into ZWLR_LAYER_SHELL_V1_LAYER_OVERLAY which is needed as I want to show the bar on top of other clients whenever it is visible. A solution might be to dynamically set the layer to ZWLR_LAYER_SHELL_V1_LAYER_BOTTOM while the bar is hidden, allthough I am not sure if I can modify that attribute without destroying and recreating the surface.

[xPMo]

dynamically set the layer

You can't right now, but there's already an issue for it (swaywm/wlr-protocols#41, I linked it earlier in this thread).

Currently, swaybar destroys its surface instead of changing layers when it hides.

[xPMo]

@nyyManni @all Good news:

wlroots 0.9.0 has been released; the layer shell protocol and wlroots now support changing layer at runtime.

It is now possible for waybar to simply raise its layer on modifier. I like this option, since waybar will always be visible on empty workspaces, or when it is uncovered/partially covered by floating windows. Additionally, it solves the focus-stealing problem @nyyManni mentioned.

However, some may prefer their bar to be completely hidden, even on empty workspaces (like swaybar). A "hide-on-modifier": <bool> option in the module may be useful; setting it to false makes waybar change layer without hiding. If this is supported, a name like "sway/hide" may be misleading; maybe call the module "sway/bar_events".

[nyyManni]

@xPMo indeed!

I already tried it last week (see the referenced commit 5 days ago), and have been using it since.

My solution is a hack, though, and I am having an issue that when I "raise" the bar with the modifier, sometimes the remaining of the screen "jumps back in time" showing an old version of my framebuffer, at least with XWayland clients.

[ghost]

I am wanting to raise the ante' and configure the bar to be say '2px and transparent(or peaking through)' and then when the move hovers over the area, the bar changes height to the full area with whatever styling

I tried using hideIt.sh but couldn't get it to work properly. :/

VV theres also this bit of code in bar.cpp VV
cpp auto waybar::Bar::toggle() -> void { ... ... window.get_style_context()->add_class("hidden") ... }
but I am not quite sure what to do with it. I don't know .. ?

[ghost]

theres also this bit of code ..
auto waybar::Bar::toggle() -> void { ... ... window.get_style_context()->add_class("hidden") ... }
but I am not quite sure what to do with it. I don't know .. ?

[mox-mox]

Hey, is there any progress so far?

[ghost]

Can we not make a modifier/module that contains the entire bar - or
overrides it's settings to turn everything off like a docker.

Essentially just aa waybar container that could be configured to work with
mouse over or hotkeys/keybind?

I would just do this myself but I don't know enough about
programming/Wayland to even know where to start.

On Thu, Aug 27, 2020, 6:09 AM mox-mox [e-mail] wrote:

Hey, is there any progress so far?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Alexays/Waybar/issues/255#issuecomment-681881713, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AKQVPQK3TUKXSUCOFUQPPDTSCY5F3ANCNFSM4HCQ77BA
.

[xPMo]

Hey, is there any progress so far?

I have some work on the feature, but unfortunately it is both old and didn't quite work. My severe inexperience with C++ is the biggest culprit, I have a decent grasp on the wayland/sway side of things.

[somini]

https://github.com/swaywm/wlr-protocols/issues/41 was fixed by https://github.com/swaywm/wlr-protocols/pull/59 apparently, I don't have problem with hiding and showing the bar now, if I send a USR1 to the waybar process.

My use case is having a simple main bar that it's always on, and another more complex one that is only shown when a modifier is pressed, for extra information.

https://github.com/xPMo/Waybar/tree/sway-hide sounds like a good solution that doesn't tie Waybar to sway so much, but provides integration, particularly with more than one bar.

I tweaked the code by trying to reuse the toggle function, and I get some segfaults if I toggle it too rapidly (I also don't know enough C++, might be something on my side). It seems that if a toggle operation is triggered while the previous operation is happening yet, there's a crash. The code in in #860