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:
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 
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.
I think the UI design was already reported by others. We could have less space wasted, collapsed “using” statements, etc etc…
UX side:
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
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
No methods descriptions at all.
No different icons for types/methods/etc.
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.
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.
I’ll review this again and make it match the behaviour of the older script component
That’s on the list. (did we have it before?)
That’s ony the list. I agree it’s pretty annoying
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
I have improved the editor launch speed so it should be a lot faster in the next build
Thank you Ehsan.
1 I see now that undo for the code editor window and for grasshopper are separated!?
3
Yes:
6 … super!
7
I’ve seen another misbehaviour:
The autocompletion dropdown (or dropup) menu can’t be closed with ESC key.
(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.
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.
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.
@Helvetosaur That’s been fixed and will be in then next build.
That’s a very elegant and simple solution. Thanks so much Ehsan, looking forward to the next builds 
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.
Yes, please, that would be great!
We can do this, but the script would not work in Rhino 7. Is that a problem?
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
@AndersDeleuran @stevebaer I’m getting the script instance cleaned up so now we have all languages being able to implement a Script Instance and override these methods. I looked into adding DrawForeground but you are right. It’s better for this to be part of GH SDK first instead of the instance wiring it up and down on every call.
Thanks for the YT
Ah sorry, I didn’t mean to imply that this wouldn’t involve updating the Grasshopper component class in the SDK. I just meant that I wouldn’t expect new features in Rhino 8 (whether RhinoCommon, Grasshopper SDK, or editors) to work in Rhino 7. I’m probably not seeing the larger picture 
After two months testing the new script editor, I still find its layout quite wasteful and distracting. If I might add to my previous suggestions above @eirannejad, here’s a new mockup that maintains all features and menus:
While substantially decreasing wasted pixels (red) and increasing the editor/console real estate (green):
Specifically, here are the edits suggested with this new mockup:
