[FEATURE] Way to utilize magic vars generically?

[Animeshz]

Description of the requested feature

The magic vars is basically a json structure with no standard keys, for instance the EWW_NET and EWW_DISK gives few similar objects of different interfaces and different partitions, but they can't be used without hardcoding particularly to the system-specific thing... Maybe a shell script interfereing in between or few more extension to s-expr be helpful, like looping through key-value or just key or just value, mapping to particular key of each in an array, take max/min (useful for EWW_NET), take sum maybe etc.

Proposed configuration syntax

Unsure, lets discuss?

Additional context

-

[legendofmiracles]

There were for loops already-before the s-expr, not sure how they work out now that the syntax changed.

[elkowar]

@legendofmiracles there weren't 🤔

Generally, while I understand the desire for more abstraction, the only real "solution" here would be to add a jq like engine into eww - which feels like it would drastically increase the complexity of eww again. Not for the implementation side necessarily (although probably), but also usage-side. Currently, I see relatively little need for this, as in 99% of cases one is making a widget for themselves, hard-coded to one system. Do you have any concrete examples where that higher level of abstraction would drastically increase the quality of a configuration?

[Animeshz]

True, we can potentially poll for lsblk or ip link show to get required interfaces for these 2 magic var, this might be a topic for future if more variables with more complexity comes in.

I'd just like to pass the var or its indexing to a shell script and receive output instead of increasing complexity of yuck/s-expr to have imperative language capability while their main purpose is just to declare the fields & tree of data. I guess this can work if we can pass s-expr instead of only literal values in the command of defpoll...

I'd rate this as low-priority issue.

[elkowar]

I might consider a pipe function or something in simplexprs, that would allow passing values through a shell pipeline. If that existed, you could make use of jq directly, by running sth like pipe(EWW_DISK, "jq 'whatever'"). Would this work for your usecases?

[Animeshz]

If we can awk or sed probably most of the text based manipulations can be done easily as well.

+1, perfect idea!

Edit: vararg pipes can also be useful, seems like the s-expr already supports var-args (collects args into vec).

[Th3Whit3Wolf]

@legendofmiracles there weren't 🤔

Generally, while I understand the desire for more abstraction, the only real "solution" here would be to add a jq like engine into eww - which feels like it would drastically increase the complexity of eww again. Not for the implementation side necessarily (although probably), but also usage-side. Currently, I see relatively little need for this, as in 99% of cases one is making a widget for themselves, hard-coded to one system. Do you have any concrete examples where that higher level of abstraction would drastically increase the quality of a configuration?

Actually there is already a rust version of jq called jql. It would be be pretty easy to add to eww as the project is one library with a 143 lines bin.rs. It's also on crates.io here.

[jokeyrhyme]

My current workaround is the parameterise the machine-specific parts, and use the :visible property with an expression: https://gitlab.com/jokeyrhyme/dotfiles/-/blob/main/config/eww/eww.yuck

e.g.

(defwidget battery [id]
  (box :class "battery" :orientation "h" :space-evenly false :halign "end" :tooltip "battery ${id}" :visible {!!EWW_BATTERY[id].capacity}
    "🐇${EWW_BATTERY[id].capacity}%"))

(defwidget sidestuff []
  (box :class "sidestuff" :orientation "h" :space-evenly false :halign "end"
    ...
	(battery :id "BAT0")
	(battery :id "BAT1")
    ...))

So, even if not all of my machines have a BAT0 or BAT1, my config includes both, and hides whatever is not available

[elkowar]

After yeeeeeeears of waiting, I now added a jq function via the jaq crate in #695! I still think a generic pipe function would be an interesting idea, but having built-in jq-style processing definitely seeeeeeems quite reasonable. I'm wondering if how feasible it might be to simply use a jq implementation as a general replacement for simplexpr... 🤔