core: add capture_screenshot keybind and apprt action

[jcollie]

Advantages over OS native screenshot facilities:

• Easier to capture just a single surface without capturing parts of other splits.
• Triggerable using configurable Ghostty keybind.
• Triggerable from APIs like Applescript or other future API interfaces (CI perhaps?).
• Doesn't include any decoration added by window manager or other GUI elements.
• Doesn't include background if the surface is transparent.
• Ability to screenshot non-visible surfaces (using an API, keybind would only work on active surface).

Disadvantages over OS native screenshot facilities:

• Only captures a single surface, so can't include multiple splits.
• Doesn't include window manager decorations, or background if the surface is partially transparent.

The disadvantages aren't "real" disadvantages as including the take_screenshot action doesn't preclude the use of OS-native screenshot facilities (although scripting those may be more difficult depending on the platform).

[mitchellh]

Hm, I don't think this needs an apprt action. If we're really just doing surface screenshots, then we can implement that 100% in the renderer via a frame capture (both OpenGL and Metal have ways).

What were you thinking about implementation in the apprt? Does GTK have something higher level?

[pluiedev]

GTK allows you to snapshot an entire widget along with its children by using a WidgetPaintable, which can then be rendered into a GdkTexture via a GskRenderer and saved into a PNG file, which is pretty convenient. I'm not sure how the equivalent process would look like for a core-only approach

[mitchellh]

GTK allows you to snapshot an entire widget along with its children by using a WidgetPaintable, which can then be rendered into a GdkTexture via a GskRenderer and saved into a PNG file, which is pretty convenient. I'm not sure how the equivalent process would look like for a core-only approach

If we're only capturing the surface state, then the renderer would capture the texture, then depending on the capture screenshot config (path/image/etc.) send up various apprt actions. For example, if its copy image, we'd send up a write clipboard apprt action with image mime type data.

Of course, if we want to capture more than the raw surface, apprt is the right place to do it. But they both have their benefits, because the renderer is really the source of truth of a surface pixels unaffected by anything else.

[jcollie]

Getting the raw snapshot from the core renderer makes sense, and will make the GTK code a little simpler. There's definitely going to need to be a lot implemented in the apprt though as the core does not have a PNG encoder (wuffs does not support PNG encoding as far as I know). Plus interaction with the clipboard etc.

My work in progress for the GTK screenshot using GTK's methods for getting the image data can be seen here:
https://github.com/jcollie/ghostty/tree/gtk-screenshot