Toolbar progress report V8.5 (Windows)

Helvetosaur · March 2, 2024, 11:21am

Just thought I’d briefly test a few of the outstanding issues today.
Tested on Windows Rhino (8.5.24058.13001, 2024-02-27) - current SRC

I created a new scheme so as to have Rhino completely default. I then typed Toolbar and created a new .rui, added two blank toolbars and saved it. In toolbar 1 I simply copied over some random buttons from default, in toolbar 2 I made a couple of new blank buttons, imported a custom .svg for each and filled out the various command areas. Both toolbars are set to display as default “Image only”, and the buttons to “Inherit appearance from tab”. Leaving the toolbars open, I then closed Rhino.

Going back to the folder where the .rui is stored, I notice that nothing has actually been saved to the .rui - it is still 1kb.

This is designed behavior that has not changed since the last time - the rui is not saved when Rhino is closed, the changes are stored in separate settings files.

Re-opened Rhino and in toolbar 2 I set one of the buttons to image + text. They then looked like this:

I then tried saving the .rui via Toolbar>File>Save… And then I closed Rhino again. The .rui file then registered as 19kb, so something got saved.

Re-opened Rhino. What’s cool is that now the images in the custom buttons in the .rui are still there. That wasn’t the case when I last tested. However, there are still some problems. Note that the button that was set to image + text before the .rui save has been reset to “Inherit appearance from tab”.

So problem #1: Button appearance settings are not saved when the .rui file is saved (and the settings for this are also deleted)

Edit: I made a bug report for this. Note also that it is not only the container (toolbar) being reset but also any individual buttons in it.
https://mcneel.myjetbrains.com/youtrack/issue/RH-80764/Saving-.rui-resets-both-toolbars-and-buttons-appearance-to-default

Next experiment - I first reset the one button to image + text. Then I clicked on the gearwheel for toolbar 2 and set the whole toolbar to image + text. What happened next surprised me. The left button - which before had no text as it inherited from the toolbar, now got some text - that is correct. However, a new “ghost” button got created, which was a copy of the button next to it - the one that did have text ! And this one, without text, is sitting on top of the text for the button to the left !!!

It’s not just an image, you can actually click that button and the command executes.

This is the left button with its tooltip:

And here is the middle “ghost” button with its tooltip:

One on top of the other… I think this has been reported previously in one form or another, obviously not been fixed. OK, close Rhino and re-open and the anomaly is now gone.

However, in setting up this post and doing screenshots in Photoshop I noticed something new. If I switched from Rhino to (already open) PS by clicking on the PS taskbar button once, then back to Rhino by clicking on the PS taskbar button again (not the Rhino taskbar icon), I got this:

The Rhino window is active, but the floating toolbars are blank. The docked toolbars are still showing. You have to click out on the desktop somewhere and back into Rhino for them to show up again, or mouse over the toolbars to get some sort of image but that doesn’t look 100% right.

OK, and last but not least, I copied the two buttons from toolbar 2 in the custom .rui into Default and I then closed the .rui. I then closed Rhino and re-opened it. Previously this would have caused the two copied buttons to be blank, their icons as well as the commands missing. However, much to my delight, the two buttons were both there and functional - the images and the command macros, tooltips, etc. had been preserved - i.e. a real independent copy had been made. This is good progress, thanks!

So, there are still some issues to be ironed out, but things are improving. Problem 1 above definitely needs to be fixed, as saving a .rui needs to preserve its integrity 100% - which it is not doing yet. A personal issue I also have with this is why the custom .rui isn’t simply saved every time Rhino is closed like in previous versions.

The rest are probably mostly display-related issues. The ghost button phenomenon described above isn’t life-threatening, but it is definitely bizarre and needs to be looked at.

I will test later on my own custom workspace - I am particularly interested to know what saving an infinitely more complex .rui will do. I now have backups in place to allow me to restore it to the previous state should things go pear-shaped. I’m virtually certain to need to do so, as the problem of toolbar appearance inheritance described above will affect more than half of the dozens of custom toolbars I have created in that rui.

skysurfer · March 2, 2024, 2:17pm

