Rhino 8 Grasshopper Script Editor - Design Feedback

No input names/nicknames? Is this grasshopper on “hard mode”? :stuck_out_tongue:

2 Likes

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.

2 Likes

@Alexander_Jacobson Already added that. Now tabs only show up when there are more than one script open in Grasshopper components

2 Likes

@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

2 Likes

Cheers @eirannejad, I made a fourth version with the thicker dark stroke. Where I have also set the stroke on the CPython logo in the inside, and the stroke on the IronPython eyes and C# hash on the outside, as well as “popped” the gradient on the CPython logo a bit. Making them look better when small and more unified:


230830_ScriptEditor_Logos_00.ai (338.4 KB)

1 Like

Hi @eirannejad, I was gonna wait before logging this, but since the Rhino 8 BETA is now out and the current GHPython component has been (arguably prematurely) removed/hidden: A major missing feature in the new script editor is the ability to run an IronPython component in GH_Component SDK Mode:

I’ve come to rely on this quite extensively for e.g. drawing things, events, and performance. I do find the default code a wee bit bloaty and usually reduce it to a more terse version ala this:

And implement the same methods that the C# component has (e.g. for drawing, that may be inserted with a user-friendly button override):



And here’s a loose thought: It does, and kinda always has, feels a bit odd and convoluted to have both Procedural Script Mode and GH_Component SDK Mode. Perhaps this might be a good time to reevaluate whether it makes sense to consolidate the two modes? Perhaps remove the SDK bloat and make the design similar to the C# component, with a hard coded RunScript scope and user friendly options to insert draw overrides etc:

The override methods also might be renamed a bit for consistency. Currently some are named the same as the C# methods (e.g. DrawViewportMeshes) and some have PEP 8 names (e.g. get_ClippingBox, which is just ClippingBox in C#) and some use dunder/double underscores (e.g. __enter__, which is called BeforeRunScript in C# I believe). All quite confusing and visually unpleasing. It being IronPython/.NET I’d prefer using CamelCase names like the C# component.

There are probably many reasons why not to consolidate, but I thought I’d put it out there. For instance, procedural mode currently handles input and output parameters better I find. Where the method you input and return parameters by in SDK mode feels a bit weird, and the names of input/output parameters do not matter, only their order (which is not the case with the C# component). Anywho, brain dump over :slight_smile:

3 Likes

This is great. In the new editor, there is a “Templates” panel on the side that has templates for various script types. This ended up replacing the “Add Overrides” buttons but I do have a ticket to make this process simpler like before

RH-76427 Missing override buttons for SolveInstance and Preview

Before that ticket is fixed, I’ll make sure IronPython has SDK mode templates for the next build

RH-77071 Add SDK-Mode templates for IronPython in Grasshopper component

I appreciate your comments and attention to detail.

2 Likes

I think the UI design was already reported by others. We could have less space wasted, collapsed “using” statements, etc etc…

UX side:

  1. You can’t “undo” any c# script code edits. Undo will revert any changes in canvas position and such, but not the changes in the code. Scary 1x

  2. In Rhino 7 gh c# script component edit window have a “X” button to “close without save changes” and a “Ok” button to “close and save changes”.
    In Rhino 8 Wip/Beta it always save any changes you make. Scary 2x

  3. No methods descriptions at all.

  4. No different icons for types/methods/etc.

  5. the main solution structure and brackets “{” and “}” can be deleted. It would be best to have them like in 7. Or if it can become useful to remove the main solution, it would interesting to know why/when/how.

  6. Opening the script component to edit the code (by double-click) is slow, the whole UI stutter for a couple of seconds (mainly the first time you open it) even on modern hardware. On older hardware, if you click while it is opening the first time you will freeze-lock the whole Rhino UI.

These points combined really makes the script component hard to use.
They are probably already on track (i hope), but I wanted to report them just to be sure.

I’d like to test it more, but currently it’s too tricky for me to build something serious.

2 Likes

@maje90

  1. I can’t replicate this. Would you mind sending me a video of how to make the bad undo happen?

  1. I’ll review this again and make it match the behaviour of the older script component

  2. That’s on the list. (did we have it before?)

  3. That’s ony the list. I agree it’s pretty annoying

  4. the new script component leaves it flexible for you to decide whether you’d want to use the SDK-style scripting or just writing down your C# code in there. The main benefit of the SDK-style is the overridable bounding box, and draw functions

  5. I have improved the editor launch speed so it should be a lot faster in the next build

1 Like

Thank you Ehsan.

1 I see now that undo for the code editor window and for grasshopper are separated!?


It’s interesting but I’m not sure I would prefer current concept.
Simply put: gh script undo behave very differently from Rhino 7.
Grasshopper is first a visual programming language, then there are small scripts here and there.
I think an user (me surely) expect to have undo as “let’s go back to 5 minutes ago where everything worked fine!”.
A definition algorithm is mixed, visual+script, while working there are edits outside and inside scripts. Not sorted, in random order.
If script editor undo and grasshopper undo are separated, not synced, one would go crazy with “undo here, undo there, redo here, redo there” to pinpoint again the working build.
This is not good. Really dangerous.
I’m pretty sure current undo behavior is definitively objectively wrong.
… but that again is my subjective opinion. :stuck_out_tongue:

3

Yes:


they are sort of broken, when description text have same words of variables it mess up the bold style and other stuff. But overall one can code directly by reading the description here.
I learnt coding directly here, thanks to descriptions, I have to search rhinocommon method only 0.1% of the cases…

6 … super!


7
I’ve seen another misbehaviour:
The autocompletion dropdown (or dropup) menu can’t be closed with ESC key.
2023-09-19 00_12_38-Window
(this ^ is just a case but it happens the same with similar others)
to close it you have to move away hand from keyboard to use the mouse and click in another line.

  1. Oh I see. Okay I’ll talk to @Alain about getting that in
  2. already fixed that and will available in the next build.
1 Like

3). the method description is there but not the description for the current param. I’ll add it:
https://mcneel.myjetbrains.com/youtrack/issue/RH-77140

7). I don’t see that problem in the latest build. I can close the autocomplete window with ESC on both windows and mac.

1 Like

Hi Alain,
Not working here in the ScriptEditor (Rhino, not Grasshopper - PC) in the current Beta - Esc does not cancel the autocomplete.

Hi Mitch,
I was testing with a local build so it should be ok in the next release.

1 Like

@Helvetosaur That’s been fixed and will be in then next build.

1 Like

That’s a very elegant and simple solution. Thanks so much Ehsan, looking forward to the next builds :raised_hands:

Edit: While you’re in there, it would be great to add the DrawForeground as a standard override, in addition to DrawViewportWires and DrawViewportMeshes. So one doesn’t have to jump through hoops to implement it. I think the considerably interest there has been for drawing to 2D screen space would warrant this.

4 Likes

Yes, please, that would be great!

2 Likes

We can do this, but the script would not work in Rhino 7. Is that a problem?

2 Likes

I don’t think so. If one writes a script in the new editor, that wouldn’t even open in Rhino 7. And I can’t think of a good reason why one would back port a script. It would be really cool and helpful to have!

Ok, this is as much about additions to the SDK as it is about some friendly tweaks to the editor to make this easy to type in. We’ll need to look at adding this to the SDK first.

https://mcneel.myjetbrains.com/youtrack/issue/RH-77256/Add-DrawForeground-override-for-components

1 Like