window-list: disconnect scale_factor signal on destroy (fixes SIGSEGV on window close)

[borisi1]

Since 25d9879 (window-list icon-size), wf-panel crashes with SIGSEGV when a window closes — e.g. restarting an application.

The scale_factor signal connection added in that commit is the only connection in WayfireToplevel::impl that is not stored in the signals vector. Every other connection is stored and disconnected in the destructor:

for (auto signal : signals)
    signal.disconnect();

Because this one is untracked, it is never disconnected. When the toplevel is destroyed, the button's scale_factor property still changes during teardown and fires on_scale_update() on the freed object → set_app_id() → IconProvider::image_set_icon() on a destroyed Gtk::Image, crashing inside the GTK4 CSS/style chain.

Fix: store the connection in signals like all the others so it is cleaned up with them.

Reproduce: launch a GUI application, then close/restart it — wf-panel crashes. With this patch the panel survives repeated open/close cycles.

[trigg]

It seems odd to me that this doesn't cause a crash on any of my machines.

That aside, this fix is still the correct thing to do, even if I can't reproduce the crash.

Thank you for the PR!

[borisi1]

I found it with manual restart of an app but the following script should catch it as well:

pid=$(pgrep -x wf-panel)
if [ -z "$pid" ]; then
echo "wf-panel is not running — start the panel first."
exit 1
fi
echo "panel PID: $pid"

app=${1:-konsole} # pass another GUI app as $1 if you prefer, e.g. ./script.sh alacritty

for i in $(seq 30); do
"$app" &
k=$!
sleep 0.4
kill "$k" 2>/dev/null
sleep 0.3
if ! kill -0 "$pid" 2>/dev/null; then
echo "❌ PANEL DIED on iteration $i"
exit 1
fi
done