now that Eto will be shipped as ‘part’ of the RhinoCommon SDK, are we going to replace System.Drawing types with Eto.Drawing types in method signatures, or provide overloads for all methods? I’d like to completely remove my references to System.Drawing in GH2, but that means every method in RhinoCommon which uses a type defined in System.Drawing is no longer available.
I don’t plan on making these changes in RhinoCommon. RhinoCommon only uses basic System.Drawing types like points, rectangles and colors which will also be available on Mac Rhino.
I also don’t plan on adding a reference to Eto from RhinoCommon. The Rhino.UI, RhinoWindows, and RhinoMac assemblies will have references to Eto.
That said, we can probably add extension methods to Rhino.UI that add Eto.Drawing functions to DisplayPipeline
We also use System.Drawing.Color in lots of other places too (object attributes, layers, UI settings). I can keep my System.Drawing references for those cases, or we can provide overloads that take ints instead of colours. Both System.Drawing.Color and Eto.Drawing.Color can convert their channel values to a single int. It’s not as friendly as methods that take actual Color structs, but it would allow us to bypass System.Drawing without adding an Eto reference to RhinoCommon.
What are the reasons for wanting to remove the dependency of grasshopper on system.drawing?
I’d just rather not have two assemblies that both do basically the same thing, and both use the same typenames.
Why not make a "GHColor" type that can convert to and from Eto.Drawing.Color and System.Drawing.Color using implicit cast operators? That way I guess you could support both assemblies without having to fight with explicit namespaces.
Probably the best thing to do right now is nothing and let @curtisw help us figure out the best approach while he looks at how to port GH1 code.
Hey! that’s my go to response. Hands off!
1 Like
I would probably lean towards @menno’s idea of creating an implicitly convertible type. I am this week starting on the port of GH1 over, so I’ll start to find all these issues (there are probably more than just Color/Point/Size/Rectangle).
We would certainly want something that is very streamlined, but switching to GHColor, GHPoint, GHRectangle, etc types would break binary compatibility with existing addins vs. adding new overloads.
I’m not sure if binary compatibility is required though, the new types would mean just a simple re-compile would do.
Hi @curtisw, what was decided in the end regarding this? As I am updating the samples that ship with the RhinoCommon wizard for VS, I first removed references to System.Drawing, but noticed that I should rather not do that. At least not now. Is that correct?
@piac yes, you are correct - You’ll still need to reference System.Drawing in plugins to call the RhinoCommon api’s that require point/rect/size structs. There’s also a few that use System.Drawing.Bitmap, such as getting a thumbnail.