Thanks Mitch to taking time testing this features.
I’m too lazy but many clients require this!
Keep pushing!

stevebaer · March 3, 2024, 12:05am

I just pushed a fix for this to the 8.5 release candidate code. Hopefully this will work for you in the next Tuesday release candidate

I’m also trying to head in this direction and remove the need for the secondary files when the rui is a custom one that doesn’t come from core Rhino or a plug-in. This part of the project hasn’t been completed yet

gustojunk · March 3, 2024, 3:52pm

Hi Steve, This is a MUST for us. Our custom .rui files live in a Dropbox synced folder that I maintain and override with updates. All our rhino users access these .RUI files in their workspaces independently of other toolbars each has.

This current regression from V7 makes impossible AFAIK fir me to maintain and update a .rui and others see it updated the next time they launch Rhino. …unless there’s some obscure linking method that makes it still possible in V8? If that’s the case, and anyone can explain it, I’d really appreciate it.

Still waiting in V7 until all this starts being useable.

G

Helvetosaur · March 4, 2024, 7:02am

Well, the current system - including the fix Steve has promised for the next 8.5 this week - would make it semi-usable for you but still manual… that means you, as the admin of the .rui would need to specifically save any changes you might make to the rui via the Toolbar command. In principle that would update the .rui and all the people using it would get the changes. I don’t know if Rhino needs to be closed and reopened by the other users in order get the updated .rui or if it’s immediate.

There is perhaps one silver lining in this cloud for you - the fact that if any of the other users happen to make changes to toolbars that reside in the shared .rui they will not be automatically saved. That’s probably a good thing. How do you handle this now in V7? How do you prevent your users from making changes to an open shared .rui? Is it read-only?

Alan_Farkas · March 4, 2024, 7:40am

Steve Baer:
I’m also trying to head in this direction and remove the need for the secondary files when the rui is a custom one that doesn’t come from core Rhino or a plug-in. This part of the project hasn’t been completed yet

This would be great. Looking forward to it.

stevebaer · March 5, 2024, 1:18am

8.6 (which we will start shipping release candidates for next week) will have the following functionality.

RUI user defined files will save changes to themself and no longer use the extra xml files.

RUI files for plug-ins, core rhino, and from previous versions of Rhino will continue to use the xml files when saving.

gustojunk · March 8, 2024, 3:00pm

Great to hear progress is happening, I have questions about this:

Does this mean that if I have a bunch of custom toolbars in my_custom_tools.RUI, all o have to manage is where I save my my_custom_tools.RUI file?
Also, what happens when I drag a toolbar, let’s call it ‘my_viewmodes’ toolbar that lives inside my_custom_tools.RUI as a tab into the main tabs of the default Rhino workspace? Is now an instance? A copy? And Who keeps track of that, the XML file? If so, how do I make sure I back it up but also keep receiving updates of any default tools you update with a new release?

Yes, I’m super confused still.

Thanks,

G

Helvetosaur · March 8, 2024, 5:16pm

As far as I understand it, yes. Like it was in V7.

As far as I understand it the set of tabs you see in the default workspace is actually a ‘container’ containing all the other toolbars:

It lives in Default - i.e. not in an .rui. Any changes made to it are still stored in an .xml settings file. Now in principle, copying toolbar buttons from an .rui to Default or to another .rui is now supposed to make a real independent copy. But again, does simply dragging a toolbar into another container copy the whole thing? That I don’t know. Going to need to do some more tests on that.

Helvetosaur · March 9, 2024, 12:03pm

So, this is what I tried this morning:

Made a new .rui, added a toolbar and put a couple of custom buttons in it (not copies).
Saved the .rui in the wrong directory (not deliberately, but it actually helps the test).
Closed the .rui (from Toolbar dialog).
Closed Rhino.
Moved the .rui I saved to a different directory.
Opened Rhino.
Via Toolbar, opened the .rui again from the new directory.
The toolbar and buttons were still there and the buttons had all the commands plus the image
Now, dragged the toolbar into the upper row standard container to make it a tab.
Closed Rhino.
Re-opened Rhino. The tab was still there and had the buttons and they work.
Via Toolbar, closed the .rui
The tab in standard with the toolbar disappears.
Via Toolbar, opened the .rui
The tools are still there but the toolbar is no longer in the Standard container as a tab.
Dragged the toolbar back to make it a tab again in the Standard container.
Went to Window>Window Layouts and saved the window layout under a new name.
Via Toolbar, closed the .rui
Toolbar disappears from the tab as before.
Opened the .rui again
Went to Window>Window Layouts and restored the previously saved window layout.
The toolbar is back as a tab.
Closed the .rui again
Went to Window>Window Layouts and tried restoring the previously saved window layout again
Got this message:

image986×232 10.9 KB

So - conclusions:

Yes, it’s complicated, but it appears to be working…

Saving .rui’s appears to be working
Dragging a toolbar (actually a container with one toolbar) from an .rui into Default somewhere is only a link - the container still lives in the .rui - the proof is that when the .rui is closed, the container (toolbar) disappears.
Window layouts remember the container arrangement for both default and any open .rui’s. As long as the .rui is open, you can save where the toolbars in it are located. However if the .rui is closed, restoring a window layout that included one or more open containers from it will not re-open the .rui and bring the toolbar back. However, it does notice that something has changed.
Yes, it’s complicated…

gustojunk · March 9, 2024, 5:29pm

Hi @Helvetosaur, thanks so much for testing this. Yes it is a complicated workflow but it’s a complicated situation so that’s understandable.

It looks like this update doing what’s desirable, and it’s an improvent of the current limitations on V7, because this allows us to maintain a/many custom .RUI file/files and then have users use linked copies of them where then want.

A few things to still test, and I might find the time to do this, if this is in a build that I have access:

(Following my original numbering sequence):

If a linked toolbar that was dragged from a custom.RUI (now living as a tab in the main workspace) is edited, for example: a button added, an icon replaced, or a macro modified; is this change propagated to the original custom.RUI?

This is the (maybe?) desirable behaving IMO, because I will be using the linked toolbar in workspace and that link is my ‘working file’ where I evolve and change things. But maybe a right-click option at the edges/properties of a toolbar can bring up the original custom.RUI file and then easily make the change there.

3B. If the custom.RUI file is set to read-only, what happens when someone tries to make an edit ins linked toolbar from that original custom.RUI? Do they maybe the change but does not propagate to original? If so, where is this change saved? Or is the user told this is a read only toolbar and cannot be changed?

Let’s say I maintain a custom.RUI that my tema uses via instances in their workspaces linked to a read-only version of this custom.RUI. Tomorrow I go an add an exciting and new toolbar with some magic Mitch’s or Pascal’s scripts. Do they see this new toolbar next time they launch rhino? (In the way a new plugin launched with open toolbars), Or they only see added/edited buttons in their visible linked toolbars?
Let’s forget multiple users now. What happens with a single user and multiple computers? If I load a custom.RUI in computer 1 and I arrange linked instances of toolbars of that .RUI file into my working workspace, how to I propagate that arrangement to my computer 2 (still in default mode). Can I bring a copy off all my workspace arrangement from computer 1 to computer 2? I think the desirable outcome is ‘import-export’ between computers, but not live-linking/mirroring everything, because I’ll use different monitor/s setup, UI scaling, etc between computer 1 (3X 4K 27” monitors) and computer 2 ( singie 4k 15.4” screen).

I’m not sure how much of these scenarios, and other conflicting scenarios has McNeel thought about, how much they have executed, and how much was executed correctly.

This is all too important to not getting it right.

Thanks,
G

Helvetosaur · March 9, 2024, 5:51pm

So Gustavo - bit of bad news…

I decided to take my own medicine and dare to save my custom rui - which I haven’t done since January.

It’s huge with dozens of toolbars and more than a hundred buttons, a lot bigger than the small one-toolbar tests I have been making. The result - utter failure. It nuked most (but not all) of my images again. The macros are still there though.

You can see the saved .rui is decidedly smaller.

Fortunately I had backed everything up in a couple of places, so it only took me like 30 seconds to restore everything. So still not ready for prime time, and you probably want to hold off testing for awhile longer. I’ll try keep this updated.

