github-starred/keycastr

Fork 0

mirror of https://github.com/keycastr/keycastr.git synced 2026-05-15 14:15:50 -06:00

[GH-ISSUE #33] [wish] Mouse tracking visualizer #28

New issue

Open

opened 2026-05-05 04:45:42 -06:00 by gitea-mirror · 6 comments

gitea-mirror commented

2026-05-05 04:45:42 -06:00

Owner

Originally created by @twardoch on GitHub (Aug 30, 2015).
Original GitHub issue: https://github.com/keycastr/keycastr/issues/33

I'd like to propose a new visualizer: the "Mouse tracking" visualizer.

The Araelium Screenflick app ( http://www.araelium.com/screenflick ) has an absolutely wonderful feature that allows me to display the keyboard modifiers (connected with mouse actions) next to the mouse cursor rather than in a fixed position. It's enormously effective and instantly makes sense — see for yourselves:
https://youtu.be/u_rSk5Kb0BI

In fact, such mode would be absolutely perfect to visualize all keystrokes!

Basically, instead of designating a fixed location with some huge keystroke modifier display, I'd like to be able to define a small area (with a customizable x/y distance from the mouse pointer) that would display the keystroke visualization always near the mouse pointer. In reality, the viewers typically follow the mouse pointer with their eyes, so having a secondary fixed position where the keystroke callouts are shown will always be distracting.

In such a visualizer, the ideal keystroke display would work so that:

If a keystroke is tapped short, then it is shown for a customizable time (say 1.5 seconds) and then fades away.
If the keystroke is held for longer, then it is shown for the duration of the holding (without repetition, i.e. if I hold "a" for longer, then it should just show "a", not "aaaaaaa"), and then fades away immediately when I release the keystroke.
Optionally, single-key alphabetic keystrokes should be displayed in uppercase (i.e. if I press the "A" key, it should display "A", not "a", since keys are labeled with uppercase letters).
All modifiers, including Shift, should be visualized, both if they are pressed by itself (i.e. I hold Shift or Cmd), or in combination (i.e. I press Shift+A).
There should be an ability to disable the fade in/out effects, so the show/hide is "hard". Such fade in/out effects eat up bandwidth enormously if I'm screen recording and my ultimate goal is to export short clips to animated GIFs.
I can determine the size of the visualizer and possibly the color & transparency of the box (mostly transparency).

Originally created by @twardoch on GitHub (Aug 30, 2015). Original GitHub issue: https://github.com/keycastr/keycastr/issues/33 I'd like to propose a new visualizer: the "Mouse tracking" visualizer. The Araelium Screenflick app ( http://www.araelium.com/screenflick ) has an absolutely wonderful feature that allows me to display the keyboard modifiers (connected with mouse actions) next to the mouse cursor rather than in a fixed position. It's enormously effective and instantly makes sense — see for yourselves: https://youtu.be/u_rSk5Kb0BI In fact, such mode would be absolutely perfect to visualize all keystrokes! Basically, instead of designating a fixed location with some huge keystroke modifier display, I'd like to be able to define a small area (with a customizable x/y distance from the mouse pointer) that would display the keystroke visualization always near the mouse pointer. In reality, the viewers typically follow the mouse pointer with their eyes, so having a secondary fixed position where the keystroke callouts are shown will always be distracting. In such a visualizer, the ideal keystroke display would work so that: 1. If a keystroke is tapped short, then it is shown for a customizable time (say 1.5 seconds) and then fades away. 2. If the keystroke is held for longer, then it is shown for the duration of the holding (without repetition, i.e. if I hold "a" for longer, then it should just show "a", not "aaaaaaa"), and then fades away immediately when I release the keystroke. 3. Optionally, single-key alphabetic keystrokes should be displayed in uppercase (i.e. if I press the "A" key, it should display "A", not "a", since keys are labeled with uppercase letters). 4. All modifiers, including Shift, should be visualized, both if they are pressed by itself (i.e. I hold Shift or Cmd), or in combination (i.e. I press Shift+A). 5. There should be an ability to disable the fade in/out effects, so the show/hide is "hard". Such fade in/out effects eat up bandwidth enormously if I'm screen recording and my ultimate goal is to export short clips to animated GIFs. 6. I can determine the size of the visualizer and possibly the color & transparency of the box (mostly transparency).

gitea-mirror added the

enhancement

label 2026-05-05 04:45:42 -06:00

gitea-mirror commented

2026-05-05 04:45:47 -06:00

Author

Owner

@luiscobot commented on GitHub (Sep 4, 2015):

+💯

@luiscobot commented on GitHub (Sep 4, 2015): +:100:

gitea-mirror commented

2026-05-05 04:45:51 -06:00

Author

Owner

@akitchen commented on GitHub (Oct 31, 2015):

That's a really cool idea, and possible...

@akitchen commented on GitHub (Oct 31, 2015): That's a really cool idea, and possible...

gitea-mirror commented

2026-05-05 04:45:54 -06:00

Author

Owner

@vichug commented on GitHub (Oct 31, 2015):

i'd add that it would be even cooler to have a possibility to see a left or right clic :) (or even left ? or roll ? or any mouse button !!!) - not sure if that's beyond the scope of this present application, though.

@vichug commented on GitHub (Oct 31, 2015): i'd add that it would be even cooler to have a possibility to see a left or right clic :) (or even left ? or roll ? or any mouse button !!!) - not sure if that's beyond the scope of this present application, though.

gitea-mirror commented

2026-05-05 04:45:58 -06:00

Author

Owner

@sdeken commented on GitHub (Sep 21, 2016):

It should be possible in theory to develop a visualizer that follows the mouse, and I think that's a great side project (along with the emacs-style keys from https://github.com/keycastr/keycastr/issues/59). We may want to start a separate incubator for the visualizer projects.

For the mouse events we're going to need to enhance the app to provide an event source for the mouse events, and then pipe them through to the visualizers in the same way we send the key events. Then we'd have to update the visualizers to support the mouse events (displaying which buttons are being held down, etc.). I'd like to see this in 1.0, it feels like a natural extension of what we have now.

@sdeken commented on GitHub (Sep 21, 2016): It should be possible in theory to develop a visualizer that follows the mouse, and I think that's a great side project (along with the emacs-style keys from https://github.com/keycastr/keycastr/issues/59). We may want to start a separate incubator for the visualizer projects. For the mouse events we're going to need to enhance the app to provide an event source for the mouse events, and then pipe them through to the visualizers in the same way we send the key events. Then we'd have to update the visualizers to support the mouse events (displaying which buttons are being held down, etc.). I'd like to see this in 1.0, it feels like a natural extension of what we have now.

gitea-mirror commented

2026-05-05 04:46:01 -06:00

Author

Owner

@porg commented on GitHub (May 20, 2022):

I made a UX design proposal to enhance Svelte with some further options which would enable your user goal.

The key option would be: ☑️ Display relative to mouse cursor: X: [ +10 ] px Y: [ 0 px ]
Plus clever color/alpha-transparency, resizing, possibility to hide the upper part (non-modifier key area)
Alltogether enabling you what you want to do. Read the details over there and 👍 upvote it if you like it.

@porg commented on GitHub (May 20, 2022): I made a [UX design proposal](https://github.com/keycastr/keycastr/issues/155#issuecomment-1132653281) to enhance Svelte with some further options which would enable your user goal. - The key option would be: ☑️ Display relative to mouse cursor: X: [ +10 ] px Y: [ 0 px ] - Plus clever color/alpha-transparency, resizing, possibility to hide the upper part (non-modifier key area) - Alltogether enabling you what you want to do. Read the details over there and 👍 upvote it if you like it.

gitea-mirror commented

2026-05-05 04:46:03 -06:00

Author

Owner

@flyisland commented on GitHub (Feb 20, 2025):

I wanted to raise an issue about adjusting the positioning of the displayed keys, but then I came across this issue. I like this concept and it's much more comprehensive!

@flyisland commented on GitHub (Feb 20, 2025): I wanted to raise an issue about adjusting the positioning of the displayed keys, but then I came across this issue. I like this concept and it's much more comprehensive!