TLDR; It would be great from productivity perspective for new components to automatically connect to the previous ones.
This workflow would be much faster if you could just type the names on the keyboard and “Tab” or arrow key between parameter slots - I think that manually laying down components and drag-and-dropping connection to parameters gets in the way at some point (EDIT: at the point when hand moves from keyboard to mouse).
It’s probably not a trivial task and I assume that would require designing an entire new interface while maintaining the existing one?
I think that it would make grasshopper an even more poweful tool though.
EDIT2: there is no exmaple
Aren’t there plenty of programming languages that don’t require you to move your hands from the keyboard at all? Some of which can be used in Grasshopper?
Not sure how linear your definitions are… but it feels like this would be exceptionally cumbersome when things branch out?
Not sure this is a sensible way to use GH but imagine trying to tab through this?
thanks, both points hit the bullseye. 1st one - tldr; boilerplate and feature parity? I wasn’t sure how C# compares to Grasshopper - can you for example call other plugins from C#? Can you call for example Lunchbox.Grid()? My concern is that it may take many more steps than just using grasshopper and also how many GH features are available from C#. Input from someone more experienced on that field would be definitely appreciated. I sense that automating grasshopper may be easier and more accessible to existing users.
Yes, branching definitions may not fit perfectly into this model - but perhaps it depends on the implementation?
From my (rather flawed) understanding, half of the plugins for Grasshopper are leveraging existing functionality of Rhinocommon that may not have made it’s way into Gh yet - this is why you sometimes have a command accessible in Rhino but not in Gh. Some components are operations that have been strung together to deliver the required functionality, so the building blocks to make things happen change very little in some ways. (What can be a little frustrating is that Rhino is using slightly older versions of both .NET and Python, but it looks like there are fairly acceptable reasons behind this, so we have to make do)
Using plugins in C# or Python largely depends on what the plugin is - grids are a fairly common operation whether you’re handling geometry or data - so chances are if you start to pursue these topics you will need plugins less anyway - but yes, you can import other libraries, assuming they have been published by the developers in the first place, not sure that Lunchbox has been.
I have noticed that generally, Gh is more appealing to people that have never really learned how to code properly and gives us a foothold in the world of computation; being a visual interface is a very large part of that. You can utilise the languages to script and automate behaviour inside Gh - or you can compile your own components; this has a slightly steeper learning curve, but delivers incredible speeds of execution. It really depends what you’re trying to achieve though, if it’s to use the mouse less, you probably want to get started with typed languages sooner rather than later - but that’s all just my two cents on the matter.
I think that’s why I stayed silent about C# or other scripting languages - Grasshopper is great for quick prototyping. I would pick C# or Python only for building a new component, not orchestrating existing ones.
Admittedly, grasshopper got me into programming in the first place. I still use it at work though and deadlines often press hard to go the easy way.
I’m looking for this workflow: open up the editor, type a few commands, bake, exit. All without touching the mouse. Utilizing the existing ecosystem of (amazing) plugins. Learning RhinoCommon and reinventing the plugins seems excessive for this purpose.
Seems like you just need to set up your main operations through GrasshopperPlayer, then you won’t even need to open Gh.