Wow, that’s a lot to take on in a single reply
I have been putting effort in lately to try and update documentation on all of these python and RhinoCommon related topics, but we are still a long way from where I want us to be.
As a first thing to note, I plan on taking down the python.rhino3d.com web site and have been in the process of moving “stuff” that is on that site to either the wiki or my personal blog.
My goal is to have the primary landing page for Rhino.Python to be
http://wiki.mcneel.com/developer/python
and my old blog on python.rhino3d.com has been moved to
http://stevebaer.wordpress.com/
Both of these are actively being updated this week in order to try and be a bit more useful.
On Windows, I would say the easiest editor for people getting started is the one you get when you run “EditPythonScript” in Rhino. The editor has autocomplete and a debugger that allows for stepping through code and evaluating variables.
If you want to use a different environment, there are several great editors out there.
- We use pycharm by jetbrains for developing google appengine python scripts, but we don’t use it for Rhino (at least not yet.)
- PyDev is also popular and @frist was able to get it to work with remote debugging (very cool). http://discourse.mcneel.com/t/external-python-debugge
- There are a boat load of other python editors out there, I just haven’t spent time researching them to be able to give any valuable feedback on them.
On OSX, there are also a large number of editors but we do not currently have “EditPythonScript”. This is very old, but I was able to use komodoedit successfully for Mac Rhino
I would say almost all of RhinoCommon has been reasonably tested. I typically only add functionality as it is needed so we can “dogfood” it. We used python and grasshopper as the “dogfood” to build RhinoCommon and it continues to be the platform that these plug-ins directly depend on to interact with Rhino.
RhinoCommon will continue to be enhanced with new functionality, so I can’t really comment on the status of intended functionality.
VB.NET will probably be easier for designing user interface since things tend to integrate nicely in Visual Studio. That being said, these same tools could be used to develop UI for python. UI is always going to be a bit of a hurdle to learn no matter what language you choose. We used to use WinForms and are now finally switching to WPF since it provides for a clean separation of UI and the logic behind the UI. It is a pretty steep learning curve for getting started with WPF though.
StarMaker – An advanced sample | Steve Baer's Notes
I would say there is a difference. Python scripting ends up being one or more .py files, where a DLL is a compiled assembly used by the .NET framework. We haven’t put a whole lot of research into compiling python into .NET assemblies.
RunPythonScript works great on Mac and almost everything works. Where we need to make some adjustments is with scripts that use some “precanned” user interface elements like ListBox since the current user interface pieces for those functions assumes you are running on Windows. I know how to fix these, I just haven’t had the time yet.
EditPythonScript does not exist on Mac. I want to experiment with doing a better job of allowing external python editors to work with Mac Rhino so we don’t have to write a new editor there from scratch.
We need to write better tools for creating and debugging Rhino Mac user plugins. Currently, if you knew all of the proper hoops and rain dances that need to be done, you could build and debug a RhinoCommon based C# plug-in on your computer today. The problem is that there are a lot of hoops and dances still.
Hope this helps more than just cause more confusion.