elkowar/eww

Elkowar’s Wacky Widgets is a standalone widget system made in Rust that allows you to...

Elkowar’s Wacky Widgets is a standalone widget system made in Rust that allows you to implement

Eww

Elkowar’s Wacky Widgets is a standalone widget system made in Rust that allows you to implement your own, custom widgets in any window manager.

Documentation and instructions on how to install can be found here.

New configuration language is being made!

A new configuration language for Eww is being made! yuck is the new name! (as discussed in the discussion post.) You can check out its development in this PR and maybe contribewwte!

Examples

  • A basic bar, see examples

  • Setup by Axarva

  • Setup by adi1090x

Contribewwting

If you want to contribute anything, like adding new widgets, features or subcommands (Including sample configs), you should definitely do so.

Steps

  1. Fork this repository
  2. Install dependencies
  3. Smash your head against the keyboard from frustration (coding is hard)
  4. Open a pull request once you're finished
Issues

Collection of the latest Issues

iSparsh

iSparsh

Comment Icon2

Problem

The README is getting highly populated with examples which are just making it more obnoxious to read. I propose we move to actually use a user-examples directory rather than moving forward with the current process.

Structure

Instructions will include process for how to go about actually making a PR and documentation for examples. It will also include process to create a literate and usable example for others to refer and go ahead.

In the main README, only the very beautiful projects with eww can be featured in a GIF/mp4 and linked to the examples directory for people to visibly see.

If this is okay and members can give me the go-ahead, I will make a PR to implement this change.

viandoxdev

viandoxdev

enhancement
Comment Icon0

Description of the requested feature

Not sure if I'm being dumb, but AFAIK, there is currently no way to access a JSON array's length in yuck, even though yuck does support the arrays themselves, so I'd like a way to do exactly that.

Proposed configuration syntax

How it's done doesn't really matter but here's a few ways:

the javascript way:

or in a function

if done this way (function) it could also return strings' length, and be useful to know if a string would fit in a certain space or not (and replace it with another if it doesn't).

Additional context

This would be useful when trying to display variable length JSON data. In my case I'm trying to display contributions obtained from the Github API.

Workarround

For now since I'm already using jq to simplify the API's responses, I can do:

which gives

and use it in yuck like this

Patch that implements this feature:

mainrs

mainrs

bug
Comment Icon1

Checklist before submitting an issue

  • I have searched through the existing closed and open issues for eww and made sure this is not a duplicate
  • I have specifically verified that this bug is not a common user error
  • I am providing as much relevant information as I am able to in this bug report (Minimal config to reproduce the issue for example, if applicable)

Description of the bug

I am not sure if this is meant to be, but widgets always draw above any of my windows and make the area un-clickable.

Reproducing the issue

Just start some widget.

This is my config:

Expected behaviour

The widgets get drawn "in the background" behind all windows.

Additional context

  • system: "x86_64-linux"
  • host os: Linux 5.10.93, NixOS, 21.11 (Porcupine)
  • eww version: 0.2.0
  • DE: Plasma 5.23.3
  • WM: KWin
PabloMansanet

PabloMansanet

bug
Comment Icon3

Checklist before submitting an issue

  • I have searched through the existing closed and open issues for eww and made sure this is not a duplicate
  • I have specifically verified that this bug is not a common user error
  • I am providing as much relevant information as I am able to in this bug report (Minimal config to reproduce the issue for example, if applicable)

Description of the bug

Setup: AMD Ryzen 7 5800H running stock Arch Linux. I installed eww through the AUR package, which correctly builds with --release.

Running Eww with any widget open (including the example window widget in the documentation) results in a constant 80-100% utilization of a single core.

This may be normal, but it seemed high enough to me to bring it up in case there's something wrong with my setup.

Please let me know if there's any particular info I can provide to help, or if this is completely ordinary.

Reproducing the issue

Running the example tutorial window.

Expected behaviour

Lower CPU utilization for a static widget with no dynamic data.

Additional context

image

CMurtagh-LGTM

CMurtagh-LGTM

enhancement
Comment Icon0

Description of the requested feature

Have a window be able to open on the monitor that has the currently focused window.

Proposed configuration syntax

or

Additional context

No response

viandoxdev

viandoxdev

enhancement
Comment Icon0

Description of the requested feature

A keepalive property on deflisten that would make the variable continue to get updated even when not used in any windows.

Proposed configuration syntax

Additional context

Currently variables defined with deflisten which aren't used in any open window don't get updated (which is good most of the time). But this can cause problems: a side bar (which stays closed more often than) with a workspace display (updates rarely) doesn't keep up with the last focused workspace if it is closed, and shows an outdated value when opened. A work around for this is to use the variable in an hidden (0px width/height) window that stays open.

