Currently, Eww windows cannot be focused. This makes widgets like Entry (a text input field) mostly useless, as you cannot type in them without focusing them.

Thus, a config option on <window> should be introduced that allows a widget to be focusable.

Acceptance Criteria

• <window> supports the focusable="true" attribute, which then allows the user to focus the window.
• As a result of that, the input field is usable.

Describe the bug

EWW creates too many zombie sh processes and this is worrying...
Processes marked <defunct> are dead processes (so-called "zombies") that remain because their parent has not destroyed them properly. These processes will be destroyed by init(8) if the parent process exits. There is no harm in letting such processes be unless there are many of them.

❯ ps -e | grep sh
    155 ?        00:00:00 zswap-shrink
   1363 ?        00:00:00 ssh-agent
   1409 ?        00:00:00 redshift-gtk
   1539 ?        00:00:02 redshift
   2018 ?        00:00:00 sh <defunct>
   2029 ?        00:00:00 sh <defunct>
   3171 pts/0    00:00:00 fish
   5719 ?        00:00:00 gvfsd-trash
  26235 ?        00:00:00 sh <defunct>
  26240 ?        00:00:00 sh <defunct>
  26244 ?        00:00:00 sh <defunct>
  26252 ?        00:00:00 sh <defunct>
  26317 ?        00:00:00 sh <defunct>
  26322 ?        00:00:00 sh <defunct>
  26355 ?        00:00:00 sh <defunct>
  26366 ?        00:00:00 sh <defunct>
  26369 ?        00:00:00 sh <defunct>
  26374 ?        00:00:00 sh <defunct>
  26379 ?        00:00:00 sh <defunct>
  26384 ?        00:00:00 sh <defunct>
  26387 ?        00:00:00 sh <defunct>
  26393 ?        00:00:00 sh <defunct>
  26396 ?        00:00:00 sh <defunct>
  26403 ?        00:00:00 sh <defunct>
  26406 ?        00:00:00 sh <defunct>
  26411 ?        00:00:00 sh <defunct>
  26414 ?        00:00:00 sh <defunct>
  26420 ?        00:00:00 sh <defunct>
  26423 ?        00:00:00 sh <defunct>
  26428 ?        00:00:00 sh <defunct>
  26431 ?        00:00:00 sh <defunct>
  26436 ?        00:00:00 sh <defunct>
  26441 ?        00:00:00 sh <defunct>
  26449 ?        00:00:00 sh <defunct>
  26452 ?        00:00:00 sh <defunct>
  26457 ?        00:00:00 sh <defunct>
  28269 pts/2    00:00:00 fish
  33182 ?        00:00:00 sh <defunct>
  33272 ?        00:00:00 sh <defunct>
  33274 ?        00:00:00 sh <defunct>
  33276 ?        00:00:00 sh <defunct>
  33278 ?        00:00:00 sh <defunct>
  33280 ?        00:00:00 sh <defunct>
  33285 ?        00:00:00 sh <defunct>
  33287 ?        00:00:00 sh <defunct>
  33289 ?        00:00:00 sh <defunct>
  33291 ?        00:00:00 sh <defunct>
  33295 ?        00:00:00 sh <defunct>
  33297 ?        00:00:00 sh <defunct>
  33299 ?        00:00:00 sh <defunct>
  33301 ?        00:00:00 sh <defunct>
  33303 ?        00:00:00 sh <defunct>
  33307 ?        00:00:00 sh <defunct>
  33309 ?        00:00:00 sh <defunct>
  33311 ?        00:00:00 sh <defunct>
  33315 ?        00:00:00 sh <defunct>
  33319 ?        00:00:00 sh <defunct>
  33321 ?        00:00:00 sh <defunct>
  33323 ?        00:00:00 sh <defunct>
  33328 ?        00:00:00 sh <defunct>
  33330 ?        00:00:00 sh <defunct>
  33338 ?        00:00:00 sh <defunct>
  33342 ?        00:00:00 sh <defunct>
  33346 ?        00:00:00 sh <defunct>
  33348 ?        00:00:00 sh <defunct>
  33352 ?        00:00:00 sh <defunct>
  33354 ?        00:00:00 sh <defunct>
  33358 ?        00:00:00 sh <defunct>
  33362 ?        00:00:00 sh <defunct>
  33364 ?        00:00:00 sh <defunct>
  33366 ?        00:00:00 sh <defunct>
  33370 ?        00:00:00 sh <defunct>
  33372 ?        00:00:00 sh <defunct>
  33374 ?        00:00:00 sh <defunct>
  33378 ?        00:00:00 sh <defunct>
  33380 ?        00:00:00 sh <defunct>
  33387 ?        00:00:00 sh <defunct>
  33391 ?        00:00:00 sh <defunct>
  33394 ?        00:00:00 sh <defunct>
  33396 ?        00:00:00 sh <defunct>
  33400 ?        00:00:00 sh <defunct>
  33402 ?        00:00:00 sh <defunct>
  33404 ?        00:00:00 sh <defunct>
  33406 ?        00:00:00 sh <defunct>
  33411 ?        00:00:00 sh <defunct>
  33413 ?        00:00:00 sh <defunct>
  33415 ?        00:00:00 sh <defunct>
  33417 ?        00:00:00 sh <defunct>
  33419 ?        00:00:00 sh <defunct>
  33421 ?        00:00:00 sh <defunct>
  33423 ?        00:00:00 sh <defunct>
  33427 ?        00:00:00 sh <defunct>
  33429 ?        00:00:00 sh <defunct>
  33431 ?        00:00:00 sh <defunct>
  33433 ?        00:00:00 sh <defunct>
  33437 ?        00:00:00 sh <defunct>
  33439 ?        00:00:00 sh <defunct>
  33441 ?        00:00:00 sh <defunct>
  33445 ?        00:00:00 sh <defunct>
  33449 ?        00:00:00 sh <defunct>
  33451 ?        00:00:00 sh <defunct>
  33453 ?        00:00:00 sh <defunct>
  33456 ?        00:00:00 sh <defunct>
  33460 ?        00:00:00 sh <defunct>
  33462 ?        00:00:00 sh <defunct>
  33470 ?        00:00:00 sh <defunct>
  33476 ?        00:00:00 sh <defunct>
  38501 pts/1    00:00:00 fish

