No description
0e409d4a52
* fix: improve multi-monitor handling under wayland When a monitor gets disconnected, the destroy event of all associated windows gets called, and the window gets removed. This patch changes that behavior: the window is still closed but the configuration is kept using the existing reload mechanism. In addition, a callback is added to listen for new monitors, triggering a reload when a new monitor gets connected. This logic also reloads already running windows, which has a positive and negative effect: - positive: if currently running e.g. on the second monitor specified in the list, the window can get moved to the first monitor - negative: if reloading starts it on the same monitor, it gets reset (e.g. graphs) I also had to work around an issue: the monitor model is not yet available immediately when a new monitor callback triggers. Waiting in the callback does not help (I tried 10 seconds). However, waiting outside, it always became available after 10ms. Tested with a dual monitor setup under KDE through a combinations of: - enabling/disabling individual monitors - switching between monitors - specifying a specific monitor in the yuck config - specifying a list of specific monitors in the yuck config In all these cases the behavior is as expected, and the widget gets loaded on the first available monitor (or stays unloaded until one becomes available). It also works when opening a window without any of the configured monitors being available. There is one remaining error from GTK when closing the window: GLib-GObject-CRITICAL **: 20:06:05.912: ../gobject/gsignal.c:2684: instance '0x55a4ab4be2d0' has no handler with id '136' This comes from the `self.gtk_window.disconnect(handler_id)` call. To prevent that we'd have to reset `destroy_event_handler_id`. * fix: do not call gtk::main_iteration_do while waiting for monitor model Executors that poll a future cannot be called recursively (in this case glib::main_context_futures::TaskSource::poll). So we cannot call gtk::main_iteration_do here, which in some cases led to the future being polled again, which raised a panic in the form of: thread 'main' panicked at glib/src/main_context_futures.rs:238:56: called `Result::unwrap()` on an `Err` value: EnterError We can just remove it as tokio::time::sleep() ensures the main thread continues to process (gtk) events during that time. |
||
|---|---|---|
| .github | ||
| crates | ||
| docs | ||
| examples | ||
| .editorconfig | ||
| .gitignore | ||
| Cargo.lock | ||
| Cargo.toml | ||
| CHANGELOG.md | ||
| default.nix | ||
| flake.lock | ||
| flake.nix | ||
| gen-docs.ts | ||
| LICENSE | ||
| README.md | ||
| rust-toolchain.toml | ||
| rustfmt.toml | ||
| shell.nix | ||
| YUCK_MIGRATION.md | ||
Eww
Elkowars 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.
Dharmx also wrote a nice, beginner friendly introductory guide for eww here.
Check out another cool project by me
I'm currently busy working yolk, which is a dotfile management solution that supports a unique spin on templating: templating without template files.
To find out more, check out the website and documentation!
Examples
(Note that some of these still make use of the old configuration syntax.)
-
A basic bar, see examples
Contribewwting
If you want to contribute anything, like adding new widgets, features, or subcommands (including sample configs), you should definitely do so.
Steps
- Fork this repository
- Install dependencies
- Smash your head against the keyboard from frustration (coding is hard)
- Write down your changes in CHANGELOG.md
- Open a pull request once you're finished