Feedback from the 1st October 2012 meeting

Hi Guys,

It was great seeing you all at our last London-GH meeting at AKT II. As suggested by Daniel Bosia, Paul and I have compiled the main topics that were discussed to submit them to the McNeel team. Below is a list of the two main topics, please feel free to add to the list or reply.

1) Collaboration on a common GH definition:
-What is the best way of dividing definitions while still keeping them linked?
-Can GH definitions be accessible by multiple people at the same time, in a similar fashion to google docs for example?
-Can changes to a definition be recorded so any other users could find them?
-Can all wires be turned off to avoid any "spaghetti effect"?

2) Understanding the definitions:
-What is the best way of organizing definitions for others to understand?
-What happened to the remote control which helps isolating the parameters?
-Can there be a "grasshopper to English" translator?
-Can there be a Grasshopper Viewer that doesn't require a Rhino install?

Paul and Arthur

Replies to This Discussion

Permalink Reply by Arthur Mamou-Mani on June 27, 2013 at 5:18am

Here is an update from David Rutten, dated 26 October 2012, replying on the wishlist above.

1) Collaboration:
- There is no way at present, excepting referenced clusters.
- No. Grasshopper reads a file but doesn't lock it, so when two people open the same file, whoever saves last, wins.
- No. I think recording changes will be part of the same effort that will also involve storing the Undo data in the GH files. I designed the Undo/Redo system in such a way that it is (de)serializable, but it was never hooked up.
- It would be fairly trivial to add an option for hiding all wires, long wires, wires connecting components that are not visible etc. However I think that the spaghetti effect is a result of a much deeper problem. I think we need to find ways to reduce the number of individual wires and make files more readable. Layers would be one way of solving it, but I can think of some other potentially interesting mechanisms.

2) Readability
- Groups are good. Panels with explanations or Scribbles can also help. Layers might be good for this as well. If people have specific ideas, I'd love to hear them.
- The Remote Control Panel was dropped when I switched SDKs (from Rhino_DotNET to RhinoCommon). RhinoCommon back then didn't allow .NET plugins to create Rhino docking dialogs. By now Steve has added this functionality and the RCP is (along Cluster improvement) the #1 priority for Grasshopper 1.0. Unfortunately both are rather big projects so it's slow going.
- Grasshopper2English sounds very ambitious. Especially when stuff starts to happen in parallel. What problem will such a feature solve?
- In theory, yes. The GH file format is not defined, which is problematic. Each part of a GH file is read by whatever object is relevant, and each object can decide for itself how to write data to a GH file. This makes it difficult to read GH files without having access to those objects. It is however possible to do at least some partial exploration to try and extract names, nicknames, descriptions, positions and sources/recipients of objects in the file. Icons will not be possible.

It sounds like a lot of this stuff would be excellent fodder for Grasshopper 2.0 Wip development, once Clusters are good enough and once the RCP is back in I'll start talking to Bob about what it means exactly to have a Grasshopper 1.0 out there and where to go next.

Another big project which we've just started (i.e. hired someone for) is the writing of the Grasshopper help file(s). I'll do the coding required for the help file display/search etc. and Kaitlin will be in charge of actually writing topics and providing example files. This will certainly not be finished for GH 1.0, in fact it might not even make it into the public 1.0 releases. But Grasshopper is now a two-person project at least.