difficult namings in rhinopython document reference choice

[piac]

Modify some explanations based on this: http://www.grasshopper3d.com/forum/topics/this-call-is-not-supported-from-within-a-grasshopper-component?xg_source=msg_forum_cat

[piac]

Anyone's suggestions are welcome!

[bengolder]

I strongly agree that this is the single most confusing aspect of the plugin, and I'm not quite sure why it exists. In general, it seems like the Python component should behave in a manner similar to C# and VB.NET scripting components, neither of which rely on the user to make decisions about the namespace used by the script (unless they want to). I think comparing it to C# and VB.NET scripting components is a good guide to setting an interface standard for the ghpython component.

Do C# or VB.NET components automatically convert objects to ids and hook up to the document? If not, it seems like it should be something handled by the rhinoscriptsyntax library itself. It really seems like something that should be 'under the hood', and perhaps switched within a script, not within the component itself.

[bengolder]

perhaps a component scope variable can be set, such as: script_target = ghdoc script_target = rhinodoc

..and so on.

[piac]

Yes, the C# and Vb.Net scripting components do not support RhinoScript at all. Grasshopper by itself does not support RhinoScript either. So they are not really eligible for comparison here.

The scripting variable can be set within the script like this:

import Rhino
import scriptcontext as sc

sc.doc = Rhino.RhinoDoc.ActiveDoc #sets the RhinoScript target to "Rhino document"
sc.doc = ghdoc #sets the RhinoScript target to "Grasshopper document"

About the "way" things are handed over, I'll try typing something to help the transition.

[bengolder]

Thanks Giulio!!

I see that the reason behind this is to be able to support RhinoScript, which is something that the GhPython component does alone, and which is one of its unique good aspects. I can now see why it makes sense to leave the doc as the default target.

I still think setting this variable is a confusion task to hand a beginner through the UI. Perhaps instead of having as a menu item, it could be set as a portion of default script.

In the C# and VB.Net components, there is a bunch of script text that is preset, partially editable, and collapsed. I think it might be helpful to have a similar division of space within the UI of the python scripting interface, and then variables could be set by a user within the script.

My hope in this is that it would hopefully address to cases:

• Copying and pasting a script from a website, and getting the same scripting variable as a result (so that the namespace can be included within the script).
• Ensuring that using someone else's script won't rely on the new user to have to determine and understand the different namespaces/script variables.
• Making it obvious that the namespace can be handled from within the script. It seems like the people who would have the most need to change the scriptcontext would be people with a moderate understanding of scripting, but they would need their script to work correctly for various new users.

If the text itself might seem like a bulky thing to include in the script editor interface, I think it would be very reasonable to leave it collapsed by default, along with some other useful import statements.

Thanks again.

[bengolder]

I'm not sure how this should interact with the id marshalling functionality, but I'm happy to help you think it over if you explain any dilemmas.

[piac]

There are no real dilemmas... It is really a question of whether it would be better to have a one-fit-all solution to obtain Guid as opposed to having roughly double the amount of "Hints", one each for geometry and the other for RhinoScriptSyntax guids. I'll see how it behaves with per-input-geometry/guids-choice, and then we can see if it works better.

About the copy-paste question: this is similar to the set up of hints in other components. Without these setups it is really hard to make the script work. Still: the point is very interesting.

[piac]

From 0.5 on there is no special "Mode" choice. Everything works as hints.

[bengolder]

fantatic! Thanks!