What can McNeel do to improve your development?

(Dale Fugier) #42

We’re moving to all online documentation.

I guess you could use the WebBrowser panel, which docks, to view the online docs.[quote=“Angel, post:39, topic:10491”]
A GUID, object name, current layer…, visualization mode inviewports to attach a small text to object and keep track on them.

Does the GetUserText/SetUserText commands help here?

(Dale Fugier) #43

Grasshopper does not have an optimization API. Rather, developers have chosen to build components to to help solve problems.

But I agree that documentation for Grasshopper and add-ons can be sparse. And, I know this is being worked on. @DavidRutten, do you have anything you can add to this?

(David Rutten) #44

Not much to add. Documentation is indeed somewhere between sparse, non-existent and useless for grasshopper 1, we hope to do much better for grasshopper 2, although we do not expect the help files to contain detailed information about the inner workings of algorithms used.

(Cottonbale) #45

Hi Dale,

How’s that ‘programming with rhinocommon’ coming along ?



a mapping table between Rhino-Commands - Rhinoscript - rs. Syntax / Phyton - Rhinocommon
would be really great.

and i would love to see a comment function or a link to discourse.mcneel in the rhinoCommon documentation and vice versa …



Language problem

(jmv) #48

I arrive a little late but for my part I find myself regularly limited by RhinoCommon on the management of the Rhino interface. (often because connections with native methods are not made) (other example the class Rhino.UI.RhinoEtoApp.MainWindow)

  • events can not be canceled (for example, a click of the mouse)
  • Management and access to the toolbar have disappeared.
  • the management and the access to the commands are innacesible (to stop a command in progress for example)

but i like Rhino too :slight_smile:

(Tj) #49

I only use C++ to develop for Rhino, so this may not apply to all languages:

Another vote here for documentation. The other large codebase I work with occasionally is Qt, and their documentation is utterly fantastic. It’s so good, in fact, that there’s almost no documentation for the Python wrapper libraries - you just get pointed to the C++ documentation. For reference, here’s the page for their pushButton clas. It incudes everything you ould possibly want to know about the class, there’s quick references to inherited functions etc, and a very good detailed description (it’s also a good representation of the rest of the documentation):

We could consider something like a community-driven wiki page to supplement the existing documentation (which I think is generated with doxygen…?). I wonder whether we could do something really clever to get user-added content on the wiki into the code comments/doxygen documentation. Perhaps an annual diff of the wiki page and the doxygen documents… Just a thought.

There are also a few things I’d quite like to see that I’m not sure have been mentioned yet:

  • I feel like .rui files are quite awkward to use (but ultimately get the job done).

  • I’d really like to see programatically changeable toolbar buttons. Our use case is being able to disable/grey-out some of the buttons until some criteria are met. I guess this ties in with easier toolbar creation/modification.

  • A levelled log would be really useful. We use a home-rolled solution at the moment, but supplementing RhinoApp.Print() with something similar to the Python log methods (https://docs.python.org/3/library/logging.html) or the boost logging methods (https://www.boost.org/doc/libs/1_64_0/libs/log/doc/html/index.html) would be really useful.

  • I’d really like to see easier Qt integration (although this is again quite niche, and I think could be a very tricky problem to solve). My issue is that we have some extant Qt widgets that I’d quite like to parent to the Rhino Windows, but given that this isn’t really a problem that Qt have solved yet, its probably a stretch to ask McNeel to solve it for Rhino. I suppose I should probably just go and lern eto…


(Dale Fugier) #50

It’s something we’re still hoping to do.

– Dale

(Dale Fugier) #51

I’m not sure how this would work, as there is no function equivalent to a command. Most command use quite a bit of the SDK. But I get your wish.

– Dale

(Dale Fugier) #52

Rhino’s toolbars are designed for end-user use. They generally don’t work well for plug-in developers.

You might have a look at the ON_TextLog class. You can then display it using CRhinoTextOut. The What command uses this.

This isn’t a direction we are heading.

– Dale

(jmv) #53

I think this approach is similar to my old proposition, integrate the existing resources to a unique point.

In my previous post, I failed to vote for the documentation. But of course, me too, my first problem with the development of Rhino is not the language or the technique but answers the question “what is this function for?”