Why not make a “globals” script component then, and connect it to whatever components using the info?
// Rolf
Yes, this is one of the options I’m working on right now. Idealy I wanted to avoid having to connect with wires, because I’ll have thousands of these components, in the final version of my project, cross referencing each other. This is why I started reducing the number of components.
First it was with data input/output, then I moved to sticky where the amount of components increased but I ditched the wires. Unfortunately introduced the need for the Timer component.
Then I tried to implement it all in one component but some showstopper issues appeared. Here’s the thread about that:
Going wireless in a flowbased network is… well, like skipping the car when going for a road trip and flying along the road instead. 
// Rolf
1 Like
Worth the try 
, You can find components on the canvas, why not access what’s inside them.
Currently I try to create global stickys sending their labels to “Panel”, so I get a list of their labels.
Then I can find that Panel get the list and use the labels to assign values to the global stickies. At least that’s the idea, still not working, though 
.
If you wonder why would I make a list of sticky labels: I placed a button to generate new guids that I attach to the labels to make them unique.
Regarding the “too many wires” problem, I can give you a hint relative to the picture you sent earlier.
You can divide all the “Bulb settings” into a single input, and use your own class to input that as a single input. Make sure your input classes are immutable, and it will behave just great.
Then do the same for “Parallel Midship settings”… etc. Group them into settings/info/modes (like “Custom Mesh settings” works for inputting settings with sliders in “Mesh Brep”).
That’s how a relatively simple way to keep wires in check and use the way Grasshopper is supposed to work.
Does it help? 
Perhaps this:
Will help more, if I drink alcohol.
This topic is related to this one:
And not to the pictures I’ve sent to you over PM, which should stay in PM.
Now concerning this:
I learnt how to create custom types, but afterwards how can I get the data from them still avoids me. i.e. from goo to get the 3d object for example. But that’s a topic for a new thread (from the hundred yet to be created).
I wonder if Karamba guys got the same answers from McNeel when they were developing their very appealing and useful customization to their components? Btw I’ve read some of the threads on the old forums and McNeel were very helpful customizing how components look. Tasting the double standard, or perhaps over the years attitude towards customers changed? There were examples, a lot of them. The problem for them not being helpful to me is that they are in VB or Csharp. Especially VB is simply unreadable to me.
So, perhaps it really isn’t the “attitudes” that is the problem then?
// Rolf
oh no, it’s the attitude, as instead of helpful examples I get ignoring and discouraging comments.
IronPython is supported to the core right now. Should csharp “native speakers” get python examples, like I have to work with csharp exampels?
Only a couple of months ago I had never written a line of C# code. And the people who had solutions spoke C#. I didn’t think that they showed “attitude”, instead I learned C#, because that was the way to go for what I was trying to do.
IronPython has its application, and users tend go only so far using it. Which means that the trickiest stuff is done with VB or more likely, with C#. And that’s the language where most of the experience of the more advanced tricks is.
It’s as simple as that.
// Rolf
1 Like
Something must be cleared out, I don’t put negative meaning to the word “attitude”. I’m not talking about “bad attitude” them being rude or something. They just deflect. Also I don’t say they deflect all my questions, just the ones regarding change of component gui.
I wouldn’t mind learning csharp, I already have some simple applications done with it. I mind having to spend the time to learn all the necessary assemblies and links and calls all over again with the unfamiliar APIs. I don’t work with Rhino, the time I spend with Rhino/GH is after work when I have time. By not getting python examples, which is very readable to me and I use it at work (not IronPython but still similar syntax), I have to spend weeks of my limited free time to figure out how to translate it to python. Over half of my tries end up failed.
The need to declare every single stupid thing with the type is too non-pragmatic. A waste of time and effort.
That’s one reason to not translate it to Python.
I spent some thirty of my best years on Delphi Pascal. I couldn’t read any other syntax. A couple of month ago I thought C# looked like… I had nothing to liken it with.
And everything new you learn about RhinoCommon/GH can then be foused on C# (which was the stage in which I thought I might as well adopt C# and go right at it). And that will get you faster to where you want (just leave out the translations to Python and you will save a lot of time…)
C# took me some 2 or 3 weeks to get used to (It became “readable” much sooner than I had expected). And I’m not in my twenties anymore. 
// Rolf
Types isn’t a big thing at all. You are forced to use the types in Rhino/GH which you also will use in C#. And BTW, I don’t understand why many people declare types twice on the same row. It looks strange to me as well. Why write like this:
List<Point3d> pointcloud = new List<Point3d>();
… when you can write like so and still explicitly declare the type:
var pointcloud = new List<Point3d>();
The compiler can still “guess” the type, no need to repeat it on the same line. You’ll get used to it, don’t worry.
// Rolf
1 Like
And I’m absolutely sure, if Pascal was supported as Python is, you’d bang your head asking for Pascal examples.
There aren’t many languages that I cannot read (except for VB and ASM probably, I tried learning ASM some 20 years ago during my wanna-be-a-hacker phase ). What the hell hit in the head the developer of VB for him to come up declaring variables with dim?
Anyways, reading is one thing, writing the code is much different. Good luck with csharp.
The other thing that infuriates me is…Python was supported since, v4 if I’m not mistaken. Why still deflect python questions?
Karamba3d and Solemma are clear examples how “in-component” controls drive true creativity. But no!
Why not just remove that from the API?
If it’s possible to change it, please give working examples in all languages RH/GH support.
1 Like
There’s an example here: Setting type hints in a Python component. This is really the way classes should be used in Python and Grasshopper, and it’s really straightforward.
We are not deflecting pure questions. There’s a difference between a “question” and a “demand of custom development”. The guys of the other mentioned add-ons decided to pursue roads of heavy GUI change of Grasshopper. They did it on their own with the public tools provided by our SDK, and we did not provide them with additional tools and they did not start “hundreds” of threads. They were simply experienced enough and did it. Some of these changes were unnecessary and are unrelated from the geometry of the add-on itself, for example I find Millipede too different. Now, I believe you will get experienced enough one day, to be able to define your own GUI and, if you want, basically re-write Grasshopper from scratch. But right now, you should really focus on getting the “primer” part working, because every big task needs its steps and “Rome wasn’t built in a day”.
Python is not suggested for GUI change. As already mentioned earlier, you will need C# for that.
Finally, I am on vacation from today till September, so the rate of my replies will diminish. Alain and Steve will be here.
1 Like
But feasible.
All I want is simple in-component gui capsule (button) example with python, that will give me the directions where to look for more advanced stuff.
Adding a toolstrip menu items is the level of “feasible” for which McNeel is going to write UI samples in Python. Re-writing Grasshopper UI defeats the purpose of “support” and opens the gates of custom developments. Learning C# is immensely easier than what you are asking, so please start there.
1 Like
Come on man, are you really going to continue with this “add menu items” slap in the face.
Support will never lose its purpose, simply because Rhino as 3d modeling engine is closed. Bugs will always appear, new features are definitely required for Rhino to stay as competitive as it is, even more.
How did you make the decision to integrate Python? It was because Python is highly popular among engineers and scientists (creative people, non programmers by education). Even you and David, are coming from this group. Opening this gate will boost creative people to create really unique useful stuff. So withholding information like this will prevent creative people to realize their ideas, while some-non creative people will butcher the UI with csharp simply because it’s their “native” language. Learning C# in most cases is not an option for full-time engineers and scientists, compiling, debugging, opening Rhino every time you want to test your script is slowing the process too much. Adding scripting components was the smartest thing until this moment (opening the gate).
It is feasible to use IronPython to create the same things csharp can do. Show a simple button example. Arguing about this took a lot more time than it would to create such example.
Design is about domesticating creativity. About reducing alternatives, to as few as possible for an end. Integrating that which serves that end.
You are suggesting disintegration. A nighmare in software design.
Rhino has a purpose. Designed for an end. C# is one of the (reducing) choices made. 99.9999999999999 of everything possible, but not desired, was simply excluded. Because what is possible is not always desired. Like with any designed product.
Learn C#.
// Rolf
1 Like
There’s a fine line between support and custom development, and I am drawing that line right after “Adding more menu items” and before “Creating new UI” in Python. See the Millipede link above for an example of what I am not going to write. You have the tools to do it, though, but I would not suggest it. Thanks.
1 Like
Only a couple of months ago I had never written a line of C# code
Same, and was really surprised how quick it was to pick up, with the help of tutorials and others. C# may seem redundant in declarations ect. but I personally like it, just makes the structure of things easier to understand and keeps potential messy code in check. Especially, when you have to go back to a code you haven’t looked at in months 
Also, the obvious benefits being it is the most documented language on the web and has tons of 3rd party libraries. It is very unlikely with C# to have a question that someone else hasn’t already solved online. Lastly, C# is faster and who doesn’t like more speed in grasshopper. 
2 Likes