Hi Sara,
Where I’m currently at here is:
- I can launch a ‘HumanUI’ controlled Grasshopper definition in Rhino 7 as a command. It use a simple Python script that is compiled as by the Rhino Script Compiler.
This you have seen in this thread:
So one of the issues with this setup is you lose all control over your GH if you close the HumanUI controls. I have got around this by listening to the window status output on the HumanUI window component and launching a second window if the first is closed that gives the option to re-open the first window. Works fine even and should give the ability to add other close down options.
The great thing about this setup is the Rhino Script Complier creates a RHI/Yak file that does not show the GH or Script files. Also you cant get to the GH script by opening GH etc.
The biggest issue I have right with this set up is a clean way to close the running GH - the only way that works is closing the whole Rhino window. I’ve got a few ideas that need to be explored to try an fix this.
Like you, my ideal setup would be ‘fully self contained exe’ something that looks like a separate application but runs GH/Rhino under the hood. Just like Shapediver looks like a custom web app but runs Rhino/GH on the server side.
The most interesting/promising thing I have seen so far is the ‘Rhino,inside,WPF’ and ‘Rhino.inside.ETO’ demos that @stevebaer has tease with:
It looks ‘probable’ that this approach would allow an GH script to be built into a self contained application that works as long as there is a licenced copy of Rhino on the machine in question.
For now I’m only going to be working on making my GH script feel/act as first class plugin, but the self contained app looks so good I’ll work on that more in the future.
Cheers
DK