Reproducing the issue

Add this button to eww.xml (and click it many times each click produces 2 sh processes):

      <button onclick="
xdotool search --onlyvisible --name time_window &amp;&amp; eww close time_window || eww open time_window
        "/>

This is what I use to make an eww window "pop-up".
Here "&" means "&" it's standard xml format.

IMPORTANT: you do not need to have xdotool installed! This behavior is also reproducable using this:

      <button onclick="
pgrep 'eww' &amp;&amp; echo '' || echo ''
        "/>

Expected behaviour

I expect eww to handle processes correctly by exiting child processes properly.
But if it can't then I expect eww to reap the zombie process.

Additional context

n/a

The current implementation of interpolated var-ref parsing seems to have introduced issues with including {}, used as a placeholder, in attributes. This needs to be fixed.

Acceptance Criteria

• parsing an attribute-value that includes {} anywhere works correctly
• Tests to verify this are implemented

Eww should support reading environment variables anywhere, to make it easier to refer to paths and other variables.
The syntax for this should simply be some text $ENV_VAR <button>whatever</button>.

As this should probably only be done once, it would be possible to introduce a simple env-var expansion step into the parser, where we simply replace all env-var mentions with the respective values before even running it through the XML parser.

While this feels somewhat hacky, any other implementations would require doing env-var expansion in multiple, less "hidden" places, thus making the code less nice to read.

Acceptance criteria

• the eww.xml file as well as the eww.scss file allow users to use $VAR_NAME syntax to refer to environment variables, which will be expanded directly after the respective file is read

Description of the requested feature

Just a -c flag to specify config location, e.g eww open main_window -c ~/Documents/eww.xml

Proposed configuration syntax

 `eww open main_window -c ~/Documents/eww.xml` 

Additional context

just like polybar does

Description of the requested feature

when you display a text have \n. it is display \n but i want it to be a new line.

Description of the requested feature

I apologize if this has already been discussed, but I can't seem to find anything while scouring the documentation and the github issues/PRs. It would be fantastic to be able to specify multiple widgets within a single window rather than have only one widget per window.

Proposed configuration syntax

I suppose within the <widget> tag, you could specify a list of widgets per location (kind of similar to polybar). To further illustrate:

<windows>
    <window name="main_bottom">
        <geometry x="5%" y="75%" width="90%" height="25%"/>
        <widget>
              <left>
                  <profile/>
                  <player/>
              </left>
              <center>
                  <launch/>
              </center>
              <right>
                  <weather/>
                  <system_info/>
              </right>
          </widget>
      </window>
</windows>

You may even want to create a <widgets> tag for this specific purpose rather than just <widget>

Description of the requested feature

