Toolbar Changes in Rhino 8.3 (TestTb8)

[stevebaer]

The latest Rhino 8.3 release candidate (Dec 19) contains a test command called TestTb8. This command is in place while we adjust the user interface involved with creating and customizing toolbars.

Once you run TestTb8, the following changes take effect. The Toolbars and Containers sections of the Options dialog have been removed and replaced with a Toolbars and Size and Style sections.

Many things should feel the same as Rhino 7 with the Toolbars section, but there are also a number of subtle changes worth mentioning

Multi-select in the toolbar/group list is supported. This can be used to create a new group.

When selecting a toolbar all of the buttons for that toolbar are presented at the bottom of the page. These buttons can be clicked on to select them for editing or deletion.

There is still a lot of fine tuning that needs to be done as well as already reported bugs that need to be fixed. Please be patient while we make these adjustments.

All feedback is welcome. @Helvetosaur my hope is that this will get us closer to a usable system instead of forcing you to adjust to a “different way”.

[tay.othman (tay.0)]

I welcome this Chage, Although the Tab sizes and icon sizes are still not transferrable with the Options export/import.

[gustojunk (Gustavo Fontana)]

Glad to see this being worked on.

We are still in v7, with V8 bought and deployed on our Cloud Zoo. We just need this to be good enough so we can install and use V8. Thanks.

G

[Helvetosaur]

Hi @stevebaer ,

OK, wow, this was unexpected… I can’t test right now because my current SRC (from last week) still tells me it’s the latest version, as does the “check now” link. I’m not on the daily builds like @tay.othman. But hopefully this will help others like @gustojunk to get V8 up and running with fewer worries, and that is critically important.

@stevebaer

my hope is that this will get us closer to a usable system instead of forcing you to adjust to a “different way

Just to be clear, my main complaints were not about how the system was “different” but simply that it was too complicated and full of problems. I don’t have any trouble adapting to “different”, as long as it works.

I have now spent more than a full week adapting my interface despite the bugs, also in an effort to understand how the system actually works - which I now think I have. I had ‘fun’ making a bunch of new non-crosslinked buttons with new SVGs that I have either adapted from the old bitmaps or the new default SVG’s. All of the new buttons and toolbars reside in one .rui. So for me much of the work is already done.

My main issue is how macros and buttons are linked and what happens when they are copied within the same library or between libraries. For me that is the root of most of the other toolbar-related problems - aside from the UI aspects of toolbar/container sizing, popups etc. which is a separate issue.

• There is no way to see what macro from what library is associated with a particular button.

• A button residing in one library can contain a macro residing in a different library.

• There is no way to directly link a macro from a library to a button from within the button editor.

• The macro libraries can contain multiple copies of the same macro and there is no way to know which ones are in use or not.

• When copying a button from one place to another, there is no way to see what invisible links have been created by that action and what the consequences of it are if either the original or the copy is modified.

I don’t know if the new setup will address these issues, I hope so. As I said, I now know how to workaround most of them, much of it is already done here, although the my macro libraries are still a mess and will require some careful “weeding” to get rid of unused entries that were caused by importing a bunch of toolbars from V7 at the beginning, but also various tests made along the way.

A secondary issue is how this stuff will get saved, backed up and transferred to another installation. I haven’t tried any of that yet.

[Gijs (Gijs de Zwart)]

@Helvetosaur

My main issue is how macros and buttons are linked and what happens when they are copied within the same library or between libraries.

That one refers to RH-78592 Copied toolbar buttons are ‘cleared’ when copied from a linked toolbar
The essence of that YT is that expected behavior is copied buttons between rui files should not know of each others’ existence.

@Helvetosaur

There is no way to see what macro from what library is associated with a particular button.

I wonder if this is an issue for you because of the current ‘links’ mentioned above, or that it is important to know this for other reasons.
I don’t think there was ever a way to see this, but correct me if I am wrong. If I copy a button from a RUI file to another Toolbar in Rhino 7, that new button becomes part of the rui that toolbar is in.

@Helvetosaur

A button residing in one library can contain a macro residing in a different library.

This one I suppose also relates to the above.

@Helvetosaur

There is no way to directly link a macro from a library to a button from within the button editor.

This has never been the case in Rhino 7 afaik, pls correct me if I am wrong. But there is now in Rhino 8 a way to add a button by selecting an existing macro. Would you suggest to build this function into the button editor itself?

@Helvetosaur

The macro libraries can contain multiple copies of the same macro and there is no way to know which ones are in use or not.

I did not see multiple copies of the same macro before myself, but if you know how to reproduce that I want to log that as a bug. Afaik, multiple copies of the same macro (where the name is the same) should not be possible.

@Helvetosaur

When copying a button from one place to another, there is no way to see what invisible links have been created by that action and what the consequences of it are if either the original or the copy is modified.

I think that one also relates to the first, and should be solved by addressing the first issue.

[Helvetosaur]

@Gijs

If I copy a button from a RUI file to another Toolbar in Rhino 7, that new button becomes part of the rui that toolbar is in.

Yes, but if I am not mistaken, the button macro remains linked to the library it was copied from…

@Gijs

Afaik, multiple copies of the same macro (where the name is the same) should not be possible.

Here are a couple:
This one’s in default:

One is completely blank, the other has something in the button text field

But I have been trying to strictly limit my modifications to the custom .rui library I have. The following have the same name, but different tooltips (I have dozens of these):

Edit - I guess you might have figured it out, but these are LMB/RMB on the same button.

