It might be possible to cook something up to create a new toolbar and add items to if via the SDK as long as you could figure out when you need to add this toolbar.
This would be very interesting to add, update and delete toolbarbuttons. But the only question is… How do you know which button is which one? What position will they take and will it show an icon with text, only 1 or both?
I wonder if we could still have the toolbars and buttons in an RUI file, but allow developers to show specific toolbars.
How would a customer override the developer and say “stop popping up this toolbar - I don’t want it!”
Any advance for V6 ?
An Rhi that replaces my plug-in toolbar would be good.
This article discusses how to re-stage a plug-in RUI file.
Actually, this article seems to be wrong.
If we delete the rui in %APPDATA% (either manually or programatically), and start Rhino, it recreates it, but not by copying the newer myplugin.rui which is stored with the myplugin.rhp. Instead, it extracts the toolbar data from the user’s default.rui for recreating the file.
That way, the plugin toolbar never gets updated. You need to manually remove it inside default.rui AND delete the %APPDATA% .rui file before you start Rhino in order to update the toolbar.
This is extremely cumbersome for plugin users. They just expect the toolbar to be updated with the plugin, especially if we add buttons for new functions.
If part of a custom toolbar is copied into another .rui file, such as
default.rui, it becomes part of that .rui file. Replacing the source .rui file will not change what got copied into
- A file
- Drag toolbar
MyTestToolbarinto the standard toolbar group in
- The toolbar
MyTestToolbaris still in
default.rui, as it was copied there when it was dragged into the Standard toolbar group. It must be deleted from
default.ruito make it go away.
Does this help?
This makes sense, but why is the toolbar copied to default.rui automatically by Rhino?
The .rui is installed along with the .rhp file, and they have the same name. That’s all we do. Then in the “Show Toolbar” context menu action, we activate it.
The toolbar is then always copied automatically to default.rui. If we uninstall the plugin, it stays there. And if we reinstall the plugin, a duplicate toolbar is created. At the end there are many junk toolbars in default.rui and the user has to remove them by hand. That’s a terrible user experience.
Is there something wrong we do that causes the copy to default.rui?
Toolbar provided by plug-in .rui files are not copied to
We found out the issue. At program startup, the toolbar was loaded but not shown. Then we right clicked on the tabs and did “Show or hide tabs”, then selected our toolbar at the end. This does copy the toolbar tab to default.rui
On the other hand, doing “Show Toolbar” does show the toolbar without copying it to default.rui
While there is a logic behind this, this is certainly not very intuitive. Sooner or later users will use the “Show tab” feature, and when the plugin will be upgraded they will complain that the toolbar is not updated.