Something notable about eww is that it's configured in a lisp language, as opposed to a more traditional XML and CSS: https://elkowar.github.io/eww/configuration.html

Note that this is primarily a syntactical choice -- there isn't _currently_ much in the configuration language that actually resembles the functionality from regular lisp languages. I've been thinking quite a bit about how I could make use of the s-expression based syntax to turn yuck into a more feature-rich, actual lisp language, without completely going out-of-scope ^^

I saw the Janet language mentioned a few times on HN recently and it looks like a nice flavor of lisp that’s also embeddable. Maybe that would be useful for EWW?

I haven’t used Janet much other than going through the beginning of this book here, but here’s the link to a good book and the Rust bindings of you want to check it out.

A really good (and free!) book on Janet: https://janet.guide/

And the Rust bindings: https://docs.rs/janetrs/latest/janetrs/

I've been following eww's development on the sidelines for a while. I wondered if you considered making it callable as a library, for some scripting language (e.g. python or lua or something), rather than growing your own bespoke language? To me it seems you risk people demanding more and more features in the "configuration language", and it turns into a (bad) fully Turing complete programming language before you notice. Like in the configuration complexity clock[1].

[1] http://mikehadlow.blogspot.com/2012/05/configuration-complex...

I've definitely considered it, and I do see the points of yuck either becoming a bad, turing complete lisp, or being just,... not powerful enough. However, I have two main counterpoints to the idea of turning it into a library for some scripting language like lua:

- The original goal of eww was to be two-dimensional polybar with support for full visuals and CSS, rather than just colored text. This means that my target audience, at least initially, was also more the polybar crowd than the awesomeWM crowd. Eww aims to be usable without really needing to know how to program, and aims to provide declarative UI description language that reduces complexity of state management and logic as much as possible. This is, arguably, a goal I've at least somewhat reached -- primarily given the fact that eww DID grow quite fast, and did enable lots of people to do more interesting UI designs than other projects (such as AwesomeWM) did. "Widgets for everyone" is a tagline I don't wanna leave, and thus requiring users to do full-on scripting is not something I'd wanna do easily.

- if you remove yuck and it's state management architecture from eww, you'll be left with quite little. Thus, there would at that point be little added value over existing GTK wrappers. The thing that makes eww appealing (at least IMO) is that it does simplify lots of the most commonly needed things down to a very simple state and UI structure, and provides a great iteration-cycle with great error messages. This would be very hard to keep when turning it into a regular, more imperative library

It should have a debugging console called barf.

After a long period with Polybar, I tried Eww for 3 months.

The features and the visual results are impressive. I wrote 400 lines of configuration and about ten scripts for it but in the end the instability chilled me.

Sometimes tooltips refuse to display, windows open in duplicate or refuse to close, the logs indicate json errors without any apparent reasons or consequences.

I will come back to see the progress in a few months.

Since then I tried i3status-rust, there are less possibilities visually but the same interactive features and its really fast stable.

Disappointed this isn't related to `M-x eww`.

this is what I'm here for.

Just picked this up the other day! So far it's been awesome. I've assembled a basic pair of bars with the usual suspects and it's been smooth sailing

Superficially, this looks quite similar to conky. Can anyone comment on similarities/differences? (other than "written in rust")

I tried an unsuccessful rice sometime ago from here [0] The installation page has some dependency on conky-lua package. My OS cranked up a few errors during compilation(?), hence wouldn't know. But hopefully the link answers your question.

0: https://old.reddit.com/r/unixporn/comments/wlscxa/fvwm_an_es...

Superficially, it is similar to conky in concept, but with very different primary points of focus. whilst conky excells at having lots of info on your desktop in the background, eww might not be optimal for that. On the other hand, eww is generally a lot easier to get visually appealing main-point-of-focus widgets in, for overlay dashboards, media/volume controls and of course bars. Eww was and is generally designed to be more or less "two-dimensional polybar", both in its original design of widgets and the state architecture.

Being written using GTK and thus also styled in GTK CSS makes a big impact here, of course

This is more like dmenu (et al) + $various_bars than conky. It allows you to do various overlay widgets and keybindings to activate/act on them.

How is MacOS compatibility? Or is there something similar for Mac?

I see references to MacOS in the code, but it looks like m1/m2 support isn't there yet.

https://github.com/elkowar/eww/issues/353

A comment in that also mentions that even with mX support it won't be very useful: https://github.com/elkowar/eww/issues/353#issuecomment-97281... The "any window manager" claim is not meant for any unix.

Quite impressive visually. I think I'll give this a try.

Does this work with any desktop environment?

Yes! It works both on X and on Wayland, and should support basically any DE, WM and compositor out there. Note that there are a few exceptions: As far as I'm aware, GNOME on wayland is not going to work well, as GNOME doesn't implement the necessary wayland extension protocols eww relies on to position its windows

I wonder if it'd be possible to transpile it to Rainmeter configuration?

> The key difference: It is independent of your window manager!

From the website[1]

[1] - https://elkowar.github.io/eww/

It does. It even works on macos iirc

Does it have a rich text editor field?

I saw this pop up yesterday on the unfortunately named https://www.reddit.com/r/unixporn/ – a subreddit well worth checking out if you want some inspiration around styling your desktop. Lots of interesting tools pop up in the comments I'd never heard of before.

(Edit: The reason I say it's 'unfortunately' named is that not everyone has the privilege to load pages containing terms like 'porn' without the risk of trouble in their workplace, country, or otherwise. I have no problem with the name personally, and it's a fantastic sub and Discord.)

Not everything in the world has to be Safe For Work. The world is not a giant workplace (yet).

I work for myself and own all of my own equipment, so believe me, I am more than happy to load anything legal at work without triggering a filter or getting a visit from a boss. Sadly not everyone has this privilege.

> Sadly not everyone has this privilege.

Everyone has the option of not browsing HN at work.

True, but nsfw isn't just about work, but also about people with more conservative sensibilities.

You could call your project bacon soaked in milk but it might needlessly deter Muslims and Jews.

If we cater to everyone, nothing will be allowed.

If we cater to a specific set of people, it will be a discrimination against all others.

I think the most tolerant solution is to let people control their own bubbles of what they want to see.

From a "fortune -o" message my BSD threw at me a long time ago: ~"It is a sad comment on society that this message is being flagged as offensive just because it contains the word 'fuck'."

I think it's named suitably, even if it's not appropriate.

There's also the widespread use of the term ricing, which, yes, I kniw has been debated and broadly accepted by the community

Nothing wrong with the name.