Add Auto-Hide feature

[varbhat]

@Alexays ,
I implemented Auto-Hide feature in Waybar. It allows Bar to autohide itself when cursor is no longer over it and makes itself visible when the cursor touches the edge of the screen to which Bar is positioned. It's incredibly useful in Small screen displays. It's working properly for me. I wish to have this merged. It adds three more configuration options to the config.

*autohide* ++
	typeof: bool ++
	default: false ++
	Option to specify whether bar must autohide.
	Use *autohide-delay* and *autohide-starthidden* to customize autohide.

*autohide-delay* ++
	typeof: integer ++
	default: 0 ++
	Time in milliseconds after which the bar must autohide if cursor is no longer over the bar.

*autohide-starthidden* ++
	typeof: bool ++
	default: false ++
	Option to specify whether the bar must start in hidden state if *autohide* option is true.

[varbhat]

Here's the snippet of my config,

  "layer": "top",
  "exclusive": false,
  "position": "top",
  "autohide": true,
  "autohide-delay": 2000,
  "autohide-starthidden": false,

[alebastr]

Have you considered cropping the surface with wp_viewporter instead of introducing an additional hotspot surface?

[varbhat]

@alebastr , I have not used that protocol. But, some alternative bars have followed the additional hotspot surface method to implement auto-hide. Is there any disadvantage of using additional hotspot surface? For me, it's working properly.

[alebastr]

@alebastr , I have not used that protocol. But, some alternative bars have followed the additional hotspot surface method to implement auto-hide. Is there any disadvantage of using additional hotspot surface? For me, it's working properly.

Interaction between two exclusive layer surfaces anchored to the same edge of the screen is a compositor-defined behavior. I.e. you shouldn't expect any specific behavior, especially the one you consider correct.

[varbhat]

@alebastr ,Please review now.

[varbhat]

@alebastr @Alexays , does this PR look good?

[alebastr]

Sorry, I'll return to review this weekend. Busy week at work :( From a brief look: I don't think last commit fixes compilation with -Dgtk-layer-shell=disabled. Have you tried using setLayer/setExclusiveZone on hotspot surface instead of direct calls to gtk-layer-shell? There's also a WIP branch in my fork where I tried to implement hotspot with a single surface and wp-viewporter. Seems like this could work, but needs some refactoring of surface abstractions.

…

On Wed, Jun 28, 2023, 10:24 Var Bhat ***@***.***> wrote: @alebastr <https://github.com/alebastr> @Alexays <https://github.com/Alexays> , does this PR look good? — Reply to this email directly, view it on GitHub <#2248 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAUOSP63AZMOXAMPE7X5LDLXNRSDRANCNFSM6AAAAAAZOQEQ7E> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[donovanglover]

This is pretty cool and allows waybar to be used on-demand with fullscreen applications. I previously tried to toggle waybar with waycorner but the hot corners would end up behind waybar.

One issue I ran into while using your branch with Hyprland is that the bar appears to be re-drawn every time a different module is hovered over. Another issue is that taskbar icons have different padding when autohiding is enabled.

Is there a way to toggle the autohide feature of waybar while it's running? For example, if you need to click something where the bar would show, is it possible to change the bar from auto-hiding non-exclusive to don't autohide + exclusive?

[varbhat]

@alebastr , Did what you said. It can now compile with gtk-layer-shell disabled. I too experimented with wp_viewporter yesterday but it was segfaulting. I think that wp-viewporter solution brewing in your branch could be better if that works.

[varbhat]

@donovanglover ,

Toggling while running -> Can be done. But, i probably will try to implement it later.
re_drawn -> yeah, it flashes for me too. Maybe show_all is redrawing everything? I need to check that.
different padding -> I didn't face this issue. I need to dive more into this.

Can you look into PR and try to improve it? It mustn't be too difficult.

[varbhat]

@alebastr any updates? also, what can be done with wp-viewporter?

[alebastr]

@alebastr any updates? also, what can be done with wp-viewporter?

Sorry for delay. I've updated my wp-viewporter branch with a working code. Feel free take the first commit as is and use the second one as an example.

The main benefit of viewporter solution, IMO, is that the change applies to the same surface and takes just one Wayland commit. I.e. that's pretty much atomic change with no flickering.

The configuration for fullscreen applications could look like

{
   "mode": "hide", // or "hotspot" to start hidden
   "modes": { // modify builtin modes
     "hide" { "layer": "overlay" },
     "hotspot": { "layer": "overlay", "hotspot": 2 }
   },
   "autohide-delay": 1000 // ms
}

I'm not happy with how that introduces third way to control bar visibility (SIGUSR1, Sway IPC and this), but getting all 3 to work together with sane interaction model requires more refactoring than I have time for :(

Also, not entirely convinced that a dedicated hotspot mode is necessary. It's possible to do "modes": { "invisible": { "hotspot": 1, "layer": "top", "passthrough": false } } to get the same effect. Or apply the changes to bar_.configured_modes[Bar::MODE_INVISIBLE] when autohide is set.

[bretello]

@alebastr I tested your code and it seems to be working fine. As you mentioned, it's a bit confusing to have this many methods for controlling bar visibility, can you elaborate a bit on what the refactoring you were talking about would look like?

[droc12345]

Just tried this on the git version, and it works well.
I'm running hyprland with a top and bottom bar,
where the top is window title, workspace # and music info
and bottom is app names, sensor info, and date/time

I've set the bottom to auto hide and the top to always stay visible.
Working well, so far.

[nightah]

@varbhat and @alebastr was this PR closed because the wp-viewporter branch is the preferred approach or just because this wasn't merged?

This patch seems to not cleanly apply to the current HEAD as changes have been made in the interim. Really keen on this feature though keen to understand what we should be doing?

[varbhat]

@nightah , Although my approach works, wp-viewporter seems to be the best approach to solve this.

• I got an external monitor and thus i don't need autohide feature (it's desirable on small screens like that of laptop)
• I also moved back to just swaybar (not that waybar is bad; it's great btw)

As i no longer need this feature, I've stopped working on this. Someone can pickup where i left (I consider this to be complete) and get this merged or continue with wp-viewporter approach.