I understand that the
DataGridView is the culprit, based on the reports that land on my desktop (see Edit 2 above) when the GHPython editor causes Rhino to crash. So the bug here (referring to your quote below) is explicitly and objectively known.
This again feels very prescriptive. When I develop in Python I rely heavily on print calls, not just for constantly checking the logic of what I’m doing. But also for things like introspection, type-checking, assembly exploration etc. that one would otherwise rely on the functionality of an IDE, or access to API documentation for. All these use cases can and will lead to large print calls. Which in the environments I prefer to use (such as Sublime Text etc.) aren’t a problem. They are designed to be lightweight, performant, and agile. Which was also the case with the old GHPython editor.
It’s great that
DataGridView has been otherwise well adopted, it really is. But for the workflow I describe here, it just doesn’t add any useful features. But instead kills performance, crashes Rhino, and generally feels shiny/bloaty (I understand that visualising compute cycles can be useful/neat, but I have zero usage for this). I’m sorry to be so negative here, but this is really a super bummer!
Edit: For reference, here’s how the Sublime Text output window looks/behaves/performs:
In terms of future text editors in Rhino/Grasshopper, I’d personally much prefer this direction.
I think we know that’s not super true. Having to pipe development/debugging information to an output would also put it on the same level of the C# component (or the Dynamo Python editor ) in terms of the development experience. Which would be a pretty large leap backwards IMO.
That’d be awesome. One thing I forgot here: Opening the search/find menu (Ctrl + F) should also preferably occur closer to the editor (it opens in the far left/upper corner currently if I recall).
I’m away from my system right now, but I’m pretty sure the GHPython Help window background has the lighter grey color. So I assume it could be edited in the source.
Afraid I’ve had no luck finding the Windows theme controls that allows one to fiddle it with. It seems that Microsoft have removed a lot of this customisation. As per this old thread, I’d vote for explicit control within the app (or hard coding it to fit within the context aesthetic).
Ah yes, that one was a bit cryptic. As far as I can tell, the syntax highlighter will assume that anything (or at least in some cases) in front an
( is the name of a function/class, and as such should be in bold. Instantiating a tuple is a basic case of this.