With multi-file configuration coming up (#45), it will be likely that users will be sharing eww widgets for others to reuse. This may cause issues with conflicting variables names, in some cases.
To avoid these, namespaced variables would be a good idea: every file could work under a different namespace, thus avoiding name conflicts. Additionally, this could be used to put magic variables as proposed in #53 under a common namespace.

Proposed configuration syntax

To reference a namespaced variable, the syntax could look like namespace::variablename. Declaring them would be based on filename, or possibly based on an explicit namespace configuration - if necessary.

Eww should provide a command to query the current eww state (the state of all global variables).

Acceptance criteria

• a eww state subcommand exists that outputs the current variable-state in a nice, machine and human readable manner.

pos and size's x and y properties should support % for a percentage of the screen for the window, dpi should also be an option but it should default to pixels. Example:

<size x="10%" y="5dpi" />
<pos x="0" y="3%" />

Description of the requested feature

The eww list-windows command should print out a simple, line-separated list listing all the window names that the user has configured.
This should work without the eww daemon, and should thus be implemented as an ActionClientOnly.

Describe the bug

#!/bin/bash
  eww -d &
  eww open weather_side &
  eww open time_side &
  eww open smol_calendar &
  eww open player_side &
  eww open sys_side &
  eww open sliders_side &

This script won't work, or it'll just create only one window instead of all specified.

However, adding a sleep command works!

#!/bin/bash
(eww -d &)
sleep 1
 eww open weather_side &
 eww open time_side &
 eww open smol_calendar &
 eww open player_side &
 eww open sys_side &
 eww open sliders_side &

I don't know what we're even looking at, seems like eww needs a delay before launching stuff?

Reproducing the issue

Run the first script, possibly by using exec foo.sh or something along the lines of it.

Expected behaviour

Launch everything properly

Additional context

I dunno

Describe the bug

Some eww commands creates extraneous new lines even though they aren't supposed to output anything.
An extraneous new line is an unwanted newline character "\n" that gets printed on a blank like at the end of the command. This results in two double line character on the terminal "\n\n" creating blank space.

Reproducing the issue

(when daemon running)

(when daemon not running)

I believe there is a clear correlation between daemon running and new line characters getting printed.

Expected behavior

Don't print an extra line on commands that aren't supposed to output anything.

Additional context

End my suffering and fix this please.

Description of the requested feature

Script-variables should only be executed if they are used in any window that is open.

Since migrating the limit-width attribute on <label> over to make use of set_max_width_chars in gtk, it doesn't work anymore. This needs to be fixed.

Best case: We understand why it doesn't work right now, and continue to make use of the GTK function.
As long as that is not done, we should revert back to the initial implementation that manually shortened the string.

Acceptance Criteria

• limit-width if possible makes use of the GTK function set_max_width_chars, and correctly limits the character width of a label

Currently, a lot of errors fail silently, as the error output is only sent to the log file, but not to the calling IPC client. This should be improved to provide a better user-experience.

A good example for this is eww open currently not showing any error if the window with the given name does not exist. For cases like these, a general abstraction needs to be set up that can handle these kinds of errors properly.

Description of the requested feature

When many windows are launched, it often becomes cumbersome to close them one by one. Instead, if eww supported a close all command, it would be helpful. killall eww or eww kill works, but that kills the eww server as well, which means widgets launch slower next time.

Proposed configuration syntax

eww close all

Additional context

I dunno

Right now, unless you have a button to quit eww, you can't quit it, except when signalling the terminal to stop, which doesn't work if you opened the widget through a keybind.

Maybe add some button with which you can kill eww...

Describe the bug

I follow the step to compile eww (there aren't many), satisfying all the dependencies I might have (glib-2.0) ; but then... Well. I have the report with --verbose ; and I'm not qualified enough to find the issue.

Expected behaviour

Everything goes well ?

Additional context

 $ git clone https://github.com/elkowar/eww
 $ cd eww
 $ cargo build --release --verbose 
       Fresh unicode-xid v0.2.1
       Fresh unicode-segmentation v1.7.1
       Fresh pkg-config v0.3.19
       Fresh version-compare v0.0.10
       Fresh strum v0.18.0
       Fresh autocfg v1.0.1
       Fresh version_check v0.9.2
       Fresh once_cell v1.5.2
       Fresh cfg-if v1.0.0
       Fresh futures-core v0.3.8
       Fresh futures-sink v0.3.8
       Fresh futures-io v0.3.8
       Fresh either v1.6.1
       Fresh pin-utils v0.1.0
       Fresh slab v0.4.2
       Fresh smallvec v1.6.0
       Fresh cfg-if v0.1.10
       Fresh ppv-lite86 v0.2.10
       Fresh lazy_static v1.4.0
       Fresh scopeguard v1.1.0
       Fresh siphasher v0.3.3
       Fresh unicode-width v0.1.8
       Fresh pin-project-lite v0.2.1
       Fresh bytes v1.0.0
       Fresh ahash v0.3.8
       Fresh ansi_term v0.11.0
       Fresh quick-error v1.2.3
       Fresh unicode-xid v0.0.4
       Fresh regex-syntax v0.6.21
       Fresh vec_map v0.8.2
       Fresh strsim v0.8.0
       Fresh termcolor v1.1.2
       Fresh hashbrown v0.9.1
       Fresh quote v0.3.15
       Fresh codemap v0.1.3
       Fresh xmlparser v0.13.3
       Fresh beef v0.4.4
       Fresh unescape v0.1.0
       Fresh maplit v1.0.2
       Fresh heck v0.3.2
       Fresh futures-channel v0.3.8
       Fresh futures-task v0.3.8
       Fresh instant v0.1.9
       Fresh itertools v0.9.0
       Fresh itertools v0.10.0
       Fresh lock_api v0.4.2
       Fresh phf_shared v0.8.0
       Fresh thread_local v1.0.1
       Fresh peekmore v0.5.6
       Fresh textwrap v0.11.0
       Fresh synom v0.11.3
       Fresh humantime v1.3.0
       Fresh proc-macro2 v1.0.24
       Fresh roxmltree v0.14.0
       Fresh libc v0.2.81
       Fresh memchr v2.3.4
       Fresh proc-macro-hack v0.5.19
       Fresh bitflags v1.2.1
       Fresh proc-macro-nested v0.1.6
       Fresh anyhow v1.0.37
       Fresh log v0.4.11
       Fresh quote v1.0.8
       Fresh getrandom v0.1.16
       Fresh num-traits v0.2.14
       Fresh atty v0.2.14
       Fresh parking_lot_core v0.8.2
       Fresh num_cpus v1.13.0
       Fresh signal-hook-registry v1.3.0
       Fresh byteorder v1.3.4
       Fresh inotify-sys v0.1.4
       Fresh syn v0.11.11
       Fresh simple-signal v1.1.1
       Fresh aho-corasick v0.7.15
       Fresh hashbrown v0.8.2
       Fresh syn v1.0.58
       Fresh proc-macro-error-attr v1.0.4
       Fresh mio v0.7.7
       Fresh indexmap v1.6.1
       Fresh nix v0.19.1
       Fresh rand_core v0.5.1
       Fresh num-integer v0.1.44
       Fresh parking_lot v0.11.1
       Fresh clap v2.33.3
       Fresh num-complex v0.3.1
       Fresh serde_derive v1.0.118
       Fresh thiserror-impl v1.0.23
       Fresh strum_macros v0.18.0
       Fresh pin-project-internal v1.0.3
       Fresh proc-macro-error v1.0.4
       Fresh futures-macro v0.3.8
       Fresh tokio-macros v1.0.0
       Fresh regex v1.4.2
       Fresh lasso v0.3.1
       Fresh async-stream-impl v0.3.0
       Fresh smart-default v0.6.0
       Fresh debug_stub_derive v0.3.0
       Fresh derive_more v0.99.11
       Fresh serde v1.0.118
       Fresh thiserror v1.0.23
       Fresh rand_chacha v0.2.2
       Fresh rand_pcg v0.2.1
       Fresh num-bigint v0.3.1
       Fresh num-iter v0.1.42
       Fresh pin-project v1.0.3
       Fresh tokio v1.0.1
       Fresh env_logger v0.7.1
       Fresh structopt-derive v0.4.14
       Fresh async-stream v0.3.0
       Fresh extend v0.3.0
       Fresh toml v0.5.8
       Fresh rand v0.7.3
       Fresh num-rational v0.3.2
       Fresh bincode v1.3.1
       Fresh system-deps v1.3.2
       Fresh futures-util v0.3.8
       Fresh proc-macro-crate v0.1.5
       Fresh tokio-stream v0.1.1
       Fresh structopt v0.3.21
       Fresh pretty_env_logger v0.4.0
       Fresh inotify v0.9.2
       Fresh futures-executor v0.3.8
       Fresh glib-macros v0.10.1
       Fresh phf_generator v0.8.0
       Fresh tokio-util v0.6.0
       Fresh num v0.3.1
       Fresh futures v0.3.8
       Fresh phf_macros v0.8.0
       Fresh glib-sys v0.10.1
       Fresh phf v0.8.0
       Fresh gobject-sys v0.10.0
       Fresh cairo-sys-rs v0.10.0
       Fresh grass v0.10.4
       Fresh glib v0.10.3
       Fresh gio-sys v0.10.1
       Fresh pango-sys v0.10.0
       Fresh atk-sys v0.10.0
       Fresh gdk-pixbuf-sys v0.10.0
       Fresh gio v0.9.1
       Fresh pango v0.9.1
       Fresh cairo-rs v0.9.1
       Fresh atk v0.9.0
       Fresh gdk-sys v0.10.0
       Fresh gdk-pixbuf v0.9.0
       Fresh gtk-sys v0.10.0
       Fresh gdk v0.13.2
       Fresh gtk v0.9.2
   Compiling eww v0.1.0 (/home/brieucdug/eww)
     Running `rustc --crate-name eww --edition=2018 src/main.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type bin --emit=dep-info,link -C opt-level=3 -C metadata=b4a8ef6d35e6c69d -C extra-filename=-b4a8ef6d35e6c69d --out-dir /home/brieucdug/eww/target/release/deps -L dependency=/home/brieucdug/eww/target/release/deps --extern anyhow=/home/brieucdug/eww/target/release/deps/libanyhow-4c93d61ddd772d7d.rlib --extern async_stream=/home/brieucdug/eww/target/release/deps/libasync_stream-10c23430b97bd9da.rlib --extern bincode=/home/brieucdug/eww/target/release/deps/libbincode-2b6cf61d15bf1be5.rlib --extern debug_stub_derive=/home/brieucdug/eww/target/release/deps/libdebug_stub_derive-b9b53ee9056cca3d.so --extern derive_more=/home/brieucdug/eww/target/release/deps/libderive_more-eee836ee4c3bdf2d.so --extern extend=/home/brieucdug/eww/target/release/deps/libextend-f972a4c0e2e32b1c.so --extern futures_core=/home/brieucdug/eww/target/release/deps/libfutures_core-aa3bf7ddd0190f8b.rlib --extern futures_util=/home/brieucdug/eww/target/release/deps/libfutures_util-a04bac1776425920.rlib --extern gdk=/home/brieucdug/eww/target/release/deps/libgdk-a75b37d57017dbe4.rlib --extern gdk_pixbuf=/home/brieucdug/eww/target/release/deps/libgdk_pixbuf-2c61b8a8e0eddecf.rlib --extern gio=/home/brieucdug/eww/target/release/deps/libgio-e4763d354af23aea.rlib --extern glib=/home/brieucdug/eww/target/release/deps/libglib-b122479cc3b62b92.rlib --extern grass=/home/brieucdug/eww/target/release/deps/libgrass-1897f50db3f41ebd.rlib --extern gtk=/home/brieucdug/eww/target/release/deps/libgtk-98b9ab47bf3b3caf.rlib --extern inotify=/home/brieucdug/eww/target/release/deps/libinotify-b0be9a87afb282b4.rlib --extern itertools=/home/brieucdug/eww/target/release/deps/libitertools-6c2d5cc7c5a630f5.rlib --extern lazy_static=/home/brieucdug/eww/target/release/deps/liblazy_static-2167c1732418bde8.rlib --extern libc=/home/brieucdug/eww/target/release/deps/liblibc-28439c95f25d4cc8.rlib --extern log=/home/brieucdug/eww/target/release/deps/liblog-5be730c692f61d0c.rlib --extern maplit=/home/brieucdug/eww/target/release/deps/libmaplit-32f3c4d7594b4da4.rlib --extern nix=/home/brieucdug/eww/target/release/deps/libnix-167cd99bd6c59fa1.rlib --extern num=/home/brieucdug/eww/target/release/deps/libnum-1a0ff8c2fdb8223a.rlib --extern pretty_env_logger=/home/brieucdug/eww/target/release/deps/libpretty_env_logger-e4cfa79868418d9f.rlib --extern regex=/home/brieucdug/eww/target/release/deps/libregex-2f9d8deed112c301.rlib --extern roxmltree=/home/brieucdug/eww/target/release/deps/libroxmltree-7aa185c8d2dcd620.rlib --extern serde=/home/brieucdug/eww/target/release/deps/libserde-f3abc3777e86c3b4.rlib --extern simple_signal=/home/brieucdug/eww/target/release/deps/libsimple_signal-9420536cd39f22f6.rlib --extern smart_default=/home/brieucdug/eww/target/release/deps/libsmart_default-e535ebd6ee015c23.so --extern structopt=/home/brieucdug/eww/target/release/deps/libstructopt-a8683cf4f00d6b1d.rlib --extern tokio=/home/brieucdug/eww/target/release/deps/libtokio-bfbf8313a78a6d1d.rlib --extern tokio_stream=/home/brieucdug/eww/target/release/deps/libtokio_stream-62a59a48bc926181.rlib --extern tokio_util=/home/brieucdug/eww/target/release/deps/libtokio_util-bcb7907b4c4ee6f3.rlib --extern unescape=/home/brieucdug/eww/target/release/deps/libunescape-89cb55b6e89a2cf5.rlib`
error[E0554]: `#![feature]` may not be used on the stable release channel
 --> src/main.rs:1:1
  |
1 | #![feature(trace_macros)]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0554]: `#![feature]` may not be used on the stable release channel
 --> src/main.rs:2:1
  |
2 | #![feature(slice_concat_trait)]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0554]: `#![feature]` may not be used on the stable release channel
 --> src/main.rs:3:1
  |
3 | #![feature(result_cloned)]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0554]: `#![feature]` may not be used on the stable release channel
 --> src/main.rs:4:1
  |
4 | #![feature(iterator_fold_self)]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0554]: `#![feature]` may not be used on the stable release channel
 --> src/main.rs:5:1
  |
5 | #![feature(try_blocks)]
  | ^^^^^^^^^^^^^^^^^^^^^^^

error[E0554]: `#![feature]` may not be used on the stable release channel
 --> src/main.rs:6:1
  |
6 | #![feature(str_split_once)]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0277]: arrays only have std trait implementations for lengths 0..=32
   --> src/server.rs:121:49
    |
121 |     let mut event_stream = inotify.event_stream(&mut buffer)?;
    |                                                 ^^^^^^^^^^^ the trait `std::array::LengthAtMost32` is not implemented for `[u8; 1024]`
    |
    = note: required because of the requirements on the impl of `std::convert::AsMut<[u8]>` for `[u8; 1024]`
    = note: required because of the requirements on the impl of `std::convert::AsMut<[u8]>` for `&mut [u8; 1024]`

error[E0599]: no method named `next` found for struct `inotify::stream::EventStream<&mut [u8; 1024]>` in the current scope
   --> src/server.rs:124:40
    |
124 |         Some(Ok(event)) = event_stream.next() => {
    |                                        ^^^^ method not found in `inotify::stream::EventStream<&mut [u8; 1024]>`
    | 
   ::: /home/brieucdug/.cargo/registry/src/github.com-1ecc6299db9ec823/inotify-0.9.2/src/stream.rs:21:1
    |
21  | pub struct EventStream<T> {
    | -------------------------
    | |
    | doesn't satisfy `_: futures_core::stream::Stream`
    | doesn't satisfy `_: futures_util::stream::stream::StreamExt`
    |
    = note: the method `next` exists but the following trait bounds were not satisfied:
            `inotify::stream::EventStream<&mut [u8; 1024]>: futures_core::stream::Stream`
            which is required by `inotify::stream::EventStream<&mut [u8; 1024]>: futures_util::stream::stream::StreamExt`

error[E0599]: no method named `poll` found for struct `std::pin::Pin<&mut _>` in the current scope
   --> src/server.rs:123:5
    |
123 | /     crate::loop_select_exiting! {
124 | |         Some(Ok(event)) = event_stream.next() => {
125 | |             try_logging_errors!("handling change of config file" => {
126 | |                 if event.wd == config_file_descriptor {
...   |
139 | |         else => break,
140 | |     }
    | |_____^ method not found in `std::pin::Pin<&mut _>`
    |
    = note: `fut` is a function, perhaps you wish to call it
    = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0599]: no method named `poll` found for struct `std::pin::Pin<_>` in the current scope
   --> src/server.rs:123:5
    |
123 | /     crate::loop_select_exiting! {
124 | |         Some(Ok(event)) = event_stream.next() => {
125 | |             try_logging_errors!("handling change of config file" => {
126 | |                 if event.wd == config_file_descriptor {
...   |
139 | |         else => break,
140 | |     }
    | |_____^ method not found in `std::pin::Pin<_>`
    |
    = note: `fut` is a function, perhaps you wish to call it
    = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

error: aborting due to 10 previous errors

Some errors have detailed explanations: E0277, E0554, E0599.
For more information about an error, try `rustc --explain E0277`.
error: could not compile `eww`.

Caused by:
  process didn't exit successfully: `rustc --crate-name eww --edition=2018 src/main.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type bin --emit=dep-info,link -C opt-level=3 -C metadata=b4a8ef6d35e6c69d -C extra-filename=-b4a8ef6d35e6c69d --out-dir /home/brieucdug/eww/target/release/deps -L dependency=/home/brieucdug/eww/target/release/deps --extern anyhow=/home/brieucdug/eww/target/release/deps/libanyhow-4c93d61ddd772d7d.rlib --extern async_stream=/home/brieucdug/eww/target/release/deps/libasync_stream-10c23430b97bd9da.rlib --extern bincode=/home/brieucdug/eww/target/release/deps/libbincode-2b6cf61d15bf1be5.rlib --extern debug_stub_derive=/home/brieucdug/eww/target/release/deps/libdebug_stub_derive-b9b53ee9056cca3d.so --extern derive_more=/home/brieucdug/eww/target/release/deps/libderive_more-eee836ee4c3bdf2d.so --extern extend=/home/brieucdug/eww/target/release/deps/libextend-f972a4c0e2e32b1c.so --extern futures_core=/home/brieucdug/eww/target/release/deps/libfutures_core-aa3bf7ddd0190f8b.rlib --extern futures_util=/home/brieucdug/eww/target/release/deps/libfutures_util-a04bac1776425920.rlib --extern gdk=/home/brieucdug/eww/target/release/deps/libgdk-a75b37d57017dbe4.rlib --extern gdk_pixbuf=/home/brieucdug/eww/target/release/deps/libgdk_pixbuf-2c61b8a8e0eddecf.rlib --extern gio=/home/brieucdug/eww/target/release/deps/libgio-e4763d354af23aea.rlib --extern glib=/home/brieucdug/eww/target/release/deps/libglib-b122479cc3b62b92.rlib --extern grass=/home/brieucdug/eww/target/release/deps/libgrass-1897f50db3f41ebd.rlib --extern gtk=/home/brieucdug/eww/target/release/deps/libgtk-98b9ab47bf3b3caf.rlib --extern inotify=/home/brieucdug/eww/target/release/deps/libinotify-b0be9a87afb282b4.rlib --extern itertools=/home/brieucdug/eww/target/release/deps/libitertools-6c2d5cc7c5a630f5.rlib --extern lazy_static=/home/brieucdug/eww/target/release/deps/liblazy_static-2167c1732418bde8.rlib --extern libc=/home/brieucdug/eww/target/release/deps/liblibc-28439c95f25d4cc8.rlib --extern log=/home/brieucdug/eww/target/release/deps/liblog-5be730c692f61d0c.rlib --extern maplit=/home/brieucdug/eww/target/release/deps/libmaplit-32f3c4d7594b4da4.rlib --extern nix=/home/brieucdug/eww/target/release/deps/libnix-167cd99bd6c59fa1.rlib --extern num=/home/brieucdug/eww/target/release/deps/libnum-1a0ff8c2fdb8223a.rlib --extern pretty_env_logger=/home/brieucdug/eww/target/release/deps/libpretty_env_logger-e4cfa79868418d9f.rlib --extern regex=/home/brieucdug/eww/target/release/deps/libregex-2f9d8deed112c301.rlib --extern roxmltree=/home/brieucdug/eww/target/release/deps/libroxmltree-7aa185c8d2dcd620.rlib --extern serde=/home/brieucdug/eww/target/release/deps/libserde-f3abc3777e86c3b4.rlib --extern simple_signal=/home/brieucdug/eww/target/release/deps/libsimple_signal-9420536cd39f22f6.rlib --extern smart_default=/home/brieucdug/eww/target/release/deps/libsmart_default-e535ebd6ee015c23.so --extern structopt=/home/brieucdug/eww/target/release/deps/libstructopt-a8683cf4f00d6b1d.rlib --extern tokio=/home/brieucdug/eww/target/release/deps/libtokio-bfbf8313a78a6d1d.rlib --extern tokio_stream=/home/brieucdug/eww/target/release/deps/libtokio_stream-62a59a48bc926181.rlib --extern tokio_util=/home/brieucdug/eww/target/release/deps/libtokio_util-bcb7907b4c4ee6f3.rlib --extern unescape=/home/brieucdug/eww/target/release/deps/libunescape-89cb55b6e89a2cf5.rlib` (exit code: 1)

Description of the requested feature

Just like the title says, i want something that sets position of the widget, just like you can do with halign, and valign. Something like <pos x="center" y="center"> or <pos x="left" y="center"> instead of manually aligning it yourself.

Proposed configuration syntax

As stated above, manually aligning the widget is annoying as frick and i want something simpler. Since now you have to do tons of math or measure by eye - which doesn't always work. Simply to align a widget. And if i change the size of it a bit i have to re-position it again.

Additional context

nope.

All provided widgets need complete documentation. This should be automatically generated from comments in the source code

Acceptance criteria

• A strict format for the comments that document built-in widgets is designed
  • Links to the GTK-documentation of these widgets is provided if applicable
  • Attributes are documented, including type / all possible values where applicable
  • a description of the widget is included
  • a instanceof referencing-system is implemented which allows widget docs to link to all super-classes, automatically including the super-classes docs in the widget docs.
• A script that generates markdown documentation from these comments is implemented
• All built-in widgets are fully documented using the created format

Eww should provide support for Wayland. For this, mainly the window positioning and stacking behaviour needs to be abstracted away and reimplemented for wayland.
This should be pretty simple to implement by making use of gtk-layer-shell-rs.

Acceptance criteria

• Eww widgets are correctly positioned and stacked when run on wayland

Description of the requested feature

Box works as a very general way of expressing alignment, but is pretty unintuitive and rather unergonomic.

Expressing things like

|<thing 1      thing 2>                          <thing3>                                    <thing 4      thing 5>|

Is quite anoying and may not even seem "possible" to some users (see #87) , for example.

Adding some more expressive alignment primitives along the lines of

<columns>
  <column>whatever</column>
  <column>whatever</column>
  <column>whatever</column>
</columns>

where each <column> would take up exactly a third of the window and be correctly aligned (left/center/right respectively) by default would help make the most common layout structures for things like bars easier to express.

This would imply adding a system for widgets that have specific support for child-elements which need to be interpreted specifically.

This issue may serve as a general place to brainstorm these layout/alignment primitives, such as to collect ideas and then see if it makes sense to implement anything like this.

Eww should have documentation that explains the general concepts and CLI of eww.
These docs should go into a docs directory in the project, which may later be used to turn it into a github-pages site.

Acceptance Criteria

• Documentation explaining the basic idea, command line interface, and structure of eww is written and referenced in the Readme.
  • general concepts include explaining what widgets and windows are, and how eww relates to GTK

Should say "whether"; wasn't sure whether I should make a pull request or not due to the size of the change.

Description of the requested feature

If I create a label widget or a box widget I can only put one-line text on it. So if I want to print a multiline text, like an output of a program, only the last line is printed.

Proposed configuration syntax

There's no need... I think

Additional context

Here you can see the output of fortune on the terminal and on a label widget. Notice how the widget only shows the last line of the STDOUT

My eww.xml is here:

<eww>
    <definitions>
	<def name="fetch">
	    <box orientation="v" space-evenly="false">
		<label wrap="true" text="{{ufetch}}"/> 
	    </box>
	</def> 
  </definitions>

  <variables>
           <script-var name="ufetch"> fortune filosofia </script-var>
  </variables>

<windows>
    <window name="main_window" stacking="fg" focusable="false">
        <geometry anchor="top left" x="300px" y="50%" width="25%" height="300px"/>
        <widget>
		<fetch/>
        </widget>
    </window>
    </windows>
</eww>

Description of the requested feature

I thought this was possible through CSS but apparently not gtk-css
I'd like to be able to set the cursor when hovering over a widget, possibly in the block.

Proposed configuration syntax

<widget cursor="pointer">

Additional context

This would especially be useful for buttons, to indicate that something is clickable.

Currently, when eww is run as detached (using -d), stdout and stderr are fully silenced (stdout being closed and stderr being redirected to /dev/null, as closing stderr breaks gtk).

Instead, both output streams should be redirected to a log file (with some system to manage the amount of data being stored), and be available using a eww logs subcommand.

Acceptance criteria

• When detached, output of both stdout and stderr is being redirected to a log file
• The log-file is somehow managed to delete old and irrelevant logs (Look into how other applications mange this)
• Eww provides a subcommand logs which shows any new logs that are written, simmilar to tail -f. This will need to be managed on the client as well. Thus, an abstraction that allows for commands to be handled directly by both the first (server) process as well as any IPC client processes needs to be implemented. This should simply allow for handling a subset of the commands before trying to connect to the IPC server.

Describe the bug

Exactly what the title says. Vars get executed even when the windows referencing them are not open.

Reproducing the issue

Launch eww daemon, open some windows and close them. Use RUST_LOG="eww=debug" eww daemon to view the logs. This gets even more noticeable when you have something like sliders which you might want to execute every millisecond. I noticed it when I was doing that as well. (CPU fans go brrrrrrr)

Expected behavior

Don't execute dem vars.

Additional context

Logs go brrrrrrr.

Describe the bug

When launching multiple windows through a script (mainly to bind these sets of widgets to a keybind on a window manager) eww sometimes... well, just breaks down with OS error 98: address not available.

Reproducing the issue

Take any sample script, make it ready to launch multiple ewws, and bind the script to your window manager. Pressing the keybind sometimes works, sometimes doesn't, not to mention starting of only some widgets, which, of course, looks weird.
killall eww or eww kill work, that's what I had been using to reproduce the issue. The issue happens a bit less often I haven't noticed it happening if eww -d is running and you only close the windows

Expected behaviour

All windows to be launched properly and without delay.

Additional context

Will upload screenshots soon

Description of the requested feature

I would like to have a variable CSS property, say, one that changes based on the time of day.

Proposed syntax

Inline CSS via an XML property is already supported, so feeding that through the same expansion as existing text should do fine. Users could then add a tag style="color: {{my_color}}" and have it updated appropriately.

The current implementation of how eww makes use of IPC is flawed in several ways:

• it is ugly. very ugly.
• It provides no way for the server process to send response output to the client process
• It is inefficient.

This needs to be improved.

Acceptance criteria:

• Eww does not start up a new IPC server after every connection, thus improving efficiency
• Eww cleanly implements a "try to connect, start server if it fails" system that first checks if a server process is already running, and otherwise starts up the server itself.
• There is a simple way to communicate back from the server to the client process, to allow for meaningful output for the user.

Describe the bug

I've been trying to build eww on macOS (currently 10.14.6 but that shouldn't matter much) after installing rustc and cargo as told in the instructions, and I've run into some hurdles:

First I got a no cairo package found message, so I installed cairo, then it was pango, then atk, at which point I learned that this was all gtk related so I installed the gtk+3 package with homebrew (the unofficial but widespread package manager on macOS)

Following that I tried building eww again, and here's the result:

➜  eww git:(master) cargo build --release
   Compiling gdkx11-sys v0.10.0
error: failed to run custom build command for `gdkx11-sys v0.10.0`

Caused by:
  process didn't exit successfully: `/Users/vermoot/Projects/eww/target/release/build/gdkx11-sys-63812bde4a87a546/build-script-build` (exit code: 1)
  --- stdout
  cargo:rerun-if-env-changed=GDK_X11_3.0_NO_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG
  cargo:rerun-if-env-changed=GDK_X11_3.0_STATIC
  cargo:rerun-if-env-changed=GDK_X11_3.0_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_STATIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64-apple-darwin
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64_apple_darwin
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64-apple-darwin
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64_apple_darwin
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64-apple-darwin
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64_apple_darwin
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR

  --- stderr
  `"pkg-config" "--libs" "--cflags" "gdk-x11-3.0" "gdk-x11-3.0 >= 3.14"` did not exit successfully: exit code: 1
  --- stderr
  Package gdk-x11-3.0 was not found in the pkg-config search path.
  Perhaps you should add the directory containing `gdk-x11-3.0.pc'
  to the PKG_CONFIG_PATH environment variable
  No package 'gdk-x11-3.0' found
  Package gdk-x11-3.0 was not found in the pkg-config search path.
  Perhaps you should add the directory containing `gdk-x11-3.0.pc'
  to the PKG_CONFIG_PATH environment variable
  No package 'gdk-x11-3.0' found

According to what I found there is no way to install gdk-x11 on macOS, so I've hit a dead end and I'm not able to build eww.

Reproducing the issue

Be on macOS. Try to build eww with my limited knowledge.

Expected behaviour

Build eww.

Additional context

MacbookPro11,1
macOS Mojave 10.14.6

Description of the requested feature

It would be helpful to have the option to render based on a condition. This would enable more flexible modifications, say, changing the layout based on user input. This would remove the need for the current clumsy work-around: on a user action, run a script that closes the old window and opens a new one.

Proposed configuration syntax

Just replicate <script-var>; maybe call it <cond-var> or similar. Have it run the enclosed command, but just capture the shell return code.

Describe the bug

When on macOS, the eww window is only visible on the one space it's been started from.

Reproducing the issue

Use eww on macOS.

Expected behaviour

The window should be sticky, appearing on all spaces or following the user around

Additional context

I guess that could either be fixed by actually making the window visible on all spaces, or it could also be solved by making the window a proper detectable window according to macOS, which would emable the user to make it sticky through their WM

The max_char attribute would, well, set the maximum character limit. So for e.g if we set it to max_char="25" the maximum character limit would be 25 characters.

It would be nice if <window> had an attribute called use-struts and that would then make whatever window manager treat the eww window as a panel by having it only take up its own space. This can be done by setting _NET_WM_STRUT for X11.

now that documentation is mostly taken care of, the main thing missing to make eww approachable is good examples. These examples should include both the css and xml and explain how and why things are used the way they are. It should also be shown how a script can be used to change the eww-state from outside. The use of the literal tag as well as script vars (both interval and tail) should be included.

These examples may in the future be used in the CI-pipeline as a means of veryifying that changes don't brake existing functionality.

acceptance criteria

• example widget config fulfilling the criteria stated above is implemented.
• screenshots showing the widgets are provided.
• examples are mentioned in the appropriate places in the documentation.

Description
CPU and RAM usage variables for cpu and ram usage monitors.

Configuration syntax
In a box you could put like, <cpu></cpu> or something like that and then configuration and label formatting goes elsewhere

Describe the bug

It's impossible to use SCSS variables in eww.scss. The way that eww parses the SCSS files means that any tokens that look like $myvariable get swapped with an environment variable. If the environment variable does not exist, the token gets swapped with a null value, producing invalid SCSS and a null stylesheet.

Reproducing the issue

Specify a SCSS variable in eww.scss. Using a variable name that isn't specified in the environment generates an invalid scss file and causes the widget to be unstyled.

// eww.scss
window {
  background: #121212;
}

$red: #AE2955;
.red {
  color: $red;
}

scale trough {
  all: unset;
  min-height: 5px;
  border-radius: 50px;
  background-color: darken($red, 20%);
  min-width: 150px;
}
highlight {
  all: unset;
  background-color: red;
  background-color: #ae2955;
  color: rgba(0,0,0,0);
}
slider {
  all: unset;
}

<eww>
  <definitions>
    <def name="controls">
      <box class="sidebarContainer controls" orientation="v">
        <box class="red" space-evenly="false" halign="center">
          <box class="icon">
            ☼
          </box>
          <scale min="0" max="100" value="10"></scale>
        </box>
      </box>
    </def>
  </definitions>


  <windows>
    <window name="controls_side">
      <geometry x="50px" y="210px" height="100px" width="250px"/>
      <widget>
        <controls />
      </widget>
    </window>
  </windows>
</eww>

Expected behaviour

Display proper styles while using the specified SCSS variable.

Additional context

Current behavior

Expected behavior

Possible solutions

1. Swapping environment variables after the SCSS->CSS conversion
   • Unfortunately this would not work because any undeclared environment variables would throw an error in the SCSS->CSS conversion step
2. Change the environment variable syntax as to not conflict with SCSS (e.g. ${MY_ENV_VAR})
   • Would break existing configs that use environment variables, but would prevent a collision with existing SCSS syntax.
3. Leave $myvar strings alone when there is not an environment variable to swap it with
   • The current behavior swaps undefined $variables with an empty string. It feels like we could happily leave these variables alone and win SCSS variables, but we could run into a situation where there's a name collision with a SCSS variable and we're back at square one; fails to compile when $CWD: #000 gets turned into /home/user/: #000... contrived, but possible.
4. Intelligently create a list of SCSS variables and don't swap these when we're looking for environment variables

• grass's API is not that open, I don't think this is reasonable to do.

I'm most okay with option 3 if there's a more verbose error message that tells me why my SCSS failed to compile. That allows the user to resolve the issue with their SCSS file.

Any other solutions?

Eww should support an <includes> block that allows users to include XML from other files.

This block should be placed at the same level as <definitions>, <variables> and <windows>, and have the following shape:

<includes>
  <file path="./something.xml"/>
  <file path="./somethingelse.xml"/>
</includes>

every one of these files should follow the same structure as the main eww.xml file, and may themselves contain other includes.

At parse time, all the includes should first be parsed into their own EwwConfig instance, which should then be merged into one combined EwwConfig.

For error messages to stay helpful, the text position of each WidgetUse should be expanded into a new struct which also stores the path to the file it was read from. This should then be included in the Display implementation of said struct.

In a later version of this, a namespacing system should be introduced, but that is not part of this issue.

Acceptance Criteria

• The EwwConfig parser is expanded to allow for a new block: <includes>, which contains a list of files to include.
• Included files are parsed as EwwConfigs and then merged together
• Error messages that show line-numbers correctly contain the path to the file the error originated in
• File paths are correctly resolved relative to the current file
• Tests are written to show that the implementation of merging EwwConfigs is correct

Not sure if it's always just 1px thick or if it's just like that because of the way my layout is, but there's a border around tags.
Using the GTK debugger I've discovered it was due to the gtkFrame having a property named shadow-type that was set to GTK_SHADOW_ETCHED_IN instead of GTK_SHADOW_NONE.

A script-var that is only executed once, such as to display static content, should be added.

Acceptance criteria

• <script-var> supports interval="never" (or something better, if there are any proposals), which will only run the script once.
• said script-vars are not included in the script-var-handler schedulers at all.

Describe the bug

A Error while running script-var command: invalid utf-8 sequence of 1 bytes from index 0 invalid utf-8 sequence of 1 bytes from index 0 error from a specific <script-var>, i have similar script vars that doesn't give this error.

The script is this:

<script-var name="radius" interval="500s">
  curl wttr.in/stocka | awk '{if (NR&gt;5) if (NR&lt;7) print}' | tr -d [:blank:\] | sed 's .\{55\}  ' | sed 's/\x1B\[[0-9;]\{1,\}[A-Za-z]//g' | tr -d '‘' | sed 's .\{2\}  '
</script-var>

It's only this script-var as well, i get the error even if i don't {{refrence}} it anywhere. The script worked yesterday (At the time of writing.) I have a similar script var that looks almost identical other than it awk's another line. (Basically changes the awk '{if (NR>5) if (NR<7) print}' to awk '{if (NR>4) if (NR<6) print}')

If i run the same command in a terminal it works just fine.

Reproducing the issue

Add

<script-var name="radius" interval="500s">
  curl wttr.in/stocka | awk '{if (NR&gt;5) if (NR&lt;7) print}' | tr -d [:blank:\] | sed 's .\{55\}  ' | sed 's/\x1B\[[0-9;]\{1,\}[A-Za-z]//g' | tr -d '‘' | sed 's .\{2\}  '
</script-var>

to <variables>

Expected behaviour

Run the script and show what's it's supposed to show.

Additional context

It gives the error, but continues on starting eww, but no eww window shows, says it's running in htop and i can kill it will pkill eww

The configuration system of Eww needs to be documented.

Acceptance criteria
Documentation should explain:

• Placement and naming of configuration files
• Different types of variables and how to reference & declare them
• How to define user-defined widgets in the <definitions> block
• All things you can configure in windows
• How GTK-theming is used and where to look for documentation related to the GTK theming
• A quick explaination on how to use the GTK-debugger to understand the structure of a widget

not part of this issue is documenting all the specific built-in widgets!

Description of the requested feature

There should be a eww daemon command which just starts eww in detached mode, without running anything else. This could then be used to launch the eww daemon on startup, making everything including the first widget startup quick

Trying to create a widget with muliple classes like <button class="class1 class2"> results in none of this classes being applied to the widget.

The resolve-implementation introduced in #26 is likely to bring significantly more overhead, as every value - even single, primitive values - are now handled as a List of possible VarRefs.
This could be optimized, at the cost of readability.

Acceptance criteria

• A better understanding of the performance implications of the current implementation is gained
• If concluded that optimizations would make sense, the code is thusly optimized implemented