g_variant_iter_n_children apparently returns 1 instead of 3 (array =
child, but I don't know).
I inverted the statement, because for empty property, it hasn't any
children.
TeamViewer exposes ToolTip as String (which is not compliant to the spec).
This caused gBar to crash, since we assume, that the tooltip variant is
always a container (struct), which glibc doesn't like.
We now fallback to g_variant_get_string if it is not according to spec
Fixes https://github.com/scorpion-26/gBar/issues/37
Some apps have a tendency to deadlock after registration (notably
KeePassXC). Now we flush before querying the item properties, so any
pending answer should have left the bus, hopefully avoiding the deadlock
ItemPropertyChanged is called multiple times per actual icon change.
senderName is the same, objectPath is the same, but our registered name
for the callback differs.
We can't use the provided name for item searching, since that *can*
differ from the one we registered with (Looking at you, Discord. Discord
registers with org.kde.StatusNotifierItem-*, but calls back with :*.*)
Since then the object path will sometimes be wrong for the name, we just
use the one from the icon we originally registered with. This causes
multiple icons to reload though
Potential fix for https://github.com/scorpion-26/gBar/issues/26
Implements a rough outline of the SNI (StatusNotifierItem) d-bus
protocol for tray icons.
Note: This is currently *very* WIP
Full implementation will close https://github.com/scorpion-26/gBar/issues/5
