-
Notifications
You must be signed in to change notification settings - Fork 207
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PathFilterUI : Allow Select Affected Objects on promoted Spreadsheets #6205
PathFilterUI : Allow Select Affected Objects on promoted Spreadsheets #6205
Conversation
Thanks Murray. This seems to be working as advertised for promoted spreadsheets, but in this little test example I can't get it to work with a non-promoted spreadsheet (and it seems it didn't work before either). If I right click on the
I haven't really followed everything that is going on in |
We also use this as an excuse to simplify `_selectAffected()` and consolidate the spreadsheet handling in `__popupMenu()`.
This appears to have been broken as far back as 1.2.0.0. File "/opt/gaffer-1.2.0.0-linux/python/GafferSceneUI/PathFilterUI.py", line 213, in __popupMenu selection = IECore.PathMatcher( plugValueWidget.vectorDataWidget().getData()[0] ) IndexError: list index out of range
Thanks for the feedback! I tracked down the issue in your example and have addressed it in 889c6e6, taking the opportunity to simplify In testing I found another existing bug related to the use of "Select Affected Objects" on cells in Spreadsheet columns created from a
|
This was confusing for several reasons : - Several callers passed `targetPlug` to the `plug` argument, but then internally `targetPlug` was acquired again separately. - The `plug` argument could be either a StringVectorDataPlug used to find a PathFilter, or a ScenePlug, but this wasn't documented. Now, `_selectedAffected()` is much dumber, and just takes a PathMatcher and a list of ScenePlugs, and selects the matching paths. All logic about where the scenes and PathMatchers come from is now on the client side.
Since the refactoring of `_selectedAffected()` we are no longer using the plug, and only care about finding a PathFilter. So we replace `_targetFilterPlug()` with a more descriptive `_destinationPathFilter()`. This removes the last use of the could-mean-anything `targetPlug` variables.
Thanks Murray - all your fixes are working nicely for me. For some reason, I still found this code very hard to read, I think mostly due to the vague and inconsistent usage of |
Thanks John, those commits are a definite improvement in clarity and do pass the majority of my test cases. Where they didn't pass was in the simple case of a disconnected PathFilter where I would prefer to go forward with your changes so I've pushed a commit that better handles that error case, and would be happy to see this merged if my changes make sense to you. |
Thanks for the additional fix - I've gone ahead and merged. |
This can be particularly useful for investigating paths on Processors inside of EditScope nodes.