Creating Rhino/GH Plugins in Script Editor

@Steven_Nie Yak does not build plugins from scripts. It is mainly a tool to package .rhp files as .yak files. ScriptEditor creates a .yak package for you automatically from your scripts. The src/ directory and its contents are merely for you to possibly change the source of the plugin.

Does that make sense?

Yes! Is there anyway to build scripts plugins via the command line? We just want to automate this process as much as possible. Thanks!

Yes. Take a look at this guide on the new rhinocode utility that is shipped with Rhino *

1 Like

Thank you Ehsan, I run the command and I immediately got this exception:

ynie:rhino (1.00016) % rhinocode project build rhino.rhproj --buildversion 0.1.1234 --buildtarget "8.*" --buildpath build
Unhandled exception. System.UriFormatException: Invalid URI: The format of the URI could not be determined.
   at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind, UriCreationOptions& creationOptions)
   at System.Uri..ctor(String uriString)
   at RhinoCodePluginCLI.Commands.ProjectCommand.ProjectBuild(ExecArgs execArgs, String[] args) in /Users/bozo/TeamCity/buildAgent/work/96e64af5b81c6f85/src4/rhino4/Plug-ins/RhinoCodePlugins/RhinoCodePluginCLI/Commands/ProjectCommand.cs:line 123
   at RhinoCodePluginCLI.Commands.ProjectCommand.Execute(ExecArgs execArgs, String[] args) in /Users/bozo/TeamCity/buildAgent/work/96e64af5b81c6f85/src4/rhino4/Plug-ins/RhinoCodePlugins/RhinoCodePluginCLI/Commands/ProjectCommand.cs:line 109
   at RhinoCodePluginCLI.Program.TryExecuteCommand(Command command, ExecArgs execArgs, String[] args) in /Users/bozo/TeamCity/buildAgent/work/96e64af5b81c6f85/src4/rhino4/Plug-ins/RhinoCodePlugins/RhinoCodePluginCLI/Program.cs:line 145
   at RhinoCodePluginCLI.Program.Main(String[] args) in /Users/bozo/TeamCity/buildAgent/work/96e64af5b81c6f85/src4/rhino4/Plug-ins/RhinoCodePlugins/RhinoCodePluginCLI/Program.cs:line 49
/Applications/Rhino 8.app/Contents/Resources/bin/rhinocode: line 3: 29303 Abort trap: 6           "$dir/dotnet/$(uname -m)/dotnet" "$dir/RhinoCode.dll" $@

Question about updating .RHP’s:

Is there a way to drag&drop an updated rhp to rhino without having to manually delete previous versions? It makes it cumbersome to keep a large team on the newest version of an rhp.

1 Like

RH-84373 is fixed in Rhino 8 Service Release 13

Hi @eirannejad,

First of all, it is great to have all these new possibilities in place with Rhino 8.
I played around with projects and tried publish project with IronPython and CPython to build a plugin and a toolbar for Rhino.
My aim is to use the plugin and toolbar architecture to deploy inhouse developments throughout our design team.

I made a couple of observations and have a couple of questions about it, that I could not answer with your new documentation.

  1. I started by using the option to add an existing iron python file to the project. The location of this file is: C:\Rhino8_Plugins\IronPython. This python file imports an inhouse module from a package that is in the same folder like this python file. Debugging into this script showed that the module from this directory is used for the import. I did not add a library to the project. The build with publish project worked. Installing and running this plugin also worked fine. I was a little bit surprised and tried to find out, which modules are actually imported. I found out that a completely different location is used for the import. I have to admit that I still have a parallel IronPython Plugin Structure running in Rhino 8 that uses the old Python Editor. The location for the commands, packages and modules is here: C:\Users\user_xy\AppData\Roaming\McNeel\Rhinoceros\8.0\Plug-ins\PythonPlugins The new compiled plugin created with the ScriptEditor picked up on this location and imports the module that is identical in this location. Is this behaviour as it should be?
  2. The module that is used via import inside the new compiled plugin can be changed and the changes are loaded once the iron python engine is reloaded through the ScriptEditor interface. Is it desired, that the imported modules are not compiled? Which python search pathes are used by the final plugin, the pathes defined in the Old Python Editor or the pathes defined in the Script Editor?
  3. Each time I want to rebuild the plugin, I first have to open the plugin manager deactivate the plugin, restart Rhino, publish the project and reactivate the plugin inside the plugin manager. The build folder is blocked otherwise. Is there a better approach for this?
  4. Did anyone try to add a larger iron python library to the project? Did it run through? I tried to add our entire iron python package and during the publish project procedure the build process is stuck at “Preparing plugin assembly”. I cannot stop this throughout the UI. I had to kill the entire Rhino process. Does anyone have an idea?
  1. and 2. → The pathes of the Old Python Editor has nothing to do with this. This was my fault. I had the path C:\Users\user_xy\AppData\Roaming\McNeel\Rhinoceros\8.0\Plug-ins\PythonPlugins added to the search pathes of the Script Editor. Changing this location solved one confusion for me. Nevertheless, the dynamic imports are not compiled and the order of the search pathes are flipped around comparing the compiled version vs. the sys.path in the Script Editor running the source code directly.

  2. → I also played around with the direct rhinocode interface outside of the Script Editor. %PROGRAMFILES%\Rhino 8\System\rhinocode project build my_tools.rhproj
    It seems like “Preparing plugin assembly” does not get stuck. The process still uses 8% of CPU.