Vermoot

Vermoot

enhancement
Comment Icon0

Description of the requested feature

I'm not sure whether this should be with the button or the eventbox widget, but it'd be nice to be able to set an action for when the user releases the click.

Proposed configuration syntax

Additional context

No response

jokeyrhyme

jokeyrhyme

bug
Comment Icon2

Checklist before submitting an issue

  • I have searched through the existing closed and open issues for eww and made sure this is not a duplicate
  • I have specifically verified that this bug is not a common user error
  • I am providing as much relevant information as I am able to in this bug report (Minimal config to reproduce the issue for example, if applicable)

Description of the bug

I use the same eww.yuck on both a gaming PC (no batteries), and a laptop: https://gitlab.com/jokeyrhyme/dotfiles/-/blob/main/config/eww/eww.yuck

I've noticed that on my PC, with no batteries, the EWW_BATTERY value is not valid JSON, which makes working with it tricky

Reproducing the issue

You can see here that EWW_RAM is valid JSON, but EWW_BATTERY is truncated, and I'm also not sure if NaN is a valid JSON number

Expected behaviour

I'm not quite sure what to expect, I suppose this is a question of design

  • should EWW_BATTERY be completely absent when there is no battery ?
  • should it be an empty string ?
  • should it be JSON like { "total_avg": null } ?

Additional context

I believe this line might need some adjustment: https://github.com/elkowar/eww/blob/master/crates/eww/src/config/system_stats.rs#L153

I might have an attempt at this myself if I get some free time

matthis-k

matthis-k

bug
Comment Icon0

Checklist before submitting an issue

  • I have searched through the existing closed and open issues for eww and made sure this is not a duplicate
  • I have specifically verified that this bug is not a common user error
  • I am providing as much relevant information as I am able to in this bug report (Minimal config to reproduce the issue for example, if applicable)

Description of the bug

The label does not fill the window, althogh it is hardcoded to do so.

Reproducing the issue

eww.yuck

eww.scss

Expected behaviour

The label fills the whole window. Expected: something like on top Acutal: bottom

image

Additional context

Additional context

I want to remake and improve my statusbar with eww. For that i want a poweroff box, which expands on hover to show options like reboot/poweroff/slepp etc. To stay consitent with my current styling, i want that to be in an 30px x 30px box, but for some reason, i can not get it to fit that, even tho it easily could fit and i hardcoded some widths/heights. Here is an image (top is waybar, bottom eww)

eddsalkield

eddsalkield

enhancement
Comment Icon0

Description of the requested feature

I'm trying to achieve a fade-in effect for windows when opened, and to do this I'm looking to set/unset a class attribute of the window and match it in the CSS.

When I set the class like so:

And with the following CSS:

I get: actual

When it would be nice to have: expected

Proposed configuration syntax

Class to mirror widget syntax a bit more, to include attributes :class and :style.

Additional context

The gtk inspector shows that the problem is that the class isn't getting set: inspector

matthis-k

matthis-k

enhancement
Comment Icon0

Description of the requested feature

The ability to constrain a window/component to a maximum size.

Proposed configuration syntax

simply a field like :maxw

Additional context

Background: I want to remake and improve my statusbar with eww. For that i want a poweroff box, which expands on hover to show options like reboot/poweroff/slepp etc. To stay consitent with my current styling, i want that to be in an 30px x 30px box, but for some reason, i can not get it to fit that, even tho it easily could fit and i hardcoded some widths/heights. Here is an image (top is waybar, bottom eww) image

eww.yuck

eww.scss

Animeshz

Animeshz

bug
Comment Icon0

Checklist before submitting an issue

  • I have searched through the existing closed and open issues for eww and made sure this is not a duplicate
  • I have specifically verified that this bug is not a common user error
  • I am providing as much relevant information as I am able to in this bug report (Minimal config to reproduce the issue for example, if applicable)

Describe the bug

Let's say a poll-var is refreshed at a rate of 5 minutes, we suspend the laptop 1 min after a refresh, we resume it later on maybe say 1 hour, now it needs 4 minutes for it to refresh itself, its very inaccurate specially for battery and weather status...

Reproducing the issue

On resume, value doesn't update immediately if 1min is elapsed, counted from last refresh.

Expected behaviour

It should rather work at absolute clock differences, and if not atleast listen to suspend events and add a timestamp and utilize it in next resume.

Additional context

Might be a bit related to https://github.com/rust-lang/rust/issues/79462

