I’m using an opensource addin, which has about 300 components, and only one icon.
Partially as a learning experience, i thought i’d try to parametrically generate some icons for them.
As a first pass, this would be creating a table of component names, inputs and outputs.
The github is not very useful.I think it might be possible to parse the code as a series fo text files and look for keywords like RegisterInputParams but it seems quite a leap to get from there to the name of the inputs) robustly. example: https://github.com/cromlyngames/Topologic/blob/master/TopologicGH/WireFaces.cs
I’ve done a first pass off the help file documentation, but that’s partial, fragile and manually intensive. Is there another way I can scrape/parse the information?
You could have a look at the components while they are loaded in Grasshopper. It should be fairly easy to figure out which loaded components belong to a specific plugin, instantiate each one and interrogate its input and output parameters.
There’s also 33 utility components that I know of, and more being added as the need arises. I can do it by hand, and probably will need to do that for the final qa pass.
ok. I guess I need to load the namespace in a python componenet, and call the correct guid to get the component (to then interogate).
Hmm. How to get guid?
Right clicking on the compnent icon in menu bar in grasshopper lets me bring it up (although sadly, I can’t select the guid out of the text).
Could I set my own? https://developer.rhino3d.com/wip/api/grasshopper/html/M_Grasshopper_Kernel_GH_Attributes_1_NewInstanceGuid_1.htm
nope, a couple of inches and one more celtic saint required for minimum requirements. let’s have a look at Harvester.
For each potential grasshopper object that exists in Grasshopper.Instances.ComponentServer.ObjectProxies
Check if it comes from a plugin, and if yes, check if that plugin matches the test input, and if yes, then create an instence and write it’s args to the text list for output to panel.
very neat.
Instead of giving none-sense icons, wouldn’t it be better to modify the components in a way that one component groups functionality, which can be selected by a dropdown or a similar control? 10 meaningful components are much better than 300 simplistic ones. Also creating in- and output parameter dynamically is not so difficult…
Certainly the ten components that return the type of the input could, and probably should be grouped into a wrapper function. The existing functions might need to be kept for backward compatibility?
The 27 components that create a new data structure on the format of Datatype2.ByDatatype1 could, I think, be merged, although you would introduce another yet another layer of abstraction that makes bug checking harder for the user. At the moment if your inputs and components are not aligned, you get a clear error message, rather than valid looking but irrelevant results.
Some of the functions, eg the four below, really should be separate with bespoke icons since the visual information of the icon is the most effective way to convey what they do and how they are different.
Merging and putting them on dropdown list of options for one component would be more confusing I think.
Topology.Impose(Generic Data Topology, Generic Data Tool, Boolean Transfer Dictionary, out Generic Data Topology)
Topology.Imprint(Generic Data Topology, Generic Data Tool, Boolean Transfer Dictionary, out Generic Data Topology)
Topology.Intersect(Generic Data Topology, Generic Data Topology, Boolean Transfer Dictionary, out Generic Data Topology)
Topology.Merge(Generic Data Topology, Generic Data Topology, Boolean Transfer Dictionary, out Generic Data Topology)
If you throw at the right place and you just pass this to the user, then the message should stay the same. Esspecially a factory object can most likely only fail if the “arguments” (input) from the users are wrong. Naming this should be straight forward. E.g. “ArgumentException: Cannot create a triangle instance. Please provide 3 valid points, which are not located on the same line.” In this example it would throw in the Triangle constructor and not in theGrasshopper component instance.
Usually you can mark any component as obsolete, which prevents it from being shown. However at this stage, I would simply make a breaking change, providing new component ids, maybe even setting up a new project. Anyone who needs the old plugin could simply load it as well.
Instead of creating absolutly random icons, you can also create group of icons, and just modify its colour or adding a symbol to it procedually.
I was just reading Icon generator in C++ , but the initial link to it was broken. So I assumed it must be something like an library used to create some randomish images, just as the Discourse Icon Generator. I didn’t expect it to be written by you.
Still it sounds more like a workaround, thats why I thought why not reducing the components instead. As I said instead of offering hundreds of api calls wrapped as a component, I personally would make the components more complex instead. It further doesn’t pollute the workspace with hundrets of them, nor it requires redundant meta information. Assuming that this is something feasable.
before opening Harvester.gh…