Rhino 8 Grasshopper Script Editor - Design Feedback

I’m using 8.2.

I have a question I’m curious about, would it be possible to integrate file watching into the new script editor so users can be notified about changes to the file from another application? In the original Python script editor this was quite handy.


My use case is typically authoring and refactoring my code in VSCode and debugging in the Rhino script editor. Is this a common workflow for anyone else? Maybe there’s a better workflow someone could share? :laughing: I’ve been really enjoying the VSCode RhinoCode extension for running hopefully there will be debugging in the future? :heart_eyes:


@bfrederick The new script editor watches changes to any of the scripts that are open in the editor. Does this not work for you?

Ah yes I see it working now, even better it just happens with no dialog. I guess my brain was used to the file changed dialog. Sorry for not thoroughly testing that!

1 Like

A couple of things came to mind while I’m here but also wanted to say, this new editor is definitely a productivity boost, thanks for all the hard work in making it a joyful experience.:heart:

Docstring & type hint support

I’m excited to see the feature RH-58484 display docstring help when double-clicking a function name in the text editor

  • I’m curious if instead of double clicking if we could optionally have a window display on hover. I understand that some folks liked seeing it in the output panel of the legacy editor.
  • If this could work on user defined method docstrings it would be a great help for anyone importing their own packages as well.
  • Supporting type hints would also be amazing now that we have Python 3 support, and super helpful when prototyping with third party packages.

Here’s an example from VSCode:

Help TextBox

A separate item is the Help tab, if rhinoscriptsyntax help could behave similar to how the RhinoCommon method help displays in a new Help tab that would be amazing.

At least if the text box window could be adjustable and scrollable, that would be much easier than only scrolling each time you view help for a method, just resize 1 time and explore method docstrings.



On my pcs it’s a 50/50 chance … every time you edit the code and close the editor, rhino will minimize… maybe.

  • 8
    and also:
    Rhino 7
    2024-01-11 02_14_14-Window
    Rhino 8.4
    2024-01-11 02_14_48-Window
    no type of object returned, input types, or description…
    I have not memorized all Rhinocommon, my usual script “flow” is to find the method more appropriate at the moment and reading what kind of object it is returning, sometime it is even a void and the output are with the “out” statement … with current state one would have to go trial and error or similar… if not memorized.

  • 9
    Also, on not-so-recent hardware the script editor is really slow to open. Particularly the first time, but also any next time after…
    Even on my main PC (Ryzen 5800X, 32GB ram, M2 SSD with 5GB/s) on 7 creating a new c# script and opening its editor is fast as much as you are: the editor window fully “unfold” in a single frame (16ms) and its content is already “sorted” inside, ready to work. Boom! And the editor pops near the on-screen location of the script component… nice!

On 8 the editor is slow even to spawn on canvas:
2024-01-11 02_39_17-Window
^ on my best pc, simply dragged new scripts (never opened once). You can feel the “hiccup” while they are being created.
Then, opening a script editor, the editor window pops (not near the on-screen location of the component…) and it takes many frames, and then its content is “sorted” … you can feel it.
I can see this on 3 machines, and on the oldest one it really seems that just creating a new script component and opening its editor is a whole complex task. It takes some-many whole seconds.
“Optimization” … whatever that word means, it’s not present for this specific aspect :no_mouth:

  • 10
    2024-01-11 02_51_27-Window
    query “m.close” returns “CollapseFa…” before than “IsClosed” …?

Last push please! :sob: (mainly pt 8 and 6)
Thank you for the support!

1 Like

Again pt 9.
On an old pc with a FX8350 , simply dragging new script components on 8:
2024-01-11 12_19_49-Grasshopper - unnamed
the top one is the first one, the bottom three are after the first.
Then, opening the script editor takes like 6 second the first time.
A total of 8+ seconds to just start coding!
(in 8 seconds I can do some pretty complex solid booleans, even in this 10+y old machine)

