Add getter callback support for 'WM_HANDLER_TYPE_KEYMAP' type handlers
this is needed for key-maps which change based on the active tool.
Replaces 'sneaky_handler' hack which temporarily inserted a handler.
This feature is intended only for testing,
to automate simulating user input.
- Enabled by '--enable-event-simulate'.
- Disables handling all real input events.
- Access by calling `Window.event_simulate(..)`
- Disabling `bpy.app.use_event_simulate`
to allow handling real events (can only disable).
Currently only mouse & keyboard events work well,
NDOF, IME... etc could be added as needed.
See D4286 for example usage.
BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
This reverts commit 1d908bffdd.
Enough uses of repeat last expect skip-save properties to be set,
transform being the most obvious example T60777#605681.
I wanted to avoid operators having account for two kinds of 'skip-save'
but this may be unavoidable.
PROP_SKIP_SAVE is often used as a way to detect the difference between
adjusting options from the redo panel and initial execution.
Repeat last operator was executing with skip-save properties set,
preventing operators from initializing them based on the context.
Fixes 60777.
Before this Blender always needed the Wintab driver. This adds support for the
native pressure API in Windows 8+, making it possible to get pressure sensitivity
on e.g. Microsoft Surface hardware without any extra drivers.
By default Blender will automatically use Wintab if available, and if not use
Windows Ink instead. There is also a new user preference to explicitly specify
which API to use if automatic detection fails.
Fixes T57869: no pressure sensitivity with Surface pen or laptop.
Code by Christopher Peerman with some tweaks by Brecht Van Lommel.
Differential Revision: https://developer.blender.org/D4165
Only use confirmation w/ X-key since this is more likely to be pressed
by accident. Delete-key delete doesn't confirm.
Part of D3953 by @Zachman w/ edits
Displaying the labels tip immediately feels too intrusive,
make this work more like regular tooltips, displaying more quickly.
Tooltips can now uses multiple passes, each pass with it's own delay
for the next pass to show.
Without this, there was no simple way to have
launchers for different app-templates.
Also allows force-disabling the app-template stored in the preferences.
Add tool options to control how select operates (add/sub/set/and/xor).
Note: edit mode armature select still needs to support all options,
this is complicated by how it handles partial end-point selection.
Currently drop operators work mostly by specifying the name of the datablock.
However there can be datablocks with the same name in different libraries, so
this gives wrong results in some cases.
Currently only outliner drop operators have been updated to use this mechanism.
This separate probe rendering from viewport rendering, making possible to
run the baking in another thread (non blocking and faster).
The baked lighting is saved in the blend file. Nothing needs to be
recomputed on load.
There is a few missing bits / bugs:
- Cache cannot be saved to disk as a separate file, it is saved in the DNA
for now making file larger and memory usage higher.
- Auto update only cubemaps does update the grids (bug).
- Probes cannot be updated individually (considered as dynamic).
- Light Cache cannot be (re)generated during render.
It was a bit odd that the scene was stored per window but not the view
layer. The reasoning was that you would use different view layers for
different tasks. This is still possible, but it's more predictable to
switch them both explicitly, and with child window support manually
syncing the view layers between multiple windows is no longer needed
as often.
* Main windows show a topbar and statusbar, and select a workspace and
scene. They are created with Window > New Main Window.
* Child windows do not show a topbar or statusbar. These follow the
workspace and scene of their parent main window. Created with Window >
New Window or View > Duplicate Area into New Window.
* The purpose of this change is to support multi monitor setups where you
just want to put more editors on the other monitors. Without multiple
topbars and statusbars, working within a single workspace and scene.
Creating multiple main windows is intended to be a concious choice to
do different tasks in different workspaces and scenes.
* Note these changes do not currently affect how the operating system
treats the windows.
* When changing the workspace, the layout in all child windows changes.
This makes sense if we consider child windows to be just a way to
extend the main window across more monitors. In some case it may be
useful to keep the same layout though, we can add an option for this
depending on user feedback.
