Clarification about GH_Component, GH_Param and GH_Attributes

Hi,

I'm currently trying to understand to what extent it is possible to customize your own custom component.

First of all, I'd like some clarifications about the differences between GH_Component, GH_Attributes and GH_Param<T>

From mine understanding:

Both GH_Component and GH_Param<T> derive from GH_ActiveObject class, which implements IGH_ActiveObject(which inherits from IGH_Document).

Inheriting from GH_Component or GH_Param<T> grants you the possibility to build (not from scratch) your own CustomComponent or your own CustomParam.

What is the difference between those two classes?

A GH_Component is a class that inherits from the common base class GH_ActiveObject ("which is the base class for all objects on the canvas that actually do something"), and its pecularity is to take n input parameters (of type GH_"wrapper" <IGH_Goo>), to compute m result parameters inside its own SolveIstance function, and to return those results as output parameters.

A GH_Param<T> is a class that wraps an objects(which implements IGH_Goo).

For example, whenever you want to build a new complexDataType (which MUST implement IGH_Goo or extend an exisiting GH_Goo<T>), you will wrap this type in a new class that extends GH_Paramspan>complexDataType>.

Doing so, you also grant the possibility to your complexDataType to have its own capsule, usable on the canvas.

So, if you have to build a "basic" component, in one or both of those two classes you can find all you need.

But what if you want to define how it displays (on the canvas), its layout, or its event handling?

In the SDK documentation you can find an example suggesting you to use a IGH_Attributes<T> interface (or a GH_Attributes<T>).

GH_Attributes<T> (where T is a class that implements IGH_DocumentObject) gives you all the functionalities to resolve the lack of configurability described above, overriding some of its methods.

In the same example, the class that extends GH_Param<T> and the other class that extends GH_Attributes<T> bind themselves through the constructor of GH_Attributes.

Now:

- If I want to define a GH_Attributes<T>, do I also have to provide its respective GH_Param?

- How should I assign a GH_Attributes<T> to a GH_Component? (the only example in documentation clarifies how to assign it to a GH_Param, not a GH_Component)

-Is it right to say that this way opens every possibility to the a GH_Component customization?

I'd be very glad if you could correct what I said above, and it would be great to have a complete example of a complex component (like "Legend", or "QuickGraph", ..).

What is the GraphMapper Component? Is it a GH_Component, a GH_Param<T>, neither of those?

I refer to those component because they group all the functionalities id like to implement on a CustomComponent.

To be more specific, how should I build a Component to make it receive inputs through default wiring techniques and also through user interaction over the displayed component itself (like GraphMapper)?

I can image there will be a lot of code to write, but I'd like to know where to start from.

Hope everything is clear,

Thanks in advance.

Luca

Replies to This Discussion

Permalink Reply by panhao on May 22, 2014 at 10:17am

GH_Component also has a method called CreateAttributes().You can override it following the GH_Param tutorial.The display class can be GH_Attributes or GH_ComponentAttributes.

Your GraphMapper component can be a sub-class of GH_Param or GH_Component.And if you want to have more individual properties. Inherit from GH_Component is better. Rendering methods in GH_Attributes are all form GDI+.

Permalink Reply by David Rutten on May 22, 2014 at 10:37am

Hi Luca,

you're pretty close, here's the basic breakdown.

