Ego Monger is the lucky one again.  That's why the central coast is the most prized real estate in the world. 

----------------------------------------------------------------------------------------------------------------

Screencap improvements continued slowly.  The big problem was creating a freetype wrapper.  The affair reminded lions of the time they made the timeline draw vertically to pack in more frames of widescreen video.  That feature was never used, but it entailed drawing text in offscreen pixmaps, reading back the pixmaps, rotating them, & drawing them again.

In modern times, vertical text would all be drawn with freetype.  In the old days, it would have been extremely slow to use freetype compared to screencapping offscreen pixmaps.  It probably could have used its own font renderer to draw a fixed point font.

The big question was where to draw the keypresses.  When no cursor is captured, the text needs to be in a fixed position.  When the cursor is captured, the presumed behavior is for the text to follow the cursor, but it could be really hard to read if the user is moving the cursor.  It's all being hard coded as if no-one else is ever going to use it.  1 soft coded need might be a selector for the text position, but it still needs borders.

Another option is just drawing the mouse state near the pointer or only drawing keypress state when the pointer is enabled.  Keypresses could always be drawn on the bottom center like subtitles.

Then of course, the user input could be captured in a text file & the text file played back in an effect.  Then it could be customized after the recording.  It creates the problem of specifying a text file.  It's a bit over complicated for what it is.

-----------------------------------------------------------------------------------------------------------------

The 1st tests of keyboard capture were pretty clumsy & showed it's a bigger problem than envisioned. It's 1 of those things which is either going to require a lot of testing & fiddling to get right or become just a toy. 

 1 problem is conveying when multiple keys are pressed simultaneously & when only 1 key is down when all the keypresses have a timed display.  We don't want to show a modifier & an alnum simultaneously if they're not pressed simultaneously.

 If the user has to hold down the alnum keys until they show, they'll repeat but the modifiers won't.

Timing out the up keys when multiple keys are down is problematic.  If they're not all released simultaneously,  it'll only show the most recent key down.  

A big problem is if you type faster than the framerate, it won't show the keypresses at all or it'll show keys as simultaneously pressed when they only overlapped in 1 frame.

Ideally, it would show the last few alnum keypresses as a string, but when SPACE is 1st or last it needs to write SPACE.  When space is between letters, it needs to show a space character.

The fact is in practical use, the user is always going to enter strings in a visible text area so the overlay doesn't need to show typing as a string.  If they're entering a command, they're usually pressing just 1 alnum per frame.  Some tests recording the use of the screen program were pretty insightful.

Some keys like . are pretty hard to see in the screen cap.  It almost needs a subtitle bubble like gootube instead of an outline algorithm.

There are a lot of corner cases. It makes lions appreciate the magic that goes into all those tiktok overlays.