I also already deleted a bunch of old imported toolbars which I made new from scratch, button by button. Those probably had more macros and it looks like they maybe got removed from the macro library when the toolbar was deleted, so I have fewer now. There may be some images of those in one of my earlier posts though.

These, while actually having different names are also hard to deal with… result of copying buttons and re-using them.

I need to go in and rename them all to something I can understand.

@Gijs

@Helvetosaur

There is no way to directly link a macro from a library to a button from within the button editor.

This has never been the case in Rhino 7 afaik, pls correct me if I am wrong. But there is now in Rhino 8 a way to add a button by selecting an existing macro. Would you suggest to build this function into the button editor itself?

Yes, as one can create a new button and choose a macro during creation, but one cannot edit an existing button and link it back to a macro. Somebody just asked for that.

[stevebaer]

@Helvetosaur

Just to be clear, my main complaints were not about how the system was “different” but simply that it was too complicated and full of problems. I don’t have any trouble adapting to “different”, as long as it works.

I know; using the word “different” was an attempt to reduce my words in the initial description. The system is overly complicated and that is what we are trying to resolve. The issues that you describe are being worked on, but they are harder problems to solve than this initial set of user interface tweaks.

[Helvetosaur]

@stevebaer

but they are harder problems to solve than this initial set of user interface tweaks.

Yeah, I gather that - in any case big thanks for taking this on, I know it’s not easy or fun. Sorry that I’ve been pretty pesty about this with my posts, it’s just my way of documenting and working through the process, trying to understand how it works.

[AlW]

@Helvetosaur

I don’t have any trouble adapting to “different”, as long as it works.

I’m even more picky. Not only do I expect a change to work, but I’d like it to be a noticeable improvement large enough to seem like it was worth the development effort and my effort to adapt.
Where I used to work they used to talk about “customer surprise and delight”.

[Helvetosaur]

@Gijs

That one refers to RH-78592 Copied toolbar buttons are ‘cleared’ when copied from a linked toolbar
The essence of that YT is that expected behavior is copied buttons between rui files should not know of each others’ existence.

Here’s another one that just happened - and I have no idea why, I haven’t even closed Rhino or anything, I did open the Macros dialog to look and make screenshots, but I didn’t mess with anything in there. Now there are two buttons missing:

These were the Length and Distance buttons copied from default into a toolbar in the .rui. I then modified the button image, nothing else.

These are in the macro list from the .rui library:

But they represent old toolbar button macros imported from V7 for which the toolbar has been deleted. The images are the old bitmap images, not the new ones I put on the buttons.

In the default library I have these:

The upper ones are the original V8 .svg button images (macros), the lower ones with the red arrows are my new button images (new svg’s I created from scratch - did not use the button editor).

The copied buttons were modified by replacing the original images with the new ones - nothing else. The copied buttons reside in toolbars in the .rui, but because the original buttons were copied there from the default, replacing the image created new macros in the default library, not the .rui.

So now I have buttons who reside in toolbars that are in an .rui, but their macros are not in that .rui’s library, they are in the default library. And it isn’t working, because it is not only the images which are now missing, both buttons are now entirely blank…

Fortunately, I think these may have been the only buttons I copied and modified. Most of the rest I made new blank buttons and manually filled in everything.

So I guess the (current) rules are:

1. Do not copy buttons from one library to another.
2. If you chose to ignore rule #1, do not modify the copied buttons in any way.

Edit: made new buttons from scratch - new blank button (last choice) and then fill in text boxes and import image. Now both macros are in the library associated with the .rui as they should be.

[stevebaer]

@Helvetosaur

So I guess the rules are:

My goal is to get rid of these types of rules

[rene1]

A bit strange. Rhino tells me that version 8.2 is the latest available. So i cannot run Test Tb8. Is this because i am in europe?

Kind regards, Rene

[rene1]

Sorry. Got it. Missed the word candidate. works sort of fine now.

[clement]

Hi @stevebaer,

could you please show the full path to the linked toolbars or rui files somewhere in the dialog ? I’ve sometimes two toolbars with the same name (one which has buttons calling a script and one which is calling the compiled script as PlugIn command name) and this would make it easier to distinguish them from each other.

thanks,
c.

[stevebaer]

You should be able to currently see this if you go to File->Properties when your rui file is selected. I will try adding this information as a tooltip as well to see if that is good enough. I also would like to add some sort of UI so you can distinguish between core rhino, a plug-in, or an independent file.

[clement]

@stevebaer

You should be able to currently see this if you go to File->Properties when your rui file is selected.

Hi @stevebaer, i’ve meant before we got TestTb8 command. Without that enabIed i was eg. having two floating toolbar groups open at the same time (with the same toolbar names but different commands in the buttons) but if i go to:

Rhino Options > Appearance > ToolBars > Linked files

Only one of the two is listed there…and there was no place where i could find out in the old dialog page to which rui that entry belongs to. With TestTb8 it’s ok.

_
c.

[clement]

Hi @stevebaer,

i’ve found some linked toolbar issues in Rhino 8 which seems a bit strange. If i close a linked toolbar (rui) file from

Rhino Options > ToolBars > ToolBars and ToolBar Groups

by choosing:

File > Close MyToolBarName

and accept the dialog with OK, then close and reopen Rhino 8, that (single) ToolBar in that linked rui file is still opened and MyToolBarName is still in that list. How can i tell Rhino 8 to not load this ?

On the other hand, when i first installed Rhino 8, it somehow gathered some opened rui files from my Rhino 7 installation. If i make changes to these toolbars in Rhino 7, close it and then open Rhino 8, the linked rui files are out of date, i mean the new changes where not in.

_
c.