Partial Developer Absence

Dear GH users,

over the next 3 weeks (till November 12th) I'll be in Seattle at McNeel headquarters discussing the road ahead for Grasshopper 2.0. I'll probably have very little time for support and discussions during this period.

The major topics discussed for GH2 during this period will be:

Documentation/Help
GHA/Cluster/VB/C# App-Store
Localization (i.e. languages other than English)
Constraint Engine implementation
Improved VB/C#/Python development tools
Multi-threading the solver
Building a Mac version

If you feel something important was left out, please let us know here. Note that incremental improvements and bug-fixes are not worth discussion as we'll try and get around to them no matter what. Topics on this list have to fit the "Are we going to try and do X?" format.

David Rutten

david@mcneel.com

Tirol, Austria

Replies to This Discussion

Permalink Reply by Mostapha Sadeghipour Roudsari on October 11, 2013 at 7:46am

Compile Grasshopper scripts to .dlls
Building also a Linux version

Permalink Reply by Sridevi Koonath on October 11, 2013 at 7:53am

I would love to have Rhino & Grasshopper run on Linux as well.

Permalink Reply by David Rutten on October 11, 2013 at 8:12am

If Rhino ever goes to Linux then Grasshopper will probably follow suit.

David Rutten

david@mcneel.com

Tirol, Austria

Permalink Reply by Sridevi Koonath on October 11, 2013 at 8:26am

Will Rhino ever go Linux?

Permalink Reply by David Rutten on October 11, 2013 at 9:51am

I doubt it. But then we also thought that Rhino for Mac would never happen... Perhaps all it takes is someone with the necessary coding chops and drive to convince Bob this is a worthwhile investment. That's how Marlin did it for Rhino Mac.

David Rutten

david@mcneel.com

Tirol, Austria

Permalink Reply by David Rutten on October 11, 2013 at 8:13am

Hi Mostapha,

these dlls, you imagine them to be Rhino plugins (RHP)?

What's the benefit of having a dll as opposed to some other way of automatically running a GH file as a command?

David Rutten

david@mcneel.com

Tirol, Austria

Permalink Reply by Mostapha Sadeghipour Roudsari on October 11, 2013 at 8:54pm

Hi David,

It is something more inline with what Mateusz asked for as his last bullet point. As all the Grasshopper scripts can be converted somehow to lines of codes I was thinking if you can find a way to compile/convert the scripts into dlls. The user can then call them into other platforms including web. Processing is a very good example.

I just see it as what you've already done with Clusters but the result is a file instead of a grasshopper component.

Thanks,

Mostapha

Permalink Reply by Gui Talarico on October 14, 2013 at 11:52am

What would be the "other way of automatically running a GH file as a command"?

Permalink Reply by Lee, Jong-Hoon on October 27, 2013 at 1:14am

linux version -_-; nice!!!!!!!!

Permalink Reply by Anders Holden Deleuran on October 11, 2013 at 8:31am

Regarding improved GHPython development tools:

It would be great if the Python component was promoted to vanilla Grasshopper. This is mainly a headache when issuing definitions or user objects which use Python, but I suspect it would also lead to a more robust component. I'm sure this is probably already on the table.

While on the subject, these are the current GHPython issues I find most pressing. In order of importance:

- Add the ability to convert a GHPython script into a stand-alone gra...

- Add Grasshopper assembly for easy import.

- Presentation hints problems.

- Shortcut or button which "Collapses" all functions, classes etc.

Not sure if these issues count as incremental or not. Better safe than sorry right :)

The Constraint Engine sounds very interesting!

Have fun in Seattle,

Anders

Permalink Reply by David Rutten on October 11, 2013 at 9:01am

I'm sure this is probably already on the table. Indeed it is.

Improvement of all core programming environments in Grasshopper (of which Python will be one in GH2) is a high-priority thing certainly. It is also unfortunately the one thing where I see many problems ahead. It's very difficult to write a good code editor and nobody in McNeel has the time nor the know-how for it. We're always looking for 3rd party alternatives but QWhale Editor.NET still seems like one of the best options out there, despite the fact that is sucks pretty bad.

If you have anything you'd like us to take a look at, here's a list of demands any code editor has to fulfill:

Support for C#, VB and Python (that includes LINQ)
Intellisense for all .NET assemblies
Autocomplete
Ability to have readonly lines in a multi-line view.
Code collapse.
Ideally a pure managed piece of code, or, failing that, 64-bit compatible.
Licensing that allows redistribution in a commercial product with either no or a per-developer fee.

David Rutten

david@mcneel.com

Tirol, Austria

Permalink Reply by Vicente Soler on October 11, 2013 at 1:40pm

I posted this in another thread but I don't think I got a response.

Have you looked at Visual Studio Tools for Applications for this?

http://www.microsoft.com/en-us/download/details.aspx?id=30749

It's described as:

Microsoft Visual Studio Tools for Applications gives you a way to enable end users to customize your existing applications using Visual Basic and Visual C#. You can incorporate a custom integrated development environment (IDE) that is similar to the Visual Studio IDE into the application.

I don't think it supports python, though.