valebes / rsclock Goto Github PK

It would be nice to be able to disable foreground/background layers independently or perhaps make them transparent to reveal only one.

cargo install rsclock throws an error when using stable-x86_64-pc-windows-gnu.
unresolved import 'sys' in termion dependency

Hi as of now, each update to rsClock adds entire frame to scroll back buffer. It happens on both in iTerm2, and also in tmux in Alacritty.

Command used:

>>rsclock -S -c

Here's a video:

Add a way to pass a clock offset, and a legend/title. That will enable using rsclock as a world-clock & users will be able to see the times from different regions of the world in split terminal screens like supported by tmux.

Currently only one location's time is visible, with ability to specify clock offset, each of the clocks in image below would be a different city:

Instead of standard YYYY-MM-DD, it would be nice to let user pass an option for the format of date.

For instance -f "%a, %d %b %Y %z" would print something like Mon, 26 Jul 2021 -0700 [PM]

Add option for 12-hour mode, when enabled a label [AM]/[PM] would be visible in the date line like " 2021-08-04 [PM]"

Then rsClock can be integrated in other dashboard tools like https://wtfutil.com as a clock display using its CmdRunner module https://wtfutil.com/modules/cmdrunner/

Stopwatch and timer would make this a killer CLI app! Thanks

Modern GPU based terminals draw the entire frame on redraws. The way to avoid screen from stuttering is to use a different approach to redrawing screen.

The solution is mentioned in neovim/neovim#14225 (comment), and vim/vim#8002 (comment). The solution is to redraw with
NOT_VALID, which would redraw everything but not clear the screen.

This problem is similar to vim on GPU accelerated terminals also has the problem and plans to fix it: vim/vim#8002

Here's an example of screen stuttering in rsclock. I am using tmux with frame sync feature enabled. Steps for enabling sync feature are detailed here: alacritty/alacritty#4904 (comment)

You won't see this problem with traditional terminals that do not use GPU acceleration. Though the future is with terminals that use GPU acceleration -- they are fast.

As a sidenote, this screen stuttering does not happen in tty-clock (I tried with same setup & within tmux). But it doesn't guarantee all clock instances to update at same time like rsClock seems to (xorg62/tty-clock#70). Great work rsClock on that front!

Instead of typing rsclock -c -S user can type rsclock -cS

FYI, I've packaged and merged rsclock into pkgsrc main branch and it's now available for NetBSD users, http://mail-index.netbsd.org/pkgsrc-changes/2022/04/08/msg251606.html