Working here in 8.0.23251.10305
Thanks for that, itās really a network issue, it takes me 20min to install numpy in pip and the download speed is very slow, probably because of this the process becoming unresponsive.
Feedback Request:
In the next build of Rhino, you are gonna notice that the Grasshopper script component has updated parameters. Both input and output parameters now have type hinting and more type hint options are also available correcponding to the new data types in Rhino 8. They also warn against using reserved keywords like dir or filter in their respective languages.
However, I also made a change to the parameter context menu, allowing to set variable name, and user-facing nickname independently from each other:
-
It helps providing a more descriptive name, and separates that from the actual name of the variable. e.g. nick name:
Image Data (base64 string)and var name:imgData. This in turn means that the inputs and outputs of the script component are gonna be more clear by just glancing at the component. IMHO this helps with readability, both for your own future self that looks at the scripts in a few months, and especially for others using your definitions. -
It allows me to grab the nickname of the parameter (the user-facing name) when generating full Grasshopper components/plugins from these script components and not worry about providing a UI to override the not-user-friendly variable names somewhere else down the chain.
Here is what it looks like on macOS, and Iād love to hear your feedback on this. One thing that is not great is that you need to set both when creating a parameter. This might create confusion and I can improve this if we generally agree this is a good feature to have.
I was going to say that.
The input name of existing script components are now in the NickName (for humans). The variable for the script input is missing.
I think it would make more sense to have the existing input in the script variable name input and if a user decides a more descriptive name is needed that would override the displayed nick name.
It looks better on the output:
I currently have around 50 components which went red because of the new nick name option. Besides that do I need to copy paste the code inside the components into a new script editor component?
I would prefer if the Nickname is optional field to fill.
empty field ā Variable and Nick-Name are the same.
by the way - did you find time to look at this topic regarding assembly references ? Thanks.
kind regards -tom
That should not have happened 
No change to your components should have been necessary. I tested this on my own test definitions. Not sure why this happened but Iām sorry.
Just fixing the parameter names should make the scripts run. Would you mind sharing an example so I see where the problem is when reading existing grasshopper files?
Iāll fix that for next weeks build
script_input_nickname_problem.gh (16.5 KB)
Two more grasshopper files I didnāt open yet in the Beta, one with a c#, the other with a python script:
sets_c#.gh (11.5 KB)
notes_in_directory_python.gh (14.4 KB)
Hi @eirannejad ,
Iām trying to understand the intent/how to use the variable name vs nickname in the new ScriptEditor update.
Currently all of my components are broken as it is saying that the input named āname hereā is not defined because the new change is looking for the āfor scriptā variable name and my scripts have all been using the shorthand nickname.
If I set VN to be V then this script example works fine.
However, then I have a tooltip input named V with NickName V (or I guess I could change nickname to be Value but this seems opposite/counter intuitive to me?)
With Python Iāve mostly been setting up my input tooltips with the following code:
ghenv.Component.Name = "Convert To Model Units"
ghenv.Component.NickName = "CMU"
ghenv.Component.Description = "Parses Input Values For Symbols Representing Units And Converts The Value To Model Units. \n(Example if Model Units = Feet: A Value Of 15m 6.75mm Returns 49.234744 Feet)"
ghenv.Component.Params.Input[0].Name ="Value"
ghenv.Component.Params.Input[0].NickName ="V"
ghenv.Component.Params.Input[0].Description ="Values To Convert"
ghenv.Component.Params.Output[0].Name ="Value"
ghenv.Component.Params.Output[0].NickName ="V"
ghenv.Component.Params.Output[0].Description ="Values In Model Units"
Do I need to update my scripts to use the .Name as the variable now instead?
Thanks for shedding light on it!
@michaelvollrath
Hi Michael. No keep using .NickName as your variable name. I made a bad change without realising how many scripts are setting these values in-script. Iām fixing this right now for next weekās build. Iām sorry for the problem this caused.
Iām also modifying the UI to make the Human-readable name optional like before.
No worries at all @eirannejad ! Thanks for clarifying, Iāll keep the components as is for now in anticipation of the update.
Thank you!
Thanks for the video. I like what you changed and Iām looking forward to the next build.
Thanks @eirannejad , looks good to me. I was going to ask about the functionality of āDisplay Full Namesā so thanks for covering that as well!
āDisplay Full Namesā didnāt used to do anything to the script components. Unfortunately since .NickName was used as the variable name, and that is what Grasshopper uses to set when āDisplay Full Namesā is toggled, I can not make it work with the new script component easily either. So:
-
The Editable script component on the canvas is always gonna show the variable name on the input/output parameters but allows setting the override Pretty name. Iām thinking of this as a small price to pay for consistency.
-
The Flat script component (a script component that has been compiled into a component with embedded script) is going to behave like the rest of Grasshopper components in regards to āDisplay Full Namesā toggle. It knows the number of inputs/outputs so can read/write based on their index and not have to care about naming.
Just wanted to throw this here for clarity
Thanks for clarifying. Perhaps someone will be bothered by that. Iāve always ran the nickname and icon variations of components to save in the screen space real estate so I prefer the shorthand input names anyways. But of course the tooltip is important to show the full name of what the input actually is instead of just the nickname of V for instance.
I have trouble determining which python package I can install and use inside new Rhino Script Editor and which not.
I would like to use xlwings package to stream data into already opened excel files. I managed to do it with the use of Hops component but itās not my preffered way to do it because I need to start VS Code and connect to Hops component. So far no luck installing xlwings module using just Script Editor.
How to know better?
EDIT:
I installed xlwings, firstly there was some circular dependency error with pandas which I believe I solved, but now itās asking me:
XlwingsError: Make sure to have āpywin32ā, a dependency of xlwings, installed.
which I canāt solve.
Okay I found a bug in how pywin32 is installed and got that fixed. Should be available in the next build
add this to the top of your script and it should handle installing both
# r: xlwings, pywin32
import xlwings
I tested this and I hit an error when importing xlwings as I dont have a license
Here is the ticket for future reference: RH-77094 Pip installed does not process .pth file when installing pywin32 and hence importing does not work
Thanks for looking into it. I just updated the Beta and still canāt make Xlwings work, I have various errors that stop me from using it.
I donāt know if I understood you correctly, should this package work yet, or not?
Another question: I know that you guys are using Eto for the GUI, but would it be possible to invoke simple GUIs made with other Python Frameworks like Tkinter?
What errors are you getting when installing Xlwings? Make sure to delete the %homepath%/.rhinocode\py39-rh8\site-envs\default-* folder to remove the existing installed packages
Using Tkinter in python 3 when running in Rhino is not possible. TKinter uses its own ui loop that does not work inside of another application