elkowar / eww

ElKowars wacky widgets
https://elkowar.github.io/eww
MIT License
9.42k stars 382 forks source link

[BUG] changes to circular-progress thickness does not update widget #572

Open DavidLyhedDanielsson opened 2 years ago

DavidLyhedDanielsson commented 2 years ago

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:

(defwidget core [entry]
  (circular-progress
    :value {100.0 / 12.0}
    :start-at {entry * (100.0 / 12.0)}
    :thickness {(cores[entry] / 100.0) * 8}
    :class {cores[entry] > 80 ? "corehigh" : "corelow"}
    :clockwise true
  )
)

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 the class property changes. The cores variable is correctly set, as verified by eww 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:

(defwidget coreusage []
  (box
    :width 25
    (overlay
      (label :text "" :class "core" :halign "center" :valign "center")
      (core :entry 0)
      (core :entry 1)
      (core :entry 2)
      (core :entry 3)
      (core :entry 4)
      (core :entry 5)
      (core :entry 6)
      (core :entry 7)
      (core :entry 8)
      (core :entry 9)
      (core :entry 10)
      (core :entry 11)
    )
  )
)

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 the corehigh 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 the corelow 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 applied

Expected behaviour

I expect thickness to trigger a widget redraw/update

Additional context

No response

elkowar commented 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

0x1d8 commented 4 months ago

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.