blob: cb195c6e73b9728e887f7bb296a2768fdab3b2ce (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
|
#+TITLE: Waybar Expansion Animation — Feasibility Assessment
#+AUTHOR: Craig Jennings
#+DATE: 2026-07-02
* Question
The todo.org task "Smooth waybar expansion animation" [#C]: the collapse/expand
jump is abrupt, and a few systray icons pop in one-by-one afterward. Can the
expansion animate smoothly?
* How the collapse actually works
=waybar-collapse= rewrites the module arrays in a runtime copy of the config
(=$XDG_RUNTIME_DIR/waybar/config=) and sends waybar SIGUSR2. Waybar reloads:
it tears down every module widget and rebuilds the bar from the new config.
* Findings
1. *No widget survives the reload, so nothing can transition.* GTK3 CSS
transitions animate property changes on live widgets. The collapse
mechanism replaces the whole widget tree; there is no widget on both sides
of the change to interpolate. The jump is structural, not stylistic.
2. *GTK3 doesn't animate widget add/remove anyway.* Smooth insert/remove needs
=GtkRevealer= wrapping, which waybar does not use for modules. Making it do
so is an upstream waybar patch, not a config or CSS matter.
3. *The layer surface resize isn't animatable either.* Hyprland layerrules can
animate map/unmap (slide/fade), but the bar stays mapped through a collapse
— the same surface changes width. No compositor-side hook exists for that.
4. *A CSS-only fake covers custom modules at best.* Custom modules could emit
a "collapsed" class and transition font-size/padding toward zero (GTK3 CSS
can animate those). But the collapsed set includes built-ins — tray,
pulseaudio, workspaces — which take no script-driven classes. The result
would be half the modules gliding and half popping: worse than the clean
jump.
5. *Tray icons popping in one-by-one is separate and unfixable here.* That's
asynchronous StatusNotifier re-registration after the reload; each app
answers on its own schedule. Only keeping the tray alive across the change
(i.e. not reloading) avoids it.
* Conclusion
Not feasible with the current collapse mechanism, and no acceptable partial
measure exists. A real animation requires waybar itself to support dynamic
module sets with Revealer-style transitions (an upstream feature), or
replacing the collapse-by-reload design entirely.
* Recommendation
Close the task as infeasible-for-now (or park at [#D] with a pointer here).
Revisit only if waybar upstream gains dynamic module visibility (worth a
check at major waybar releases) or if the bar ever migrates to a custom
GTK4 shell — the Blueprint pipeline from the net panel would make Revealer
transitions natural there.
|
