Installing RUI files properly for plug-ins

Rhino Developer
1

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

  1. I want to make sure each user has one and only one RUI for each plug-in.
  2. We want to update the RUI file for users to add features or fix bugs
  3. 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.
  4. 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.

2

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:

  1. Copy the RUI file to any User folder (Roaming,…)
  2. Add a tag of the plugin version in the RUI file.
  3. Load the toolbar to Rhino.

If the RUI is loaded:

  1. Check if the RUI files (User folder and Installation path) is the same.
  2. If is not the same, do the previous steps.

If you have any question, please let me know.

Thanks and best regards,

Rafael del Molino
TDM Solutions SL

3

From this:

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.

4

Hi Dale,

If I follow these instructions, and then later release a new installer with a new RUI file, does Rhino replace the existing staged version with the new one?

5

No. My testing shows that if you replace the original .RUI file, Rhino will not replace the existing staged version. @JohnM might want to chime in if he knows something different.

6

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.

7

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.

8

The same is true for Rhino, in fact. This is because if the user modifies their toolbars, we don’t want to destroy their customization just to fix a bug under one or two buttons.

That said, our changes may be much less significant than yours. Also, there’s really no good way for us to tell if the user customized the RUI, or just moved some toolbars around or docked them.

There are problems both ways, and I’m not sure what the best solution is… what do you (the third party developers that actually need this to work) think?

9

I anderstand we cant know wath the user do. For my opinion it will always show then new rui and if the same name rhi file is allready load rename the new with an indice and show it

10

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.

11

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.

Why is the tendency is to place the RUIs in roaming app data?

12

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).

1 Like
13

Thanks Dale! That makes sense.

14

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?

Luis

15

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.

16

True, the toolbar is effectively MOVED to the AppData folder where Rhino stores user plugin, but I suppose Rhino does nothing by default with the files in the /Common directory.

What is the appropriate way for my plugin to load a toolbar (C#) if in the /Common folder?

17

I haven’t tested this. But something like this should work.

const string name = @"MyToolbarFile.rui";
Rhino.UI.ToolbarFileCollection tb_collection = RhinoApp.ToolbarFiles;
Rhino.UI.ToolbarFile tb_file = tb_collection.FindByName(name, true);
if (null == tb_file)
{
  string exe = System.Reflection.Assembly.GetExecutingAssembly().Location;
  string path = System.IO.Path.GetDirectoryName(exe);
  path += "\\Common\\";
  path += name;
  if (System.IO.File.Exists(path))
    tb_collection.Open(path);
}
18

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?

19

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.

1 Like
20

@JohnM any advise for Chema?