Hi!
I know that things are not so easy as photoshopping an image, but still…
What if the connection would be as simple as this ?:
1 Like
Hi 
I think something more like this image can be made in Rhino 8 with RhinoCode; Rhino 8 Feature: RhinoCode (CPython, CSharp)
Yes, it could be possible, still, having it on Hops is more appealing.
You can code, test, use any package, any api without even starting Rhino.
You can use your favorite ide.
and once it’s done you just hook the inputs you need to GH via Hops.
1 Like
I prefer to be a bit more explicit about what the inputs and outputs are for hops instead of randomly guessing at which variables in a script are important. The ghhops server provides a lot more functionality than this.
Well from what I see it requires a lot of “setup” before doing some a plus b…
What I sketched can still use the server…
well, since python is an object oriented language we can assume a hops type object…
The python script has to set up a server instance. There’s no way around that.
When you introduce intermediate variables in your script which always happens then we would need some way to explicitly set or exclude items.
yes, and all this can happen under the hood no?
User should specify:
- the program to run
- maybe the localhost address
- and input variables
and the output gets picked back into gh. I mean, by the way hops runs now, things are already possible. it just needs to be more user-friendly.
I guess I should just say no 
I’m not going to do this.
Hops and the ghpython server are both open source. You are welcome to prove me wrong and implement this yourself. If it works great, I would consider rolling it into hops.
1 Like
Come on, don’t be so negative. 
Think about those ppl who just started with python. They will not have patience to go though all the setup. They want to test things on-the-fly. And, they expect something similar to the GHPython component.
While a Python user would expect a pythonic object.
And the stuff is already there (it just needs some “interface” polishing)
I would argue that python beginners are just not the target audience for the ghhops-server feature. Furthermore I don’t think it would make any sense to redesign it to be as easy and user-friendly as you propose, instead I would highly recommend starting somewhere else as a python beginner.
Hiding complexity and making everything super easy and user-friendly adds a ton of overhead, this would be, frankly said, every developers nightmare. I clearly see the benefit in ghhops-server in being able to define very explicit and unambiguous Grasshopper Components in Python and using advanced Python libraries.
3 Likes
Hi @efestwin
I’m quite inclined to argue the opposite. While there are plenty of options for the advanced python users (considering by the amount of GH apps already existing), not so much is done for the python beginner.
Further, I might say, that the language itself is very easy to learn. More tricky is to figure out how different packages work. And this is where the fun might come for the beginners. Skip the “geeky stuff” and just bring me closer to my drawing.
After all, Rhino is intended for designers first, and not so much for the programmers.
If you want to run a script like you posted a screenshot of just use GhPython. That keeps things simple for people starting out with python.
My feeling is that it won’t get much easier than GhPython Component / EditPythonScript in conjunction with rhinoscriptsyntax. There is excellent tutorial material on these topics out there, also by McNeel themselves.
If people want to code, it is just what people will have to learn and deal with. Every language has this, there is no way around it (but maybe I’m not understanding you correctly, sorry if that’s the case).
Isn’t this the prupose of Grasshopper without scripting components? GhPython is already extending Grasshopper’s functionality. So it is already geeky so to speak, since you’re “extending the extension of Rhino” when using scriptable components.
Another thing would be: The more you simplify programming, the less powerful it will be. We can already see this with Grasshopper - and don’t get me wrong - Grasshopper is super powerful but also has a ton of overhead if compared to coding everything in C# or even Python using RhinoCommon.
Just to make sure that things are clear, please let’s go again trough my sketch image above:
- There is some data in Grasshopper
- It gets into the Hops component (similar to the GHPython component that you already have)
- From Hops it goes to the GHServer (which you already have)
- It reaches the Python3 code written in the VS coder (which you already suggest)
- It gets compiled there, in parallel, using any of those 3250307 packages released on PyPi.org
- The compiled data goes back into the GHServer and as an output of Hops into GH.
So I honestly don’t understand where is the problem here.
@stevebaer ,
Many of those packages on PyPi are far more easy to use than rhinoscriptsyntax itself.
They also get updated and documented by those people that make them. So if one gets depreciated it’s very easy to find another.
People need to learn up to a certain level. For example, if we take this Prime numbers generator, released yesterday. It takes 1 click to install, and 2 lines of code to get what you need. (the prime numbers) There’s no need to learn or understand what that guy did in those 214 lines of code written in the package.
So with my suggested approach you make any python package out there available to users, in a very elegant way. (unlike the mess of “ported” code that we see now in many of those GHapps on food4rhino(but that’s another discussion) )
So, again, I don’t understand why is this complicated to implement, since it seems that most of it is already there.
We already support pypi installed packages in native cpython in Rhino 8. We will also be writing a cpython scripting component for Rhino 8 which will support these packages.
2 Likes
Well, that’s good to hear.
Still, I find the Hops component more attractive.
Is it possible to further develop it for R8 and include it in the wip?
Andy has been working on hops quite a bit lately and posting updates to the package manager. We don’t plan on directly including hops with Rhino 8.
That’s totally reasonable, since it’s a niche feature, although a neat one. It’s good to hear that as such development is nonetheless maintained.
Tends to become little bit too niche for the amount of work put into it and the possibilities.