One bug that I know that hasn’t yet been fixed is that the toolbar button appearance is reset to “Inherit appearance from tab” when you save the .rui - and mine are a lot of Text and Text+Image, so that completely ruins the .rui anyway, even if the images had been saved. The fix for that is supposed to be in 8.6 I think, will try again next Wednesday.

Karim_tabbara · March 10, 2024, 12:43am

Please ?
I lost my RUI settings but have saved my RUI file in a specific folder
How do I restore it ???

thanks

gustojunk · March 10, 2024, 1:00am

If it makes you feel any better my sources tell me that although this was supposed to be fixed in 8.5, it’s actually really going to be fixed in 8.6.

So I was under the impression that you had your hands on an 8.6 build already.

So let’s hang in there. I’m really hopeful that this time around the McNeel time has finally fixed this stuff. And there’s always 8.7 and 8.8…

Thanks for checking and enjoy your Sunday!

G

Helvetosaur · March 10, 2024, 9:15am

Yeah, except some of this stuff is supposed to already be fixed in the most recent 8.5. All the tests I made above were with that version and it successfully saved the .rui with all the images etc. So I guess there is something else going on here - one or more of the following:

The complexity of my custom .rui is too much for the system to deal with
The fact that it was originally created back at release time under 8.0/8.1 or so and thus suffers from some genetic defect that can’t be fixed
The fact that the macro library associated with the .rui is a mess, full of duplicate entries due to previous bugs plus lots of testing
Bad .rui karma
Wrong phase of the moon
Something else…

Helvetosaur · March 15, 2024, 8:24am

@gustojunk

Well, as you have seen from my post yesterday on 8.6, it looks like your ‘sources’ were overoptimistic.

Saving my custom .rui still results in the following:

Toolbar properties on all my flyouts are nuked.
Toolbar images on all my flyouts are nuked.

However - I did discover something new and perhaps important in my tests:

I observed that the two main toolbars in my custom .rui - the ones which contain the buttons that fly out all the other toolbars - were almost intact after the .rui save (one of the buttons lost its text title) . These toolbars are open when the .rui is saved, all the others, being flyouts, were closed. So after restoring my setup once again, I pulled out a few of these flyouts and left them open when I saved the .rui.

Closing and re-opening Rhino I see that the images in those flyouts that were left open are now there - they weren’t before. All the other flyouts which were closed at the time of the save are still missing their images. OTOH, even the open toolbars have lost their Image+Text or Text-only properties, and reverted to Image-only.

So the takeaways here are:

When saving a (my) .rui any toolbars (containers) that are closed lose their images
All the container properties in the .rui are reverted to Image-only (closed or open, doesn’t matter)
However if individual buttons in a container are set to a specific property instead of “Inherit from tab”, those properties are retained for those buttons.

@stevebaer - don’t know if the above info helps - fwiw.

Alan_Farkas · March 20, 2024, 3:53pm

Thank you for working on this. I thought I was alone in the madness

Could we maybe Pin this thread? I’m sure there must be a bunch of people like me who have been trying to work on this, but are much less acute than @Helvetosaur in our methodology!

Bugs aside (defaulting to inherite from toolbar) it seems like we will have to think about these Toolbars like Blocks, where we need to keep track of the Master and its Instances. Is that right?

FWIW, and again, I’m not int he same arena as Mitch, but my gut keeps telling me there’s one too many elements in the workflow Maybe it has something to do with Toolbar and ToolbarGroup? I feel like the ability to edit the Toolbar Group has been shed from v7, and now it’s been collpased into “Toolbar” without the flexibility to directly edit it somehow, even tho we still need to?

The UI that comes with creating a NewToolbar seems to be the missing link when editing Existing Toolbars. Maybe?

And then there’s this:

brian · March 26, 2024, 10:24pm

RH-80766 is fixed in Rhino 8 Service Release 6 Release Candidate

dan · April 10, 2024, 6:38pm

RH-80766 is also fixed in Rhino 8 Service Release 6…book keeping book keeping.