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
Don't immediately ASSERT when the hyprland socket operations fail.
Instead, retry them a few times and then return gracefully instead of
crashing.
https://github.com/scorpion-26/gBar/issues/32
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
Previous default value of date creates null option in gBar config and
crashed the bar, removes null as accepted option in SNIIcon* options as
that also crashes the bar. I also felt like documentation lacked so
wrote this.
Add a way to write the gBar configuration in the nix language, like many
other home manager modules, this spares, atleast nix users, from the
trouble of using a new config language and integrates it nicer into
existing home manager configs.
Giving each main box element (left, center, right) caused the window to
resize and clip out of the monitor when
e.g. the right part was larger than the 1/3 of the window.
Now we have a size for the center widget and try to manually center a box with
that size by setting the left widget's size accordingly. This allows the
right widget to have more room, so it can go right up to the center widget without issues.
For it to actually do something, we need to click twice within 2s. The
clicked button also changes color for visual indication on what was
pressed
See https://github.com/scorpion-26/gBar/issues/17
