Think it's generally useful for scripts to be able to react to workspace
changes. But also, workspaces changed deferred. We internally send a notifier
to change it and only do the actual change on notifier handling. This is an
issue if scripts want to do more than just change the workspace.
There were multiple reports on this in the past (don't make me dig them up!)
and I don't know of a good solution for them. So this handler could be a decent
workaround.
Details
Details
- Reviewers
Campbell Barton (campbellbarton)
Diff Detail
Diff Detail
- Repository
- rB Blender
- Branch
- master
- Build Status
Buildable 11693 Build 11693: arc lint + arc unit
Event Timeline
Comment Actions
@Julian Eisel (Severin) I tested the patch and apparently it works as intended. Thank you :)
Comment Actions
On a second thought i found that there is one case that can not be handled by an on change handler, that is when a script wants to modify something on a workspace other than the active one. In my special case i want to append a workspace from a library blendfile, then i want to move that workspace to the first position in the workspace list but not make it active.
The problem here: Moving a workspace in the list is only possible for the active workspace. So i tried to make the new workspace active, move to front, make the previous workspace active again. This does not work because workspace switches are deferred. This particular issue can not be nicely resolved with an on change handler. All i could do is to move my workspace to the front when the user changes the workspace, but that is really not a solution at all.
Maybe a better solution could be to allow modifying workspace parameters (like the position in the workspace list for example) regardless if they are active or not.