I never did that. Nothing is “blocked”. After publishing an active project, I restart Rhino and I have the new Version of the package installed.(My package manager source is the build folder)

I am using the default folder „build“ that is set by the publish project UI.
If Rhino is closed, I can probably use the rhinocode project build and do not have to do anything with the Plugin Manager.
How do you do the rebuild? Do you use the UI inside the Script Editor or do you use the CMD interface?

I am not touching the build folder and its content.(Besides small changes inside the *.rhproj) When I am want to rebuild the project I am just using the functions/UI of the script editor. The Idea is to stay in the Rhino environment. Are you maybe crosslinking Assemblies/Libraries? Normally Rhino is copying every file of the package to a special folder. After Install there should be no connection to your build folder.at all.

As far as I know, I am not crosslinking Assemblies/Libraries. I navigated to the build folder and did drag and drop to install the plugin, just as it is shown in the video at the beginning of this topic. Did you install the plugin differently?

@daniel.kowollik

I am glad 1 and 2 seem to be resolved. The new scripting infrastructure has NO ties to the legacy system. Python module search paths are adjustable from Editor Options with more advanced controls using Path Files

3 - Once a dll is loaded in Rhino it can not be unloaded. So I follow one of these methods for iterative testing:

  • Drop the generated yak package into Rhino for testing. Delete the package from Rhino’s %APPDATA%\McNeel\Rhinoceros\packages directory and restart Rhino. Build an install a new package. This method has the benefit of Not loading the dll from the build folder so you can keep building into the same folder
  • Keep restarting Rhino, build a new version, load and test
  • Build into incremental folders build\, build1\, build2\ and load from there

4 - I have not had issues with this. I appreciate if you can DM me an example so I can replicate and fix any bugs

1 Like

Hi @eirannejad,

is there a way to control the order of toolbar buttons in the rui file which gets written to the build directory ? Background is that i had to add another command / script to my project but it should not be the last button in the toolbar. It seems the order is controlled by the order of the commands in the project.

Is there a way to add a right mouse button command / icon to the toolbar ?

btw. found a small issue with command / script icons: if an icon saved from the new svg editor is added to a command, it is not displayed. But once the edit icon dialog for the command is reopened it is shown properly.

_
c.

@clement
Yes, there is. For both issues.

Check my post in the forum. I had the same problems as you.

Greetings,
Leon

Thank you @leonbrohmann, i’ve had a look inside the project file too and found that it might be possible to change the order manually. But it would be a nice feature to control it from the ScriptEditor.

If i would have to make the changes to the toolbar myself and these are only stored locally, i still have the problem that i publish a toolbar without changes.
_
c.

Replying to myself, in case anyone else is wondering:

I found that if I place the distribution files (rhp/rui) in a shared folder - in our case OneDrive - the update process is pretty painless. Folks use PluginManager to install from the shared folder, and when I have updates, I simply replace the rhp/rui in that folder. As long as the GUID is the same, it simply loads on everyone’s computer as the newest version! No muss no fuss! It does require that no one can be using Rhino at the time of the switcharoo, but that’s easy enough to manage.

2 Likes