Can't access actually used values of macro operator properties from Python #40762
Labels
No Label
Interest
Animation & Rigging
Interest
Blender Cloud
Interest
Collada
Interest
Core
Interest
Documentation
Interest
Eevee & Viewport
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
Import and Export
Interest
Modeling
Interest
Modifiers
Interest
Nodes & Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds, Tests & Devices
Interest
Python API
Interest
Rendering & Cycles
Interest
Sculpt, Paint & Texture
Interest
Translations
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Meta
Good First Issue
Meta
Papercut
Module
Add-ons (BF-Blender)
Module
Add-ons (Community)
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
7 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender-addons#40762
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
System Information
Windows 7, 64bit
Blender Version
Broken: 2.71 RC2
Short description of error
Logged operators in
WindowManager.operators
also include Macros, but if their arguments are retrieved, they are all at their default values.Exact steps for others to reproduce the error
It will print
0, 0.0), "texture_space":False, "remove_on_cancel":False, "release_confirm":Fals
so everything False, 0.0 or whatever is default...
Changed status to: 'Open'
Added subscriber: @CodeManX
Added subscribers: @ideasman42, @LukasTonne
I may be wrong, but IIRC macro operators in fact don't have properties of their own (or at least they don't inherit properties from nested operators by default). Including nested operator properties in the macro's dict would be dangerous. How would you handle name conflicts etc.?
If anything, the nested operators' properties should be accessible as a collection inside the macro (something like
window_manager.operators[-1].macro- [x].properties
). This is actually how properties are stored for macros and how the redo panel accesses and displays them. I don't know why these are not exposed already in the RNA, maybe @ideasman42 can say?About dynamic enums: Yes, this is annoying ... In principle dynamic enums can depend on context even, but in most cases they're just used to select a fixed list based on some other property. There are classmethods in UILayout which could be used for resolving enum names, descriptions and icons, but not for mapping index <-> identifier. Something like this would be very handy (if it doesn't exist somewhere else already?).
Added subscriber: @iPLEOMAX
Use attributes instead of dictionary keys.
bpy.context.window_manager.operators[-1].properties['constraint_orientation']
bpy.context.window_manager.operators[-1].properties.constraint_orientation
The dict keys() can be used to getattr()
Changed status from 'Open' to: 'Archived'
Ah yes, @iPLEOMAX is right. The nested operator properties can be accessed as attributes. To get all their properties you could use the RNA type info:
Closing this report.
WindowManager.operators does not resolve macro propertiesto Can't access actually used values of macro operator properties from PythonChanged status from 'Archived' to: 'Open'
Re-opened, because macro operator arguments can't be accessed.
http://blenderartists.org/forum/showthread.php?340868-Get-lines-from-INFO-area&p=2674292&viewfull=1#post2674292
Added subscriber: @mont29
Yeah… I had to fight that issue in C as well, to allow the log/info window to show valid parameters in this case too, some time ago… Sounds more like a TODO to me, tbh.
IDK what the problem here is actually ...
Added subscriber: @Sergey
@ideasman42, not sure what's the design specification here, mind having a look?
Confirmed. but changing Py/RNA API right before release is too risky (unless its obvious fix for mistake)
Added subscriber: @JulianEisel
Hmm, any news here?
Asking again ;)
This issue was referenced by blender/blender@3160740421
Changed status from 'Open' to: 'Resolved'
Closed by commit blender/blender@3160740421.
Expose via operator.macros, a list of macros whos properties you can access.
This is a bit awkward but its how the data is stored internally.
Better silly than sorry ;-)