elkowar

elkowar

enhancement
Comment Icon0

Description of the requested feature

Currently it's kind of confusing to have to put things like json access into {} when not in a string. It should be possible to just do

without the curlies, optimally.

Similarly, but larger scope, it would be nice to allow completely abandoning the simplexpr syntax by making math via (+ 1 some_var) possible and identical to {1 + some_var}

tramhao

tramhao

bug
Comment Icon8

Checklist before submitting an issue

  • I have searched through the existing closed and open issues for eww and made sure this is not a duplicate
  • I have specifically verified that this bug is not a common user error
  • I am providing as much relevant information as I am able to in this bug report (Minimal config to reproduce the issue for example, if applicable)

Describe the bug

I'm using eww as bar for leftwm. It works but always stop updating for no obvious reason that I can find. It'll work again if I close-all and open-many again. About 1 hour or 2 it'll happen. I have two screens. Configuration is as below:

my monitor xrandr script:

my eww configuration is as below:

Reproducing the issue

As configuration above.

Expected behaviour

It should keep updating.

Additional context

If applicable, provide additional context or screenshots here I turned on --debug so the log is pretty long and I'll not post it but attach it instead. eww_L2hvbWUvdHJhbWhhby8uY29uZmlnL2V3dw==.log

eddsalkield

eddsalkield

bug
Comment Icon5

Checklist before submitting an issue

  • I have searched through the existing closed and open issues for eww and made sure this is not a duplicate
  • I have specifically verified that this bug is not a common user error
  • I am providing as much relevant information as I am able to in this bug report (Minimal config to reproduce the issue for example, if applicable)

Describe the bug

On Alpine Linux, the current master branch segfaults when eww daemon --no-daemonize is run.

Reproducing the issue

Compile eww from master on mainline Alpine. Create ~/.config/eww. Run eww daemon --no-daemonize

Additional context

Catvert

Catvert

bug
Comment Icon0

Checklist before submitting an issue

  • I have searched through the existing closed and open issues for eww and made sure this is not a duplicate
  • I have specifically verified that this bug is not a common user error
  • I am providing as much relevant information as I am able to in this bug report (Minimal config to reproduce the issue for example, if applicable)

Describe the bug

Hello, I'm trying to create 2 bars (like polybar) for my 2 monitors. I have some script that poll some informations, like current volume and the playerctl status.

However, when I'm closing the bars (with close-all), some of these sub-processes are leaked out and not closed properly. This 'leak' does not appear with only 1 window (bar) opened. I've also noticed that when I'm opening the 2 window, the processes that are defined in 'deflisten' spawn 2 times instead of one (I'm not sure if this is the expected behavior).

Reproducing the issue

For example, here is my deflistens :

eww-volume and eww-music-subscribe are simply scripts that call 'playerctl --follow' and 'pactl subscribe' and pretty-print the output.

Here is my windows :

When opening just one window (bar_screen1) : image

When opening the two windows (bar_screen1 + bar_screen2) :

image

