| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Use rna naming conventions for unit-settings callbacks.
|
|
Now its possibly to ask for only keyboard/mouse/ndof events
when finding key map items.
|
|
|
|
|
|
This is needed for keymaps to define their own options,
which can include left/right mouse select.
This can also help to us to provide popular keymap tweaks as options,
so users can easily fit blender to their workflow with well supported
adjustments which don't give the overhead of having to maintain
your own keymap, which become out-dated when operators change.
|
|
For Blender builtin configurations the option to choose the select mouse remains
and is now also in the splash screen. It works by changing the keymap dynamically
in the script, rather than using special events.
The system of automatic switching of events was not flexible enough to deal with
side effects that require further keymap changes, so it is now under more manual
control in the script.
This breaks compatibility for some scripts and exported key configurations.
These can be fixed by replacing SELECTMOUSE, ACTIONMOUSE, EVT_TWEAK_S and
EVT_TWEAK_A with appropriate LEFTMOUSE, RIGHTMOUSE, EVT_TWEAK_L and
EVT_TWEAK_R events.
Other than that, there should be no functional changes.
|
|
|
|
Without this bugs slip through that don't null check the descriptions
since many were set to empty strings.
|
|
Not sure why but MSVC is complaining for some of those.
In particular for the struct in BKE_subdiv_ccg.h. Those were the ones
crashing here..
|
|
|
|
|
|
For now, that flag is only used in redo code, since after undo step
depsgraph is totally empty... We *may* want to add at least an assert in
op calling code too, though?
|
|
|
|
Missed when changing callbacks from int to bool type.
|
|
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.
|
|
|
|
|
|
|
|
We were using int's for bool arguments in BKE,
just to avoid having wrapper functions.
|
|
|
|
|
|
|
|
This allows for a single key to be mapped to both release and drag,
useful for pie menus to share a key with a different action.
|
|
- UILayout.popover(.. panel_type ..)
A single panel
- UILayout.popover_group(.. panel categories ..)
Expands all panels matching args.
Currently used in the topbar for redo and paint options.
|
|
|
|
Also rename pupmenu -> popmenu
|
|
This caused too many problems syncing object modes
with multiple objects/windows/workspaces, see: D3130 for details.
|
|
Allows for each workspace to have it's own add-ons on display.
Filtering for: Panels, Menus, Keymaps & Manipulators.
Automatically applies to add-ons at the moment.
Access from workspace, toggled off by default
once enabled, add-ons can be white-listed.
See D3076
|
|
|
|
|
|
- Read-only access can often use EvaluationContext.object_mode
- Write access to go to WorkSpace.object_mode.
- Some TODO's remain (marked as "TODO/OBMODE")
- Add-ons will need updating
(context.active_object.mode -> context.workspace.object_mode)
- There will be small/medium issues that still need resolving
this does work on a basic level though.
See D3037
|
|
|
|
|
|
|
|
|
|
When using a tablet, detecting absolute motion only worked
when activating a tool with the tablet.
Pressing Enter to run a tool for e.g. would use relative motion.
Now store is_motion_absolute in the event,
set for new events based on the most recent motion events.
|
|
This fixes renaming via the interface.
This bug was introduced originally in 9515737b554. We need the id of the RNA
property to be the one that owns the data (view layer).
So it can't be the window's id, but the scene one instead.
|
|
Needs to use new messaging system.
|
|
Instead of storing a single active view-layer in the workspace, one is
stored for each scene the workspace showed before.
With this, some things become possible:
* Multiple windows in the same workspace but showing different scenes.
* Toggling back and forth scene keeps same active view-layer for each scene.
* Activating workspace which didn't show current scene before, the current view-layer is kept.
A necessary evil for this is that accessing view-layer and object mode
from .py can't be done via workspace directly anymore. It has to be done
through the window, so RNA can use the correct scene.
So instead of `workspace.view_layer`, it's `window.view_layer` now (same
with mode) even though it's still workspace data.
Fixes T53432.
|
|
This will later be used to show advanced operator properties separate from
basic (as in non-advanced) ones in the UI.
Tagging a single operator property in C should be done via
`WM_operatortype_prop_tag()`. It does additional checks for type safety
that `RNA_def_property_tags()` doesn't do.
To avoid having to tag each advanced property individually, multiple
ones can be tagged by wrapping them into
`WM_operatortype_props_advanced_bein()` and
`WM_operatortype_props_advanced_end()` calls. It's also possible to only
call `_begin()`, all properties added after this will get tagged then.
In most cases this last approach should be sufficient.
Example of Python usage:
`my_float = bpy.props.FloatProperty(name="Some Float", tags={'ADVANCED'})`
|
|
|
|
Practically all access to enum data is read-only.
|
|
|
|
Operators and their properties are two different types
Previously both operators and their properties are added
causing C operators to access the properties, Python the classes.
Favor consistency in this case so only Python classes are added.
|
|
|
|
Only add subclasses of: Menu, Panel, Header, UIList, Operator
This helps avoid unnecessary naming collisions,
See T52599 for details
|
|
|
|
|
