Last month I added a new feature to the Speckle Rhino connector. While working on it, I discovered that there are some limitations with handling views in the connector due to bugs and limited capabilities on the RhinoCommon side. (I still was able to add the feature by circumnavigating those limitations)
I made a thread about it on the Rhino forum, and the team responded quickly. I was able to discuss the matter with one of their developers (he sent me a PM), who informed me that a new attribute ViewInfo.NamedViewId will be added in the next Rhino stable release, version 7.28. The developer even gave me a link to the release so I could test it myself, and I found that it works well.
This new attribute has the potential to improve view handling in the Speckle Rhino connector. However, I understand that Speckle is designed to work with both Rhino 6 and Rhino 7. Since this new feature will only be available in Rhino 7.28 and higher, I am wondering whether it is desirable to make the changes required to use this feature ?
If the changes are minor, we could use conditional statements depending on the Rhino version running I guess, but if they are significant, it could be a heavy undertaking. Therefore, I would appreciate any input on this matter. Thank you!
This is an excellent first contribution to the community @MedoLucas; thank you also for your good work on the repo.
This is a great place to discuss it, but it is fair to say it could be posted as an Issue on GH too.
We are generally pretty keen on keeping up with API changes. You have probably noticed the Connectors already have branching code for Major version support, so doing so further wouldn’t be an inconceivable stretch. However, my preference for such a minor version branching would be to do so on a feature basis rather than a version one. In this case, I’d first test if that new attribute exists and respond accordingly; if not, fall back to the existing one.
If you raise an issue or go so far as last time and raise a PR, the Rhino dev team could review the best path forward.
Thanks @jonathon for making this clearer so now I know what is the best approach for a scenario like this
For this particular View handling case I think it’s doable to check the attribute existence and use it or fallback on the existing method, we can continue with this approach until the older version of Rhino is no longer supported, at which point we can remove the older, cumbersome code.
In any case if I see a potential improve with new Rhino/GH release I’ll sure raise a first draft/idea issue to get feedback from your developer before proceeding further. thank you again for your help!
This is a great place to discuss it, but it is fair to say it could be posted as an Issue on GH too.
I’m not sure if I get this right did I post on the wrong forum ? (GH = General help) or maybe you meant I should have added a Grasshopper tag to this thread ? (GH = Grasshopper)
did I post on the wrong forum ? (GH = General help) or maybe you meant I should have added a Grasshopper tag to this thread ? (GH = Grasshopper)
- sorry GH == Github