Screenshot Interaction

[snoyer]

Proposed feature:

Provide a key binding to render the current view to a file from within the app.

F3D already has an --output <png file> option to render as an image to a user-defined location, so implementing this feature should 🤞 be a matter of rewiring that to a key-binding and generating an appropriate filename.

Basic requirements:

• the destination filename should be computed from a configurable string template, eg. F3D-{timestamp}.png
• the default filename template should include the F3D version and OS (eg. F3D-{version}-{os}-{timestamp}.png) so users are able to communicate their F3D version and OS by just pressing the screenshot key and sending the image, without having to run f3d --version in a terminal..
• users must be able to find the file without having to know where the executable lives, saving it to the home directory seems sensible

Open questions:

• {timestamp} could mostly be a unique identifier to avoid overwriting previous images but in which case it does not need to be a human readable date/time. Would be good if it was lexicographically sortable though. Maybe base64 unix timestamp could be nice and short? if using a human readable format it would be best to pick one that wouldn't leak timezone and OS locale info when sharing the file.
• instead, or in addition to, a timestamp should we check if a file of a given name exists and append some kind of counter to make the new name unique? (F3D-blah.png, F3D-blah(2).png, F3D-blah(3).png, ...)
• what should the string template syntax be? {foo}, $(bar), %baz?
• should the full image destination be configurable, or just the filename (with the directory hardcoded)?
• if the full destination is configurable in the filename template (eg, {TEMP}/F3D-{timestamp}.png, {HOME}/F3D-{version}-{os}-{timestamp}.png) how do we deal with path separators (use / even on Windows? always accept both / and \)?
• do we need more template variables? eg. {filename} so that F3D-{filename}-{timestamp}.png would expand to F3D-my_model.glb-1234.png

[mwestphal]

any news on that @snoyer ? :)