Open DavidLyhedDanielsson opened 2 years ago
Are there any logs that occur when you change the thickness value? My assumption would be that the calculated value is somehow malformed (i.e. too big? idk). Generally, changing the thickness value, if everything works, should definitely trigger a redraw as usual - you can verify that by simply setting a direct variable for thickness and changing that manually
Also having this issue.
; ~/.config/eww.yuck
(defvar thickness "10")
(defwidget circle []
(circular-progress
:class "ram-circle"
:value "100"
:thickness {thickness}
)
)
(defwidget bar []
(centerbox
(label :text "1")
(circle)
(label :text "3")
)
)
(defwindow bar
:monitor '["<primary>", 1, 0]'
:geometry (geometry
:y "0.5%"
:x "0%"
:anchor "bottom center"
:width "90%"
:height "0%"
)
:exclusive true
(bar)
)
$ eww open bar
$ eww update thickness=50
$ eww update thickness=0
$ eww update thickness=5
These updates will seemingly not do anything, but if you check with $ eww debug | less +/thickness
, it will show that the variable did actually change, it's just that the widget will not change accordingly. Unless if you change it in the yuck file, then it'll work as expected.
It seems that the widget only goes off the initial value itself, not the current one. This can be confirmed by also checking in $ eww debug | less +/initial_variables
, the widget's thickness will correspond to the initial value instead of the current.
I also checked the logs, and I'm getting no errors.
Tested on archlinux, with eww 6.0, built from the AUR package.
Checklist before submitting an issue
Description of the bug
I'm hackishly using the thickness of a circular widget to create a CPU usage widget as such:
I was experimenting with a python script which runs
eww update cores=[1,2,3,4,5,...]
and noticed that the the widget doesn't update until theclass
property changes. Thecores
variable is correctly set, as verified byeww get cores
.As a workaround, I can set the value property to
{cores[entry] * 0 + 100 / 12}
and it works as expected.Same thing happens with the builtin
EWW_CPU.cores[entry].usage
.Another question is of course: Is there a reason why the thickness does not trigger an update other than unexpected behaviour?
Reproducing the issue
Use the yuck above combined with this:
and run something like:
eww update "cores=[0, 10, 20, 30, 40, 50, 60, 70, 80, 90, 100, 0]"
and it should update since some cores will use thecorehigh
class. Now run:eww update "cores=[0, 10, 20, 30, 40, 50, 60, 70, 80, 80, 80, 0]"
and it should, once again update since all the cores now use thecorelow
class.Finally, run
eww update "cores=[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]"
and it does not update unless the workaround is appliedExpected behaviour
I expect
thickness
to trigger a widget redraw/updateAdditional context
No response