I'm ElKowar, or Elk, Elko, or the Elk o' war!
I like to work on various projects and enjoy functional, declarative programming.
ElKowars wacky widgets
Home Page: https://elkowar.github.io/eww
License: MIT License
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...
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%" />
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.
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.
There's no need... I think
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>
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.
Just replicate <script-var>
; maybe call it <cond-var>
or similar. Have it run the enclosed command, but just capture the shell return code.
Trying to create a widget with muliple classes like <button class="class1 class2">
results in none of this classes being applied to the widget.
when you display a text have \n
. it is display \n but i want it to be a new line.
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.
(when daemon running)
Command | Extraneous new line? |
---|---|
eww open [window_name] | ✓ |
eww close [window_name] | ✓ |
eww kill | ✓ |
eww daemon | ✓ |
eww -d open [window_name] | ✓ |
eww | ✓ |
eww update "x=5" | ✓ |
eww state | ☓ |
eww -h | ☓ |
(when daemon not running)
Command | Extraneous new line? |
---|---|
eww close [window_name] | ☓ |
eww kill | ☓ |
eww daemon | ☓ |
eww -d open [window_name] | ☓ |
eww | ☓ |
eww update "x=5" | ☓ |
eww state | ☓ |
eww -h | ☓ |
I believe there is a clear correlation between daemon running and new line characters getting printed.
Don't print an extra line on commands that aren't supposed to output anything.
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
I would like to have a variable CSS property, say, one that changes based on the time of day.
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.
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.
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.
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.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
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
<includes>
, which contains a list of files to include.EwwConfig
s is correctI 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.
<widget cursor="pointer">
This would especially be useful for buttons, to indicate that something is clickable.
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.The current implementation of how eww makes use of IPC is flawed in several ways:
This needs to be improved.
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.
Everything goes well ?
$ 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)
#!/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?
Run the first script, possibly by using exec foo.sh
or something along the lines of it.
Launch everything properly
I dunno
Script-variables should only be executed if they are used in any window that is open.
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>5) if (NR<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.
Add
<script-var name="radius" interval="500s">
curl wttr.in/stocka | awk '{if (NR>5) if (NR<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>
Run the script and show what's it's supposed to show.
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
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
Eww should provide a command to query the current eww state (the state of all global variables).
eww state
subcommand exists that outputs the current variable-state in a nice, machine and human readable manner.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.
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.
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>
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.
limit-width
if possible makes use of the GTK function set_max_width_chars
, and correctly limits the character width of a labelJust 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.
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.
nope.
Exactly what the title says. Vars get executed even when the windows referencing them are not open.
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)
Don't execute dem vars.
Logs go brrrrrrr.
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
When on macOS, the eww window is only visible on the one space it's been started from.
Use eww on macOS.
The window should be sticky, appearing on all spaces or following the user around
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
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.
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.
eww close all
I dunno
All provided widgets need complete documentation. This should be automatically generated from comments in the source code
Acceptance criteria
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.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.
Be on macOS. Try to build eww with my limited knowledge.
Build eww.
MacbookPro11,1
macOS Mojave 10.14.6
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.
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
All windows to be launched properly and without delay.
Will upload screenshots soon
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.
eww/src/widgets/widget_definitions.rs
Line 194 in ac8bc7d
Should say "whether"; wasn't sure whether I should make a pull request or not due to the size of the change.
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
.
Just a -c flag to specify config location, e.g eww open main_window -c ~/Documents/eww.xml
`eww open main_window -c ~/Documents/eww.xml`
just like polybar does
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.
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>
Display proper styles while using the specified SCSS variable.
${MY_ENV_VAR}
)
$myvar
strings alone when there is not an environment variable to swap it with
$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.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?
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.
{}
anywhere works correctlyThe configuration system of Eww needs to be documented.
Acceptance criteria
Documentation should explain:
<definitions>
blocknot part of this issue is documenting all the specific built-in widgets!
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.
$VAR_NAME
syntax to refer to environment variables, which will be expanded directly after the respective file is readA 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.script-var-handler
schedulers at all.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
.
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
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 && 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' && echo '' || echo ''
"/>
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.
n/a
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.
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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.