Hi,
i had to recompile some scripts to a PlugIn Installer which have been compiled dozens of times using the RhinoScriptCompiler in the past. The output rhi file has been renamed to zip in order to include a ToolBar file and a Help.pdf document. Then the zip file has been renamed to rhi.
If the users try to install the PlugIn by double click on Windows 10, they get the following error:
What to do now ?
btw. this PlugIn is supposed to run under Rhino 6 and 7.
thanks,
c.
âŚjust in case someone else is running into this issue, the solution was rather simple:
Doing it this way it was possible to install with a double click in Rhino 6 and 7 under Windows 10. The PlugIn was installed into:
C:\Users\UserName\AppData\Roaming\McNeel\Rhinoceros\6.0\Plug-ins
C:\Users\UserName\AppData\Roaming\McNeel\Rhinoceros\7.0\Plug-ins
thanks,
c.
I thought I got rid of rhi as an output for the script compiler in Rhino 7. It should only be producing rhp and yak files. We are trying to phase out rhi in favor of yak. Now I need to go double check.
Double checked, the Rhino 7 script compiler doesnât produce rhi files.
Hi @stevebaer thanks, confirmed. I must have used a link in my toolbars to the old compiler. The one available from the menu does create rhp and yak without prompt in a bin folder (?!). Unfortunately, i do not know how to use the yak file. The PlugIn is not for public distribution.
Imho, looking back at the processes required to compile a bunch of scripts with support files into PlugIns has evolved away from the simplicity of the initial Monkey script compiler. The RhinoScriptCompiler with itâs commandline based UI is not a bad thing though once a project file has been saved and the PlugIn needs to be updated. (And the developer knows how to create an rhi since youâve removed that useful feature already). The key, at least for me, is and was simple updating and simple installation on the user side. Rhi was meeting these purposes, at least on the Windows side.
Yak appears to be a bit over my horizon due to complexity. Iâve never used Linux. Starting with the docs, itâs mentioning many technical terms iâve never heard of. Btw. the link on that page to âjoin the discussionâ points to nowhere. Would it be possible for the developer to create a simple video on how to use it, starting with the rhp and how (private) users then can install the PlugIn on both platforms ? Is this possible at all using Yak ? The docs still mention this:
Currently the only available package server is our public server. Self-hosted/private servers are on the roadmap however for now all guides will assume youâre using the public server.
I am not allowed to upload to public servers nor do i want to upload to any server to offer my clients a simple to install PlugIn along with support files. If youâre phasing out the simplicity of rhi in favour of yak, is there some awareness that yak is miles away from what we have know, or better from what we have had ?
thanks,
c.
You can put yak packages in a local (or server) directory and point to those as well @clement, it doesnât need to be hosted publically
Hi @csykes,
can the installation be done (on the user side), eg. with a double click if i send out a file via email ?
_
c.
Double click and drag/drop of yak files should be supported, but that may not currently be the case. @will and @Trav would have a better idea than me.
Confirmed, .yak is an unknown file type and windows wants to know the app to open with. Drag and Drop of a .yak file brings up the File Options dialog, clicking OK yields a message that the file type is not supported by Rhinoceros.
btw. is there a reason why the RhinoScriptCompiler does not preserve the upper/lower cases in the PlugIn name ? Eg. i have defined this PlugIn name: âCG_MyPluginNameâ the yak file name is this:
cg_mypluginname-0.1.0-rh7_0-any.yak
_
c.
Hey @clement, no double click sorry like the rhi in my experience.
You can install it using the yak cli, which isnât too tricky, but not user friendly per-say.
What we do at my company is to put it on a sharepoint/onedrive and have that directory sync locally and point to that by editing the Rhino.Options.PackageManager.Sources settings in Rhino to include this directory. I find it much nicer asking them to update using PackageManager than use rhis.
Thanks @csykes. I am able to cope with whatever is required to make it as simple as a double click for the end user. Unfortunately i have to asume that most of the end users have no experience with Rhino or with the OS they are using.
Explaining users to âClose Rhino, double click the file iâve send and then open Rhino to start with the ToolBarâ (which automatically opens) is what we did in the past. At least this worked the first time the compiled PlugIn was installed on the users system. Then McNeel changed the way PlugIns are installed by adding the PlugIn content into folders with random numbering and by just keeping the old install.
This caused that ToolBars where loaded from previous installs instead of the recent ones. Same goes for included files like updated help docs. Iâve spend hours on remote user sessions to help updating PlugIns and removing previous installs.
The fact that you have to explain your client that they first need to manually remove the old installation files before they can install (and see) the most recent buttons in the included ToolBars makes the process look unprofessional. Weâve even provided (un)installers using power shell scripts which then start the PlugIn installer (rhi) once the old content have been removed. Setting all these things up for multiple PlugIns and maintaining them across multiple Rhino versions and different operating systems is already a nightmare. Thatâs why i get so nervous if rhi is just kicked in favour of something which looks even more complicated atm.
_
c.
Hi @clement,
I agree with your comments.
https://mcneel.myjetbrains.com/youtrack/issue/RH-69578
â Dale
@dale, thanks so much for writing this up !
_
c.
Hi All,
Just wanted to add my +1 for the rhi-installer-like functionality to be available via compiler for the very same reasons that Clement has mentioned (internal distributions and non-public easy to install plugin releases).
thanks,
âjarek
Another upvote here for return of RHI style functionality.
I also have a further request/question.
Right now the a drag and drop install of an .rhp file will install that plugin from the folder it was dragged in from. On FIRST install Rhino will also look at and install any matching .Rui user interface file in the same folder.
After first drag and drop install the .Rui file is then ignored/there are no user interface updates even if the .Rui file is changed.
Can/does/will the return of . RHI functionality also allow for automatic UI updates?
Right now for my plugin (windows only) I get my users to:
For updates (around once a month) Iâll send out a new .rhp to replace the current which the user needs to copy into the folder in /Program Files
Iâve not found an easy work flow to update .Rui files after first install.
My ideal for both first install and updates would be to send a .RHI or similar that would install in âwhere ever Rhino thinks is bestâ on a simple double click AND would update the user interface if any changes were made.
I do not EVER see my plugin being publicly hosted on the YAK service as it only has a tiny (~20 people world wide) market that needs close feedback to the developer.
Cheers
DK
Hi @kiteboardshaper, if you create the rhi as described in my second post and it contains a rui file with the same name as the rhp, the installer will place the contents in the PlugIn folder and once Rhino is opened, it loads the Toolbar. Updating by re-installing the rhi works for the PlugIn but often fails for the ToolBar. The reason is that the rhi installer leaves the old install and just creates a new one, in a subfolder of the PlugIn directory.
Imho, an improved installer system should allow developers to define what happens when the PlugIn is updated. Having control over the Rhino version to install to and an option to uninstall should be mandatory.
_
c.
Updating of toolbar .rui file during plugin update is already possible during OnLoad, but requires changes to be provided in plugin code in .NET language. It is not possible yet from script compiler level - but maybe as option could be added?