I understand that from an external point of view this machine hardware might seems old, but the truth is I can work normally with any rhino 7 project up to about 500MB, grasshopper scripts (and c#) included… It doesn’t slow me down.
For comparison, on 7:
2024-01-11 12_19_29-Grasshopper - unnamed
… and opening the code editor is also similarly faster.

This to say: on old machine, for me, it is impossible to code in 8. While doing so in 7 is no problem at all.
On other pc, much more modern, this problem is lighter (but still I can’t work due to pt 8 an 6).

I’m not asking for the code editor to be faster because I want to work on 10+ years old hardware. No.

I’m asking this because I can perceive the the UI struggling to keep up with my clicks while doing “nothing” (creating and editing a new, empty script) even from a modern hardware!
Here ^ I’m using old hardware only to measure/show the literal 100x time required to do the same ““task””, from 7 to 8.

Something is objectively wrong.
In other fields devs simply go with the “Users with modern hardware might not notice…” , I hope it is not the same for Rhino and McNeel.

Currently I can code in c# better and faster on a 10+ years old machine with 7, than a modern machine with 8. More proficently, effectively, with results.

  • 11 missing right click > cut/copy/paste menu in the code editor

Would the constant updating of the Script component be behind why there is such a lag when typing?

Either way, having an option to turn off that constant updating would be my key feature request.

Just bumping this one, think it might have fallen through the cracks (ping @eirannejad):

That is, move File and Edit menu points up so they are first. And move Grasshopper down to before or after Tools.

1 Like

I’m just going to reiterate some of these suggestions, specifically in relation to something I noticed over here. Namely that one cannot identify the component type and version when an error is thrown:

I would again suggest moving this information up from the bottom to the top bar:

I will also suggest deleting the top left Rhino logo (i.e. like the GHPython editor). The new editor has quite a bit of visual bloat in terms of superfluous and high contrast icons already (for my taste), so culling any that aren’t strictly necessary or functional would be greatly appreciated. One might also further simplify/make explicit the component information by editing these from:

C# @ 9.0
Python 3 @ 3.9.10
IronPython 2 @ 2.7.12


C# 9.0
CPython 3.9.10
IronPython 2.7.12

That is, similar to this previous mock-up:

I of course understand that you’re very busy fixing functional issues, so I’ll leave all this for later :slight_smile:





Now this I consider constructive feedback :smiley:
Thank you for effectively making the script editor better for us all

1 Like

Adding descriptions for RhinoCommon C# completion items, RH-80097, is fixed in v8.5.

After the completion window is open either click arrow on the right or ctrl+spacebar to open the window. It will stay open while you scroll through the other items.

Related items: Automatically open the docs window for completion items RH-80453


I’m currently running 8.5 on macOS and a scripts directory still doesn’t seem to be referenced?
Sorry, my bad. I had them in another Rhino Scripts directory.

1 Like

I have a few questions about using the Grasshopper Script Editor in Rhino 8.5,

  1. Is it no longer possible to use docstrings to create tooltips for inputs as previously done in a Rhino 7 ghpython component?
"""Provides a scripting component.
        x: The x script variable
        y: The y script variable
        a: The a output variable"""

  1. Is anyone else having UI issues where the Script Editor is misaligned with the elements circled red in the image above?

Thanks! :blush:

Yes, I have that as well

I reported this a couple of days ago, I think it will be fixed in the next SR.


Yes, me as well on macOS. By the way, I’ve discovered numerous UI glitches like this in Grasshopper, like grid lines popping in and out of existence but in the wrong place and the canvas border being duplicated when placing some components outside of its boundary, all depending on the zoom level and thus hard to replicate at times.

These are the related tickets we are working on:

  • The editor does not yet support extracting parameter information from docstrings: RH-79236

  • There is an issue with high-res monitors and scaling above 100%. Fixing this underlying issue with resolve these to tickets: RH-81319 and RH-75781


One quick design comment that I’m curious about is why syntax errors don’t appear in the Terminal tab. They show up in the component runtime message flag and highlighted in the editor and the Problems tab. That’s all good :clap: however when you’ve got a large script and your quickly debugging it’s nice to see the syntax errors in Terminal Tab.

Does anyone else agree?