I made some screensavers that you can have run after a period of inactivity in your terminal. I'm using bevy to generate frames and then ratatui/ratatui-image, through my plugin bevy_ratatui_render (https://github.com/cxreiff/bevy_ratatui_render), to render those frames. The period of inactivity part only works in ZSH because I'm using the TMOUT env variable– please let me know if you know another way!
GNU screen has a `lockscreen` option with a $LOCKPRG environment variable, and an `idle` command that can do `idle 300 lockscreen`.
tmux has `lock-command` / `lock-after-time`.
You could implement a screensaver on top of those... they only "lock" as much the $LOCKPRG / lock-command chooses to lock them, no reason a single keypress can't "unlock" the screen if it's just a screensaver.
Those will be invoked regardless of whether a program is running or it's sitting at the prompt. Since tmux and screen are terminal emulators, the underlying shell and programs running in them won't even be aware of the screen saver.
I have my friend's garage NAS set to use `cmatrix` as a lockscreen on the system console and mine uses `glances`.
Oh, thank you! I'll look into this. I'm a little apprehensive of tmux because I've had it mess with ANSI colors before, which this relies heavily on. But it would let me get this to trigger while things like neovim are open, so maybe worth it...
I am personally using https://github.com/st3w/neo (from the Matrix) as my screensaver. Feels good to feel yourself looking at that side of the world from time to time :)
This is great, I've been wanting to do something like this after finding an old series about making games in the terminal (https://www.youtube.com/watch?v=xW8skO7MFYw). I'll need to checkout bevy now.
Bevy lets you create a custom render pipeline, so you just have to get the rendered image and send it to ratatui instead of a window. I handled that part in bevy_ratatui_render (https://github.com/cxreiff/bevy_ratatui_render) which just gives you a bevy Camera and a ratatui Widget that draws the latest frame.
I was wondering how did you manage to translate WGPU code into Ratatui code, but I guess there was no WGPU in the first place. Actually, it is kinda cool that you can switch renderers in Bevy, meaning you can take advantage of whatever API you may want.
The cool thing with Bevy is that every built-in feature is in fact a `plugin` and can be disabled or replaced with a custom implementation.
Tiny glade[1], the first commercial success of a Bevy game, use Bevy but with their own renderer (IIRC they also replace other parts of Bevy but I don't remember which).
There is an interview with the Tiny Glade developer which contains a bit more about why Bevy and how it's being used:
> And when it comes to the engine and the tech, Anastasia started with Bevy because it was the easiest thing to jump into, and we're still using a modified version of Bevy to this day. Technically, at the base level we have the framework called the ECS, or Entity Component System, which is the way to define the game objects and how they work, basically the lifeblood of everything happening within the game. Initially, Anastasia's prototype was using Bevy for everything, including rendering, but eventually, our needs outscaled what Bevy could provide at the time, as the need for the project was to have prettier graphics and better procedural generation on the GPU.
That would be cool! But this is a fairly different/incompatible approach- here each frame is generated by the GPU using an actual game engine (bevy) and then printed to the terminal instead of a window- no logic for different types of characters. Maybe in the future if I replace the ascii rendering library.
That kind of text output would be really useful, because a lot of terminals don't support images.
I am also thinking, you don't need ratatui except for the "redraw whole screen" part, right? I might try to split ratatui-image into just the rendering/protocol part, so that there could be for example a fullscreen image stream crate without ratatui.
Oh, hello! Thank you for your wonderful library, it made this very easy. :)
If there were significant performance improvements it would be useful to have a non-ratatui option in bevy_ratatui_render! But I would still keep the ratatui option for other reasons. So far I've just been making simple toys that only use bevy's render output, but as soon as you need any kind of text or UI, you'd want to layer other ratatui widgets on top of the ratatui-image widget.
I made some screensavers that you can have run after a period of inactivity in your terminal. I'm using bevy to generate frames and then ratatui/ratatui-image, through my plugin bevy_ratatui_render (https://github.com/cxreiff/bevy_ratatui_render), to render those frames. The period of inactivity part only works in ZSH because I'm using the TMOUT env variable– please let me know if you know another way!
GNU screen has a `lockscreen` option with a $LOCKPRG environment variable, and an `idle` command that can do `idle 300 lockscreen`.
tmux has `lock-command` / `lock-after-time`.
You could implement a screensaver on top of those... they only "lock" as much the $LOCKPRG / lock-command chooses to lock them, no reason a single keypress can't "unlock" the screen if it's just a screensaver.
Those will be invoked regardless of whether a program is running or it's sitting at the prompt. Since tmux and screen are terminal emulators, the underlying shell and programs running in them won't even be aware of the screen saver.
I have my friend's garage NAS set to use `cmatrix` as a lockscreen on the system console and mine uses `glances`.
Oh, thank you! I'll look into this. I'm a little apprehensive of tmux because I've had it mess with ANSI colors before, which this relies heavily on. But it would let me get this to trigger while things like neovim are open, so maybe worth it...
I am personally using https://github.com/st3w/neo (from the Matrix) as my screensaver. Feels good to feel yourself looking at that side of the world from time to time :)
This is great, I've been wanting to do something like this after finding an old series about making games in the terminal (https://www.youtube.com/watch?v=xW8skO7MFYw). I'll need to checkout bevy now.
Wow, didn't know you could do that with bevy!
Bevy lets you create a custom render pipeline, so you just have to get the rendered image and send it to ratatui instead of a window. I handled that part in bevy_ratatui_render (https://github.com/cxreiff/bevy_ratatui_render) which just gives you a bevy Camera and a ratatui Widget that draws the latest frame.
I was wondering how did you manage to translate WGPU code into Ratatui code, but I guess there was no WGPU in the first place. Actually, it is kinda cool that you can switch renderers in Bevy, meaning you can take advantage of whatever API you may want.
The cool thing with Bevy is that every built-in feature is in fact a `plugin` and can be disabled or replaced with a custom implementation.
Tiny glade[1], the first commercial success of a Bevy game, use Bevy but with their own renderer (IIRC they also replace other parts of Bevy but I don't remember which).
[1]: https://store.steampowered.com/app/2198150/Tiny_Glade/
There is an interview with the Tiny Glade developer which contains a bit more about why Bevy and how it's being used:
> And when it comes to the engine and the tech, Anastasia started with Bevy because it was the easiest thing to jump into, and we're still using a modified version of Bevy to this day. Technically, at the base level we have the framework called the ECS, or Entity Component System, which is the way to define the game objects and how they work, basically the lifeblood of everything happening within the game. Initially, Anastasia's prototype was using Bevy for everything, including rendering, but eventually, our needs outscaled what Bevy could provide at the time, as the need for the project was to have prettier graphics and better procedural generation on the GPU.
https://80.lv/articles/exclusive-tiny-glade-developers-discu...
alias snow='for((I=0;J=--I;))do clear;for((D=LINES;S=++J*3%COLUMNS,--D;))do printf %*s.\\n $S;done;sleep .1;done'
zsh: parse error near `)'
Need a space after each `for` keyword.
A while back there was a whole post about making it snow in your terminal [1]. I think my favorite was [2]:
[1] https://news.ycombinator.com/item?id=38652339[2] https://news.ycombinator.com/item?id=38654884
alias snow='for ((I=0;J=--I;)); do clear; for ((D=LINES;S=++J*3%COLUMNS,--D;)); do printf %*s.\\n $S;done;sleep .1;done'
the DOOM one is fun.
I would personally like to see a set of screensavers that utilizes terminal-text-effects
Its an old windows screensaver! https://www.youtube.com/watch?v=MHGnSqr9kK8
That would be cool! But this is a fairly different/incompatible approach- here each frame is generated by the GPU using an actual game engine (bevy) and then printed to the terminal instead of a window- no logic for different types of characters. Maybe in the future if I replace the ascii rendering library.
There could be an ASCII-art-like renderer more advanced than the HalfBlocks one. Something that detects outlines and such.
Definitely something I want to do down the line... something like the Sobel filter approach that acerola uses in this video: https://youtu.be/gg40RWiaHRY?si=DWtt-fdSUVADFNS_
BTW I'm the author of ratatui-image :)
That kind of text output would be really useful, because a lot of terminals don't support images.
I am also thinking, you don't need ratatui except for the "redraw whole screen" part, right? I might try to split ratatui-image into just the rendering/protocol part, so that there could be for example a fullscreen image stream crate without ratatui.
Oh, hello! Thank you for your wonderful library, it made this very easy. :)
If there were significant performance improvements it would be useful to have a non-ratatui option in bevy_ratatui_render! But I would still keep the ratatui option for other reasons. So far I've just been making simple toys that only use bevy's render output, but as soon as you need any kind of text or UI, you'd want to layer other ratatui widgets on top of the ratatui-image widget.
Right, in the end you want some library for dealing with the terminal, and ratatui has no meaningful performance impact.