[FEATURE] pipe yuck into eww commands about eww HOT 3 OPEN

After looking a bit more, I realize that this feature has already been suggested, but only in the context of providing options for window creation. The implementation I describe would allow entire configs to be passed when invoking eww open without writing a config to the disk.

from eww.

I don't really understand the use case here that you can't already do with literals. I feel like a literal is pretty much the same thing, even. A literal is just going to display whatever the command/script returns as if it was yuck, and as long as you're listening to that script it'll update whenever the script changes.

I mean, what would you be able to do with this that you can't with a literal?

Plus, I'm not so sure if I agree with literals being hard to style. You define what classes a given widget is going to have when you make a literal script. And if you're still having difficulties you can always launch the inspector and play around.

from eww.

I suppose you're right. However, If I wanted to generate any possible window configuration controlled by some other backend, I couldn't just use a literal that pulls from window arguments, as the documentation made it abundantly clear that those are constant and unchanging.

In order for me to pass dynamic content to these "meta-windows" I'd need to pass the NAME of a listener that pulled JSON data from somewhere and have the yuck use it as a call to a variable.

Last I checked that only half worked. Either you'd be able to pass the name but unable to get its value, or you'd pass the value and be unable to get the corresponding NAME to use in eww commands that set its value. But none of this matters if you can't generate and include temporary configurations that store those variables.

Plus, without any way to define variables within a window in terms of scope, and without any real means of introspection, it's not as if I could use the ID of the window as a prefix for a local variable.

In addition to all this, literals have a not insignificant performance impact. Previously I got around this with a bash script that could write configs and JSON to temp files, but that solution was not very pretty and was bound to cause wear on the disk.

from eww.