I received a question from @rafaeldelmolino regarding the best practices for distributing RUI (Rhino User Interface) files with plug-ins. Rafa’s questions were:

I want to make sure each user has one and only one RUI for each plug-in.

We want to update the RUI file for users to add features or fix bugs

Where we need to copy the rui file (installer) to achieve this? The installation directory of the plug-in is not writable directory because it is under program files, so users cannot modify or dock RUIs saved there.

Who loads the toolbar? Rhino or the plugin? How does this work?

I’m hoping that @stevebaer, @brian, and @JohnM, as well as the Rhino Developer community can participate in this discussion.

Hi Brian,
Thanks for open the discussion.
Probably the easiest way for the developer is just copy the RUI file in the same folder as the .rhp, and Rhino is who take care about loading and version control of the RUI file. Possible workflow.

When Rhino loads the Plugin:

If the RUI is not loaded:

Copy the RUI file to any User folder (Roaming,…)

Add a tag of the plugin version in the RUI file.

Load the toolbar to Rhino.

If the RUI is loaded:

Check if the RUI files (User folder and Installation path) is the same.

Hi, I am packaging my plugins using my own MSI installer. I am following the http://wiki.mcneel.com/developer/installingandregisteringaplugin guide. I would also like to register a custom toolbar. Which registry should I edit so that the toolbar...

If you give the RUI file the exact same name as the plug-in RHP file and install it in the folder containing the RHP file (or its parent folder) Rhino will automatically stage it in a writable location and open it at startup.

That was our experience as well. We worked around it by having our .msi, on uninstall, remove not only the original toolbar but the staged version as well, which it found by digging the file location out of the registry. We haven’t been able to figure out a solution to the problem of a user moving the toolbar once installed, though - in that case it becomes apparently completely disconnected from our plugin.

Hi,
I confirm the trouble, each time i send a new release with an Rhi, the new toolbar is not loading on all computer. Some user mus reload it. I put the Rui and the Rhp files in the same directory and they have the same name.
A wish : It woulb be nice if The Rhinoinstaller would detect a previous version and propose to remove it.

I sympathize with you guys; the cause of the problem became clear pretty soon after I discovered it. What about this: the ability to “lock” RUI files so that their contained toolbars can be moved and redocked but not altered? If this were possible, Rhino could keep track of the toolbars individually rather than just throwing their contents all into a big “UI” blob that becomes impossible to untangle when a plugin is updated or uninstalled. The “lock” doesn’t even need to be permanent, just difficult enough to undo so that users know that if they do so, they risk plugin updates not working correctly.

It seems that many of the installers send the RUI files to C:\Users%userprofile%\AppData\Roaming\McNeel\Rhinoceros\5.0\Plug-ins\ where each plug-in has its own folder with a serial string.

I don’t like to store things in C:\Users if they can function properly in C:\Program Files so I’ve been moving my RUI files to C:\Program Files\Rhinoceros 5 (64-bit)\Plug-ins\Toolbars. So far this has been working out fine.

1,) If you are on a network that implements roaming profiles, the RUI will follow you.

2.) This folder (…\AppData\Roaming) is one where files can be read from and written to. Applications don’t normally have rights to write to any files in a folder that exists in Program Files (due to user rights and UAC).

Hello All,
It has been my experience that placing .rui files in the /Common folder of an rhi does not lead to that toolbar being installed. If I put it in the folder with the rhp it does register the toolbar (if I have it in /x64 with the rhp for example). According to http://wiki.mcneel.com/developer/rhinoinstallerengine/authoring I should be able to place the rui in the /Common folder. Is there anything I need to do from the plugin to register resources in the /Common folder?

I believe the document says an rui, added to a Common folder, will be installed. I don’t believe it says anything about being registered (sorry for splitting hairs…).

If your know your rui file is in a Common folder just below the folder where your plug-in is installed, then your plug-in can load the rui file itself. If this is more work than you want to do, then just make sure the rui is in the same folder as your plug-in.

This might work, but still: how are you going to know that you have a newer toolbar to install later? How do you know the user didn’t extensively modify your previous toolbar, and to overwrite it with the new one would cause lots of frustration?

My wish would be to have a way to programmatically create/destroy a toolbar from the SDK, just like one can do with a menu (i.e., InsertPlugInMenuToRhinoMenu).

At least in my case in particular, this would allow me to control what buttons our users see, and make sure that when a new version is released with new features, the new buttons (if any) are displayed.