Note that eww-volume and eww-music-subscribe (+ tail) are duplicated (Which I think is not an expected behavior, aren't the variables 'global'?)

Now, when I , here is the result : image

A 'pair' of sub-processes are not killed (which is not normal).

If instead I kill the daemon (eww kill), the subprocesses are still active while eww no longer exists.

image

I noticed this bug when after a morning of tweaking my dotfiles, I noticed that I had about 20 processes of 'eww-volume and eww-music-subscribe' in my task manager

I hope my explanations are clear, don't hesitate to come back to me if you need more information.

Thank you for your help.

Vermoot

Vermoot

enhancement
Comment Icon6

Being able to set custom tooltips for widgets would be cool

ImDevinC

ImDevinC

bug
Comment Icon9

Checklist before submitting an issue

  • I have searched through the existing closed and open issues for eww and made sure this is not a duplicate
  • I have specifically verified that this bug is not a common user error
  • I am providing as much relevant information as I am able to in this bug report (Minimal config to reproduce the issue for example, if applicable)

Describe the bug

image widget doesn't use class properly

Reproducing the issue

yuck

scss

Expected behaviour

The image should have the styles applied to it but they are not

Additional context

ExpandingMan

ExpandingMan

enhancement
Comment Icon6

Description of the requested feature

I'm not entirely sure whether this should be considered a new feature or a bug, or if there's already some way of doing this that I can't figure out.

It would be nice to tell eww that a window should be drawn on top of everything and necessarily visible (my use case is for bringing up menus while watching full-screen video). Currently this does not seem possible on Xorg, at least not without special configuration of the window manager.

I know it's possible to do this because dunst does, though this is the only thing I'm currently aware of that draws on top of full-screen windows in X.

Proposed configuration syntax

The :stacking argument to defwindow should be further clarified. Presumably this behavior would either replace "fg" or get its own value.

Additional context

Again, particularly relevant if something else is in full-screen.

elkowar

elkowar

enhancement
Comment Icon0

Currently eww simply defaults to an empty config when the daemon initially fails to load the config. This means that the error gets printed out during daemon startup, but does not get reported on other interactions with the config, such as opening windows. For those cases, it currently just prints out "Window does not exist".

This could be solved by actually storing the configuration as a Result in the app struct, or by having some other mechanism to guarantee that the config is always valid when parts of eww that rely on it are accessing it.

druskus20

druskus20

Comment Icon2

Description of the widget

Currently users dont have the ability to rotate widgets, implementing a wrapper widget that rotates its content should be pretty easy using cairo.

elkowar

elkowar

bug
Comment Icon0

Checklist before submitting an issue

  • I have searched through the existing closed and open issues for eww and made sure this is not a duplicate
  • I have specifically verified that this bug is not a common user error
  • I am providing as much relevant information as I am able to in this bug report (Minimal config to reproduce the issue for example, if applicable)

Describe the bug

eww does not properly start without an eww.scss file existing. the error message complains about the window not existing, which is severely misleading, too. There is no reason to require that file to exist.

elkowar

elkowar

enhancement
Comment Icon0

To anyone desperately waiting for this: I am, too, but it's still gonna take some time, as a large statemanagement rework is first required, that has already cost me a lot of braincells...

In the future, it should be possible to have variables be local to a widget. This would allow for reusable widgets to have their own, isolated state, making it significantly easier to implement generic, dynamic UI elements. For this, a couple of things are necessary. First and foremost, the already planned statemanagement rework needs to take place, to make this possible. Secondly, Syntax for defining and updating local variables needs to be defined and implemented. Here we could either go with a classic let Syntax, as is popular in most lisps, or have a special variables block of some kind.

the way to update these would most likely be adding a set Form as a valid value for onclick and similar attributes. For consistency, shell commands should then maybe also fall under a (shell notify-send foo)` Syntax, although that would be a breaking change.

Its also not yet clear if locals should also allow for script vars.

Versions

Find the latest versions by id

Information - Updated Feb 17, 2022

Stars: 2.0K
Forks: 92
Issues: 63

Repositories & Extras

This is an example of a Rust server that functions as a remote schema for...

Rust + Hasura Rust server that functions as a Hasura

This is an example of a Rust server that functions as a remote schema for...

Newport Engine is a modular 2D and 3D game engine built in Rust for Rust

It is designed to be easily extendable and easy to use

Newport Engine is a modular 2D and 3D game engine built in Rust for Rust

liboqs-rust: Rust bindings for liboqs

Qyantum Safe liboqs rust bindings

liboqs-rust: Rust bindings for liboqs

msgflo-rust: Rust participant support for MsgFlo

Flowhub visual programming IDE

msgflo-rust: Rust participant support for MsgFlo
Actix

1.2K

How to be a full stack Rust Developer

Read Rust the Rust blog posts at Steadylearner

How to be a full stack Rust Developer

Rust library translation (rust-src/rust-std/stdlib/rustlib translation)

This is the place to translate Having a documentation in your native language is essential if you don't speak English, and still enjoyable even if...

Rust library translation (rust-src/rust-std/stdlib/rustlib translation)

False Positive for rust-lang/rust#83583

The deprecation lint proc_macro_derive_resolution_fallback is intended to catch proc macro generated code that refers to items from parent modules that should not be in scope:

False Positive for rust-lang/rust#83583

xbuild is a build tool for rust and rust/flutter projects with support for cross compiling...

xbuild is a build tool for rust and rust/flutter projects with support for cross compiling and

xbuild is a build tool for rust and rust/flutter projects with support for cross compiling...

Rust: setup Rust with rustup

wabt: --sysroot value in the Makefiles when using a different target localtion for wasi-sdk)

Rust: setup Rust with rustup

How to be a full stack Rust Developer

Read Rust the Rust blog posts at Steadylearner

How to be a full stack Rust Developer

Snake game developed in Rust using rust-sdl2 crate

Snake game developed in Rust using

Snake game developed in Rust using rust-sdl2 crate

This is a game engine for rust in rust

I'm building it as a learning experience to try and better understand rust and what goes into making a game engine

This is a game engine for rust in rust
Facebook Instagram Twitter GitHub Dribbble
Privacy