systray: add :visible-empty property for systray widget

[vnva]

Description

Issue

Added the :visible-empty property for the systray widget. By default, an empty tray is displayed.

I also noticed a problem that tray elements are not removed from systray.items.

Usage

(systray :visible-empty false)

Showcase

2024-05-05.22-14-11.mp4

Additional Notes

This is my first time writing in rust, so I might have made mistakes, please check carefully to see. I'm ready to correct mistakes.

As far as I understand, the documentation for widgets is generated automatically.

Checklist

Please make sure you can check all the boxes that apply to this PR.

• All widgets I've added are correctly documented.
• I added my changes to CHANGELOG.md, if appropriate.
• The documentation in the docs/content/main directory has been adjusted to reflect my changes.
• I used cargo fmt to automatically format all code before committing

[vnva]

Most likely this is not the best solution, I think it’s worth passing a condition on the number of elements in the tray in :visible, you don’t have to merge this PR. But it’s certainly worth fixing removing elements from the tray. This also conflicts with the :visible property.

[vnva]

@jlo62, i wrote a stupid script to count the number of elements in the tray, you can use it together with deflisten and :visible

#!/bin/bash

count=0

dbus-monitor --session "interface='org.kde.StatusNotifierWatcher'" |
while read -r signal; do
    if [[ $signal == *"StatusNotifierItemRegistered"* ]]; then
      count=$(($count + 1))
    elif [[ $signal == *"StatusNotifierItemUnregistered"* ]] then
      count=$(($count - 1))
    fi

    echo $count
done

(deflisten systray-items-count :initial 0 "path-to-script")
(systray :visible "${systray-items-count > 0}")

[vnva]

@elkowar, perhaps this method should be added to the docs or add a magic variable with the number of elements in the systray. Perhaps it’s generally worth disabling the widget’s display by default if there are no elements in it.

[w-lfchen]

i think adding a magic var would be a lot nicer, but i'd have to investigate whether this is difficult from an architectural standpoint.

since there has been little activity on this pr, do you mind me adopting it?
i'd then see where i can take this idea (i'd probably attempt to implement a magic var since that's far more flexible)