Congrats on the progress of the Rhino 8 Grasshopper Script Editor. It looks a lot sharper than last time I had a go. That said, I do find there are design issues where the current GHPython editor shines brighter. Notably:
1: Wasted Screen Space + Visually Busy/Cluttered
With the same window and output/terminal size, there is substantially less space for the actual code editor:
As mentioned elsewhere, this language indicator is pretty clunky/wasteful. The information is also provided two places inside the editor and may be provided on the component itself by swapping out the icon to respectively the C#, CPython and IronPython logos upon language selection:
I understand that there is new functionality planned (e.g. debugging). But changing the 10+ year oldTest shortcut (i.e. F5) is pretty jarring. Perhaps consider making Run F5 and Continue F6:
There are quite a few issues here, I assume these are just the result of whatever the new editor is built upon. But anywho here are a couple of the ones that immediately sprang to mind for me:
I’ve also noticed more functional issues, but perhaps that’s best left for another topic/place. How do you prefer us logging this feedback by the way?
I’m not a heavy Rhinoscript user and essentially unfamiliar with Grasshopper, but my 30,000 ft view is that it is completely absurd and almost irresponsible to have two different editors for what is essentially the same thing in the Rhino ecosystem.
My understanding is that this new Script component (which can run both C#, IronPython and CPython) is meant to replace the current C# and GHPython (i.e. IronPython) scripting components at some point.
I’d recommend asking general questions about the new Script editor project here. This topic was specifically meant to highlight design regressions from the current GHPython component.
The new script editor allows debugging in Grasshopper. It means that you can step into a function that is in a separate file and editor would open that file showing the new tab.
Thanks so much for logging these @eirannejad. A couple of quick follow-ups/elaborations:
That’s really cool. Does it work yet? If so, is there any documentation/examples of how to use it?
I understand and appreciate that. It just takes up an awful lot of of space and is quite visually distracting compared to the current GHPython editor. Especially if one does not intend to use these buttons: I run a pretty GUI minimal Rhino/Grasshopper setup, relying on typing commands and using keyboard shortcuts. A typical situation looks like this, where I will have several GHPython components open at the same time:
So any waste of screen real estate and unnecessary visual clutter is kind of a big deal for me (especially since dealing with Long Covid/brain fogginess). And I would very much like to reiterate the request to make the top and left button toolbars hideable. Just like one can hide toolbars in Rhino and Grasshopper as per my screenshot above. Failing that, perhaps consider reorganising and trimming the GUI elements a bit to make it more like the current GHPython component. Here’s a quick mockup implementing suggestions made in my original post:
Again I understand, but it takes up a lot of screen space (and is subjectively inelegant/odd). Especially for components with little or no inputs/outputs. Also the textual information is clipped with short/no parameter names:
Thanks for the suggestions. I agree it is still rough around the edges. I’m working on finishing up the last “feature” in the editor and should be able to jump back on these issues very soon. I have logged this issue related to the comments here, alongside the ones added above:
We’ll get there soon. Please keep the requests and comments comming about anything that feels like a regression, etc. The goal is to make this feel as close as possible to the older script editor, and yet provide loads of new goodies
Debugging in the editor is pretty straighforward. in Rhino or in GH, throw a breakpoint somewhere in your script. The buttons will change to debug buttons. Run from the button or from GH, and the script should stop at the breakpoint. Debugging panels below the editor show variables and callstack.
Hi @eirannejad, I just noticed that you have implemented this suggestion. Thanks so much, it looks great! If you’re interested, I have previous downloaded the logo files as SVG (i.e. for the Grasshopper2 versions and for best rasterization in Grasshopper1). Also, just spitballing here, maybe the logos should be edited a bit to fit within the general Grasshopper/Rutten aesthetic (i.e. similar to the current GHPython component). Just gave it a quick whirl, like very quick, but might spark some ideas:
Me too, I was just thinking that perhaps one ought already align their design with the new Grasshopper2 icons. Which appear to use colored strokes quite a bit. And are also dynamic (if I recall there were even options to customise/mute icon colors at some point):
And while I enjoy the G2 Icons quite a bit, I don’t want to undersell the simplicity of a dark/light switchable border stroke to just “lift” the edges of an icon off a light/dark background node color.
You could leave the icon colors consistent and invert the boundary edge color between light/dark based on the UI theme/color beyond.
The tabbed debugging is a really nice feature for debugging handoffs between multiple components, I liked the idea when I saw it at the development conference in BCN earlier this year.
I agree with Anders that it hogs real estate if you’re only working on a single component though. Perhaps there is an auto-hide option to conceal the tabs when there is only one, this could also visually strengthen debugging one component vs multiple components.
@AndersDeleuran Thanks for the icons and attention to detail. I have a ticket for that and will get those cleaned up RH-76674 Improve discoveribility of creating languages in new script component
