Screencast Keys is a blender add-on to display the Keyboard/Mouse and Operation status with customizable UIs. The add-on is useful when you try to make tutorials for Blender. The main features of this add-on are as follows.
See Document to know the details of this add-on.
If you want to report bug, request features or discuss about this add-on, see ISSUES.md.
We provide the answers for the frequently asked questions. See these answers before making bug reports. If you want to have an interactive discussion, you can use screencast-keys channel on the Discord server.
If you want to contribute to or support this project, see CONTRIBUTING.md.
Indie Game/Application Developer.
Especially, I spend most time to improve Blender and Unreal Game Engine via
providing the extensions.
Support via GitHub Sponsors
Thanks for the contribution to this project.
Thanks for the sponsoring this project.
From this version, Screencast Keys add-on uses the 'MODAL_PRIORITY' option to remove the dependency of the Blender internal structure. Also, this add-on is available at extensions.blender.org.
On the other hand, this add-on only supports Blender 4.2 or later from this version. If you continue this add-on on Blender 4.1 or before, use Version 3.14 series.
This extension does not require special permissions.
We've added new mandatory fields: Featured Image and Icon. Featured Image is shown at the home page instead of the first preview image, and icon is shown in the extension's title (and later will be shown in Blender as well).
Could you please update your extension with an icon and a featured image?
Apologies for the late heads up.
I have this error when installing the add-on from disk:
Add-on not loaded: "bl_ext.user_default.screencast_keys", cause: No module named 'bl_ext.user_default.screencast_keys'
Also, could you provide a Featured image and a Logo for your extension
Add-on expects to have internet access.
Just a heads up that it seems the permission for Internet Access
is still present.
Sign in to comment.
This add-on relies on manipulating window-manager pointers using DNA offsets which may change multiple times between major releases.
I don't think this is acceptable as this will likely cause crashes when whenever the
wmWindow
struct changes which can happen at any time.Can the add-on be made functional without manipulating internal DNA data?
A more general policy for direct memory access should be created so this isn't decided on an ad-hoc basis.