All objects that want to be part of a GH_Document must implement the IGH_DocumentObject interface. This interface provides core methods needed for all objects, such as Undo, Autosave, Display, Menu and Tooltip functionality. IGH_ActiveObject extends upon IGH_DocumentObject and it provides methods used for participating in the solution. (Incidentally this distinction is gone in GH2, I'm using a single interface now which covers everything).

Some objects which only implement IGH_DocumentObject are Jumps, Scribbles and Groups, pretty much everything else implements IGH_ActiveObject.

That's basically all you need to make your own objects, however making parameters and components from scratch is a boatload of work, so I've provided classes with basic implementations for these types of object.

Parameters (via the IGH_Param interface and several GH_Param<T> classes) maintain a data tree which is associated with a specific type of IGH_Goo data. They have the logic build in that allows them to communicate with other parameters via their input/output wires.

Components tend to derive from GH_Component (or at the very least implement IGH_Component), as that class provides all the bookkeeping methods for managing a collection of input and output parameters.

You are more than welcome to implement IGH_ActiveObject from scratch, but you'll probably spend months getting it right because there is a lot of stuff that matters.

------------------------------------------------------------------------

Attributes are used primary for display purposes. Every object must be capable of creating and maintaining a class which ultimately implements IGH_Attributes. The attributes are in charge of rendering the object to the canvas, providing basic information about the shape of an object, handling mouse and key events, responding correctly to selection actions, and (in GH1 anyway) maintaining the object hierarchy. Basically, it means that component attributes must be able to 'talk' to input and output parameters, and the parameters need to be able to figure out they are slaved to a component.

-----------------------------------------------------------------------

Usually it's sufficient to derive either from GH_Component or from GH_Param<T> (or GH_PersistentParam<T> or GH_GeometryParam<T>) and override the default attributes. Doing this allows you to change the way the object looks and to change the way the object responds to mouse events.

What sort of exotic object are you looking to create?

David Rutten

david@mcneel.com

Permalink Reply by panhao on May 23, 2014 at 4:09am

Hello David

It takes me about a week to understand the drawing sequence of the capsule.The class tree seems have too many branches.And it makes the code difficult to read.You said Grasshopper2 will use a basic interface.A good news!

Where could I get the latest news about Grasshopper2. Do you have a github repository？CouldI put forward my proposals?

Permalink Reply by David Rutten on May 23, 2014 at 4:59am

You can certainly put forward proposals. The code isn't currently available anywhere online and I don't know if we will open source all of it. I'm rewriting the program from scratch, trying to achieve the following:

DataTrees will be made more consistent. No more distinction between DataTree<T> and GH_Structure<T:IGH_Goo>. All functionality (path mapping, grafting, simplifying) will be available directly on the core datatree class itself.
Naming will follow standard .NET guidelines. Classes are no longer prefixed with "GH_".
Functionality from attributes will be moved into objects, basically, objects need to be fully functional without any attributes. Attributes should only be necessary when the object is drawn on the screen.
Multiple canvasses.
More events.
Unmutable types. I'm trying to make as many structs and classes unmutable as possible. This should vastly improve the reliability of the runtime and make it more threadsafe.
Adding threaded and async overloads for time consuming operations.
Disassociate the UI from specific frameworks (GDI+ or Direct2D or WPF for example) and make it cross-platform.
Improve basic consistency, both in naming and functionality.

Although cleaning up the SDK is a major goal in GH2, do note that pretty much all the functionality is needed to do what Grasshopper does. I.e., there won't be any less of it, hopefully just better structured.

David Rutten

david@mcneel.com

Permalink Reply by panhao on May 24, 2014 at 7:03am

Is it possible to add a option that write scripts in viusal studio and then use csharpCodeProvider to compile and use Reflection to run.It is much more like what the C# component does.Writing in visual studio is more convenient.Or if the new Grasshopper have a public class about C# Reflection...


Hope to see a powerful Grasshopper2.0.

Permalink Reply by David Rutten on May 24, 2014 at 8:21am

You can write (and debug) components in Visual Studio if you create a GHA project. Giulio wrote a set of project wizards for this so it should be very easy to set up. Is that not what you're after?

David Rutten

david@mcneel.com

Permalink Reply by panhao on May 24, 2014 at 1:50pm

Well I have two ways to debug in VisualStudio while Rhino is running.Either reload Grasshopper or use C# Reflection in C# component.Reloading grasshopper makes a lot of trouble when I need to change parameters frequently.Using C# Reflection in C# component brings strange exceptions sometimes.Maybe I should understand how C# component works completely. That is a difficult task with Reflector.

Permalink Reply by panhao on May 24, 2014 at 11:13pm

Maybe I can follow ReadFile component to write one.

RSS