search

rayes0 / dotfiles

dotfiles for bash, neovim, tmux, widgets, and more
74 stars 0 forks source link

Error in start-eww #2

Closed GideonWolfe closed 3 years ago

GideonWolfe commented 3 years ago

Sorry to open issues in your personal dotfiles, but these are great and i want this to work as well as possible.

Ever since I've messed with this setup I've been seeing the following error image

Seems there is some sort of syntax error in changetomin().

Looking at the output of start-eww, I occasionally get

./start-eww.sh: line 67: 10#: invalid integer constant (error token is "10#")

rayes0 commented 3 years ago

Hmm weird. I don't know what I was thinking, writing that. For some reason, my shell never showed me the error. The 10# is completely necessary (and wrong), try removing it so the function becomes this:

changetomin() { printf "%d:%02d" "$(($1 / 60))" "$(($1 % 60))"; }

rayes0 commented 3 years ago

Also don't be afraid to open issues! I too, also to improve this as much as possible, and people reporting problems is a great help! Thank you!

GideonWolfe commented 3 years ago

No problem! Changing to the suggested line seemed to fix the error warnings. However I seem to have created a new bug for myself. Now the weather simply won't load (it was working fine earlier).

I'm not sure if this is related, but in eww logs I see

Error while resolving attributes: Got unresolved variable mus_whenplaying while trying to evaluate expression mus_whenplaying
Error while resolving attributes: Got unresolved variable mus_whenplaying while trying to evaluate expression mus_whenplaying
[src/app.rs:187] Error while handling event: sending response from main thread

Caused by:
    channel closed
rayes0 commented 3 years ago

Could you provide the output of eww state | grep mus_whenplaying. This should be either a true or false value, and shouldn't be empty.

GideonWolfe commented 3 years ago

It is indeed set to true

rayes0 commented 3 years ago

Does it change into false if you try to toggle the weather?

GideonWolfe commented 3 years ago

It does. And when I was testing it, I inadvertently got the weather to show up by

rayes0 commented 3 years ago

Try manually sending a SIGUSR2 to the script, and see if anything happens. Also keep eww logs open and see if there is any output:

kill -s USR2 $(cat ${XDG_RUNTIME_DIR}/eww-wrapper.lock)

rayes0 commented 3 years ago

If the weather still doesn't show up, try running eww update mus_whennotplaying=true and see if it shows up then.

GideonWolfe commented 3 years ago

Ok, here's the steps:

┏━━━━━━━━━━━━━━━━━━━━━━━┓
┃Initializing eww daemon┃
┗━━━━━━━━━━━━━━━━━━━━━━━┛

(eww:1515932): Gtk-WARNING **: 12:51:46.089: Theme parsing error: <data>:498:15: Not using units is deprecated. Assuming 'px'.

Seems ok.

Error while resolving attributes: Got unresolved variable mus_whenplaying while trying to evaluate expression mus_whenplaying
Error while resolving attributes: Got unresolved variable mus_whenplaying while trying to evaluate expression mus_whenplaying
[src/app.rs:187] Error while handling event: sending response from main thread

Caused by:
    channel closed
GideonWolfe commented 3 years ago

Fixed by removing the animations I tried adding earlier... No wonder why the error just showed up. I guess the 1s delay was messing stuff up?

rayes0 commented 3 years ago

Yeah, I'm not really sure. Unfortunately the animations supported by pure GTK+ CSS are very limited, basically to only fading things in and out when the window is initially opened.

GideonWolfe commented 3 years ago

Gotcha. I can deal with that.

Another question I had was about opening terminals. For example when cmus isn't running and I start eww, clicking the "click to start" button should work.

In eww-prefs, I have

term_command='alacritty -e'

In eww logs, I get

WARNING: command alacritty -e cmus timed out

whenever I try to "click to start". It just pops open a terminal that instantly closes.

Running alacritty -e cmus or alacritty -e cmus & in my terminal works fine, and opens a cmus window as expected.

Somewhat related, but when I have the window open and cmus isn't running, even though the UI reflects this and gives me a launch button, I still see errors about unresolved values. It doesn't break anything, but it's still there.

Error while resolving attributes: Got unresolved variable mus_status while trying to evaluate expression mus_status
Error while resolving attributes: Got unresolved variable mus_song while trying to evaluate expression mus_song
Error while resolving attributes: Got unresolved variable mus_album while trying to evaluate expression mus_album
Error while resolving attributes: Got unresolved variable mus_artist while trying to evaluate expression mus_artist
Error while resolving attributes: Got unresolved variable mus_position_min while trying to evaluate expression mus_position_min
[src/eww_state.rs:34] Error while updating UI based after state change: couldn't convert "" to f64: cannot parse float from empty string

When I have the window open. It seems to be looking for cmus attributes even though it isn't running.

rayes0 commented 3 years ago

Alright, I pushed some commits which should fix the issue with the terminal. I tested it with alacritty -e and it seems to work.

As for the unresolved values, it's probably because of this. It used to be that I relied on the value of the status variable to determine what items to show, by now that I directly get the value from pgrep cmus, there doesn't need to be an extra call anymore. I will push a commit in the very near future to fix this.

GideonWolfe commented 3 years ago

That works! I'm sure that script can be modified to behave like startterm and take an arbitrary program as an argument. I'm planning on making a little program launcher, so that will come in handy.

rayes0 commented 3 years ago

Yeah it for sure could, but currently, cmus is actually the only program that makes use of the setting. If I add more startable terminal programs in the future, I will have to modify the script to take the program as an argument.