Previously reported R8 UI issues still present

[LewnWorx]

Various stuff I (and others) have reported that are still happening, and I’ve lost track of the initial threads where they occurred. The menu stuff is “old” (i.e. were some of my first reported issues with V8) and have had no replies or McKneel comments since, thus this post.

The container stuff may overlap other issues but is how they tend to manifest for me.

All this stuff present as of:

Rhino 8 SR3 2024-1-9 (Rhino 8, 8.3.24009.15002, Git hash:master @ 3541fa287a013b0f17849f0740f1e43a44031bfc)
License type: Commercial, build 2024-01-09
License details: Cloud Zoo

Apple macOS Version 12.6.1 (Build 21G217) (Physical RAM: 96Gb)
Mac Model Identifier: MacPro5,1
Language: en-US (MacOS default)
.NET 7.0.0

Metal GPU Family Apple 0
Metal GPU Family Common 3
Metal GPU Family Mac 2
Graphics processors
AMD Radeon RX 580 (8 GB)
LG HDR 4K - Left (3840 x 2159 @ 60.00Hz)
LG HDR 4K - Left (3840 x 2160 @ 30.00Hz)
LG HDR 4K - RIght (3584 x 2016 @ 60.00Hz)

USB devices
Generic: USB2.1 Hub
Tripp Lite : TRIPP LITE UPS
Generic: USB2.1 Hub
Generic: USB3.2 Hub
ASMT: USB 3.0 Destop HD EP0 Product string
Generic: USB3.0 Card Reader
Generic: USB3.2 Hub
Kensington: Kensington Slimblade Trackball
3Dconnexion: SpaceMouse Enterprise
Apple, Inc: Apple Keyboard
Broadcom Corp.: Bluetooth USB Host Controller

Bluetooth devices
None

Third party kernel extensions
as.vit9696.Lilu (1.6.2) 264B15BE-8923-3A33-A9F5-8F0FFBB80595
as.vit9696.WhateverGreen (1.6.3) 9599C0FC-6144-3136-854C-C15FFF63706F
com.khronokernel.FeatureUnlock (1.1.2) 46C7C044-AE43-378A-8E50-F24BA68705DA

Third party plugins
/Library/Frameworks/3DconnexionClient.framework/Versions/A/3DconnexionClient
/usr/lib/swift/libswiftAppKit.dylib
/usr/lib/swift/libswiftCore.dylib
/usr/lib/swift/libswiftCoreData.dylib
/usr/lib/swift/libswiftCoreFoundation.dylib
/usr/lib/swift/libswiftCoreGraphics.dylib
/usr/lib/swift/libswiftCoreImage.dylib
/usr/lib/swift/libswiftDarwin.dylib
/usr/lib/swift/libswiftDispatch.dylib
/usr/lib/swift/libswiftFoundation.dylib
/usr/lib/swift/libswiftIOKit.dylib
/usr/lib/swift/libswiftMetal.dylib
/usr/lib/swift/libswiftObjectiveC.dylib
/usr/lib/swift/libswiftQuartzCore.dylib
/usr/lib/swift/libswiftXPC.dylib
/usr/lib/swift/libswift_Concurrency.dylib
/usr/lib/swift/libswiftos.dylib
/usr/lib/swift/libswiftCloudKit.dylib
/usr/lib/swift/libswiftCoreLocation.dylib
/usr/lib/swift/libswiftCryptoTokenKit.dylib
/usr/lib/swift/libswiftAccelerate.dylib
/usr/lib/swift/libswiftContacts.dylib
/usr/lib/swift/libswiftCoreAudio.dylib
/usr/lib/swift/libswiftCoreML.dylib
/usr/lib/swift/libswiftCoreMedia.dylib
/usr/lib/swift/libswiftOSLog.dylib
/usr/lib/swift/libswiftVision.dylib
/usr/lib/swift/libswiftsimd.dylib
/usr/lib/swift/libswiftNetwork.dylib
/usr/lib/swift/libswiftDemangle.dylib
/usr/lib/swift/libswiftFileProvider.dylib
/usr/lib/swift/libswiftIntents.dylib
/usr/lib/swift/libswiftPrivate_BiomePubSub.dylib
/usr/lib/swift/libswiftPrivate_BiomeStreams.dylib
/usr/lib/swift/libswiftUniformTypeIdentifiers.dylib
/usr/lib/swift/libswiftAVFoundation.dylib
/usr/lib/swift/libswiftCoreMIDI.dylib
/usr/lib/log/liblog_network.dylib

Rhino plugins that do not ship with Rhino
/Users/marklewno/Library/Application Support/McNeel/Rhinoceros/packages/8.0/FilterSelection/1.0.2.0/RhSelectionFilter.rhp “FilterSelection” 0.0.0.0

Rhino plugins that ship with Rhino
/Applications/Rhino 8.app/Contents/Frameworks/RhMaterialEditor.framework “Renderer Development Kit” 8.3.24009.1002
/Applications/Rhino 8.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/Commands.rhp “Commands” 8.3.24009.15002
/Applications/Rhino 8.app/Contents/PlugIns/NamedSnapshots.rhp “Snapshots” 8.3.24009.1002
/Applications/Rhino 8.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/RDK_EtoUI.rhp “RDK_EtoUI” 8.3.24009.15002
/Applications/Rhino 8.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/MeshCommands.rhp “MeshCommands” 8.3.24009.15002
/Applications/Rhino 8.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/RhinoRenderCycles.rhp “Rhino Render” 8.3.24009.15002
/Applications/Rhino 8.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/RhinoCycles.rhp “RhinoCycles” 8.3.24009.15002
/Applications/Rhino 8.app/Contents/PlugIns/AnimationTools.rhp “AnimationTools” 8.3.24009.1002
/Applications/Rhino 8.app/Contents/PlugIns/NamedPositions.rhp “Named Position” 8.3.24009.1002
/Applications/Rhino 8.app/Contents/PlugIns/SectionTools.rhp “SectionTools” 8.3.24009.1002
/Applications/Rhino 8.app/Contents/PlugIns/RhinoRender.rhp “Legacy Rhino Render” 8.3.24009.1002
/Applications/Rhino 8.app/Contents/PlugIns/export_3MF.rhp “export_3MF” 8.3.24009.1002
/Applications/Rhino 8.app/Contents/PlugIns/RhinoBonusTools.rhp “Rhino Bonus Tools” 8.3.24009.1002
/Applications/Rhino 8.app/Contents/PlugIns/RhinoLabsTools.rhp “Rhino Labs Tools” 8.3.24009.1002
/Applications/Rhino 8.app/Contents/PlugIns/Displacement.rhp “Displacement” 8.3.24009.1002
/Applications/Rhino 8.app/Contents/PlugIns/PanelingTools.rhp “PanelingTools” 8.3.24009.1002
/Applications/Rhino 8.app/Contents/PlugIns/SolidTools.rhp “SolidTools” 8.3.24009.1002
/Applications/Rhino 8.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/RhinoDLR_Python.rhp “IronPython” 8.3.24009.15002
/Applications/Rhino 8.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/GrasshopperPlugin.rhp “Grasshopper” 8.3.24009.15002
/Applications/Rhino 8.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/RhinoCodePlugin.rhp “RhinoCodePlugin” 8.3.24009.15002

---

Menu Stuff

1 - Vanishing Menus (might be Mac only)

Menus still broken, as any defined menus vanish on quit.

While they are still define (somewhere), on relaunch they vanish until you invoke menus, add a menu (can be anything) close the dialog. When You do your previously defined menus will show back up (along with the one you just created). These will work for the remainder of the session or until Rhino Crashes, whichever comes first.

2 - Duplicated menus:

This one is erratic and hard to reproduce:

But occasionally menu names get duplicated in the menu bar (in this case “Align”)

when you check the menu editor only one exists:

General Container Stuff:

3 - Vanishing Defined Container When Locked and Docked:

I’ve got several containers defined that do NOT use any of the pre-existing container names:

This are docked in specific locations and locked.

Occasionally, and for no reasons I can reproduce (probably because I don’t see it when it’s happening, only after so thus don’t know exactly what causes it, one of more of them will “vanish”, I.E. become unchecked as far as containers is concerned, in this case “Mark’s Common Tools” from the previous screen cap.

That particular container evolves during use as it’s toolbar stuff I tend to find my self using a lot “currently” and stuff gets added and removed from this as needed based on current project workflow.

4 - Locked and Docked containers becoming NON Docked, Floating and Unusable

This one is recent (like maybe the last update). Might be Mac only.

Tends to happen mostly if I have multiple documents open on switching between the, but several of my above listed containers will undock, go floating, and outside of being able to close them are utterly non intractable. You can’t use the tools or panels in them, you can’t move them, you can’t redock them, and nothing fixes this (even a re-invocation of a previously saved Window Layout).

The ONLY way I’ve found get rid of them is to bring up the containers dialog and uncheck and recheck the container in question a couple of times to get it to “re-docK” and then repeat that process for all the rest of the “ghost orphaned floating containers”.

This one is super annoying and chews up a LOT of time. Very distracting. This also appears to have just happened recently like in the last couple of updates.

[Gijs (Gijs de Zwart)]

Thanks @LewnWorx and apologies that your earlier reports were not responded to.

@LewnWorx

1 - Vanishing Menus (might be Mac only)

Menus still broken, as any defined menus vanish on quit.

While they are still define (somewhere), on relaunch they vanish until you invoke menus, add a menu (can be anything) close the dialog. When You do your previously defined menus will show back up (along with the one you just created). These will work for the remainder of the session or until Rhino Crashes, whichever comes first.

I cannot repeat this here. Tested in 8.3.24009.15002 on a Mac running Sonoma 14.1
I made a Menu item called Align and Added a few of the align commands as well as a separator.
After doing this I closed and restarted Rhino, the menu was still there.
What am I doing differently?

@LewnWorx

2 - Duplicated menus

@LewnWorx

3 - Vanishing Defined Container When Locked and Docked:

I will keep an eye on these to see if that happens here, but so far I don’t recall this happening here.

@LewnWorx

4 - Locked and Docked containers becoming NON Docked, Floating and Unusable

This one is recent (like maybe the last update). Might be Mac only.

Yes this is a Mac only bug and is on the list as
RH-79748 Floating Containers leave traces when Rhino Window is closed.

[LewnWorx]

@Gijs

I cannot repeat this here. Tested in 8.3.24009.15002 on a Mac running Sonoma 14.1
I made a Menu item called Align and Added a few of the align commands as well as a separator.
After doing this I closed and restarted Rhino, the menu was still there.
What am I doing differently?

Wondering if you’re not seeing it is OS or platform? I’m on Monterey as my machine can’t update past that. This on a dual proc intel, not apple silicone.

Now as for the menus vanishing, I think that may have cured in last update. Need to double check as I never close Rhino unless it crashes, its always running.

The duplicated menus however are still very much there.

Much earlier on I’d ask what the difference was between the. “Mac library” and the “Rhino” library was when assigning menus.

Can you mix and match? I’m not getting rge significance of the two libraries. Obviously there for a reason or it wouldn’t exist but the why is utterly undocumented.

[LewnWorx]

Gijs:

Current Updates On These. First the sys info:

Rhino 8 SR3 2024-1-9 (Rhino 8, 8.3.24009.15002, Git hash:master @ 3541fa287a013b0f17849f0740f1e43a44031bfc)
License type: Commercial, build 2024-01-09
License details: Cloud Zoo

Apple macOS Version 12.6.1 (Build 21G217) (Physical RAM: 96Gb)
Mac Model Identifier: MacPro5,1
Language: en-US (MacOS default)
.NET 7.0.0

Metal GPU Family Apple 0
Metal GPU Family Common 3
Metal GPU Family Mac 2
Graphics processors
AMD Radeon RX 580 (8 GB)
LG HDR 4K - Left (3840 x 2160 @ 60.00Hz)
LG HDR 4K - Left (3840 x 2160 @ 60.00Hz)
LG HDR 4K - RIght (3840 x 2160 @ 60.00Hz)

USB devices
Generic: USB2.1 Hub
VIA Labs, Inc. : USB2.0 Hub
Generic: USB2.1 Hub
Generic: USB3.2 Hub
ASMT: USB 3.0 Destop HD EP0 Product string
Generic: USB3.0 Card Reader
Generic: USB3.2 Hub
Kensington: Kensington Slimblade Trackball
3Dconnexion: SpaceMouse Enterprise
Apple, Inc: Apple Keyboard
Broadcom Corp.: Bluetooth USB Host Controller

Bluetooth devices
None

Third party kernel extensions
as.vit9696.Lilu (1.6.2) 264B15BE-8923-3A33-A9F5-8F0FFBB80595
as.vit9696.WhateverGreen (1.6.3) 9599C0FC-6144-3136-854C-C15FFF63706F
com.khronokernel.FeatureUnlock (1.1.2) 46C7C044-AE43-378A-8E50-F24BA68705DA

Third party plugins
/Library/Frameworks/3DconnexionClient.framework/Versions/A/3DconnexionClient
/usr/lib/swift/libswiftAppKit.dylib
/usr/lib/swift/libswiftCore.dylib
/usr/lib/swift/libswiftCoreData.dylib
/usr/lib/swift/libswiftCoreFoundation.dylib
/usr/lib/swift/libswiftCoreGraphics.dylib
/usr/lib/swift/libswiftCoreImage.dylib
/usr/lib/swift/libswiftDarwin.dylib
/usr/lib/swift/libswiftDispatch.dylib
/usr/lib/swift/libswiftFoundation.dylib
/usr/lib/swift/libswiftIOKit.dylib
/usr/lib/swift/libswiftMetal.dylib
/usr/lib/swift/libswiftObjectiveC.dylib
/usr/lib/swift/libswiftQuartzCore.dylib
/usr/lib/swift/libswiftXPC.dylib
/usr/lib/swift/libswift_Concurrency.dylib
/usr/lib/swift/libswiftos.dylib
/usr/lib/swift/libswiftCloudKit.dylib
/usr/lib/swift/libswiftCoreLocation.dylib
/usr/lib/swift/libswiftCryptoTokenKit.dylib
/usr/lib/swift/libswiftAccelerate.dylib
/usr/lib/swift/libswiftContacts.dylib
/usr/lib/swift/libswiftCoreAudio.dylib
/usr/lib/swift/libswiftCoreML.dylib
/usr/lib/swift/libswiftCoreMedia.dylib
/usr/lib/swift/libswiftOSLog.dylib
/usr/lib/swift/libswiftVision.dylib
/usr/lib/swift/libswiftsimd.dylib
/usr/lib/swift/libswiftNetwork.dylib
/usr/lib/swift/libswiftDemangle.dylib
/usr/lib/swift/libswiftFileProvider.dylib
/usr/lib/swift/libswiftIntents.dylib
/usr/lib/swift/libswiftPrivate_BiomePubSub.dylib
/usr/lib/swift/libswiftPrivate_BiomeStreams.dylib
/usr/lib/swift/libswiftUniformTypeIdentifiers.dylib
/usr/lib/swift/libswiftAVFoundation.dylib
/usr/lib/swift/libswiftCoreMIDI.dylib
/usr/lib/log/liblog_network.dylib

Rhino plugins that do not ship with Rhino

Rhino plugins that ship with Rhino
/Applications/Rhino 8.app/Contents/Frameworks/RhMaterialEditor.framework “Renderer Development Kit” 8.3.24009.1002
/Applications/Rhino 8.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/Commands.rhp “Commands” 8.3.24009.15002
/Applications/Rhino 8.app/Contents/PlugIns/NamedSnapshots.rhp “Snapshots” 8.3.24009.1002
/Applications/Rhino 8.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/RDK_EtoUI.rhp “RDK_EtoUI” 8.3.24009.15002
/Applications/Rhino 8.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/MeshCommands.rhp “MeshCommands” 8.3.24009.15002
/Applications/Rhino 8.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/RhinoRenderCycles.rhp “Rhino Render” 8.3.24009.15002
/Applications/Rhino 8.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/RhinoCycles.rhp “RhinoCycles” 8.3.24009.15002
/Applications/Rhino 8.app/Contents/PlugIns/AnimationTools.rhp “AnimationTools” 8.3.24009.1002
/Applications/Rhino 8.app/Contents/PlugIns/SectionTools.rhp “SectionTools” 8.3.24009.1002
/Applications/Rhino 8.app/Contents/PlugIns/RhinoRender.rhp “Legacy Rhino Render” 8.3.24009.1002
/Applications/Rhino 8.app/Contents/PlugIns/Displacement.rhp “Displacement” 8.3.24009.1002
/Applications/Rhino 8.app/Contents/PlugIns/PanelingTools.rhp “PanelingTools” 8.3.24009.1002
/Applications/Rhino 8.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/RhinoDLR_Python.rhp “IronPython” 8.3.24009.15002
/Applications/Rhino 8.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/GrasshopperPlugin.rhp “Grasshopper” 8.3.24009.15002
/Applications/Rhino 8.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/RhinoCodePlugin.rhp “RhinoCodePlugin” 8.3.24009.15002

And on to the list::

1 - Vanishing Menus (might be Mac only). - Appears to be fixed

2 - Duplicated menus

Stlll alive and raging, and furthermore can no longer be deleted (you used to be able to make the dup go away, until sometime after the next launch and manual re-involke via add one to the menu as an edit, close that, reopen the menus to delete the one just added in order to have menus work for that “session” until the next quit or crash. At least then when the dups showed up you could invoke menus and delete it. No longer.

At least when this first popped up on the first V8 release you could go into the editor and delete the cloned copy of the menu. No longer as both aren’t visible in the editor.

Where do these things live anyway? Is this some XML or JSON file we can go look at?
A tutorial or doc on where these various prefs live and which one modifies what would be really good to have, as since R8 changed everything most of us Mac users have no clue where any of these new stuff lives, what and what they do.

For example:

Containers has an import button, but there’s no export button.

When they are imported or created manually, where do they live?

Containers has this:

But Toolbars has this:

It’s these kinds of differences with all the other ui changes that makes trying to get your head around V8 particularly bewildering, as there’s just a mess of inconsistencies, and almost NONE of them have any documentation as to what they even do, at least not anything you can find in the help panel, which also has areas where the current help is out of date (R7 stuff) and as a result of the on-screen stuff in help not matching, the issue becomes even more incomprehensible.

And like menus, containers also has this:

But again, we don’t know what the difference is, and if (for example) it’s “Legal” to use a defaultmac library thingy in a otherwise “defualt” set of settings. Dunno. maybe my menu issues are screwed because I mixed them?

However because I can’t nuke the “duplicate” menus, (they don’t show up in the editor) and I don’t know where this stuff lives on disc, my odds of troubleshooting what’s happening and why are markedly decreased.

3 - Vanishing Defined Container When Locked and Docked:

This one I was finally able to cure only by deleting every “custom” container I had, quitting, re-opening and manually rebuilding all my containers. That managed to fix that, except for when

4 - Locked and Docked containers becoming NON Docked, Floating and Unusable

Shows up, but at least now you have that one as a known bug item.

So there’s that but wait, there’s more:

More Inconsistencies

In Options, toolbars gets it’s own panel & icon:

, and furthermore part of it shows up there, and more of it shows up here:

And as a result it’s not clear what takes precedence and where you go to do what.

However, Containers does not get it’s own panel, it’s only under this tab under appearance:

and was also obliquely referenced in the workspaces, and speaking of which:

Worksession has vanished from the UI

(I have a menu command for it but it no longer fires and brings up the workspace UI (and I have no clue how I got to it before putting the menu in)

And this is just a hoot. Worksession exists only here in help but doesn’t even warrant a mention outside of being part to the topic.

Issuing work session USED (early R8) to bring up a dialog where you could save and restore your various UI bits.

Now, however it doesn’t appear to exist:

And when issued from the menu item it was originally under instead of brining up the aforementioned dialog it now gives:

So I have no idea where that went. I had been using it to attempt to fix the magical unlocking of my docked and locked containers (which sometimes worked), but now that component of the UI appears to have gone totally missing or has moved.

In the ONE and only place I’ve been able to find that (which is buried in bowels of another UI pref panel) while it shows up, even there:

It does nothing:

So that’s broke as well.

Now back to:

Toolbars

If I do hit help for the toolbars panel in settings, I get the following:

What’s an RUI file? it’s not in help. What’s a linked RUI file? NO idea. Not covered in help. There’s some very cryptic discussion of them there but it’s written like everybody is intimately familiar with them and (and a least on the Mac side) prior to R8 nobody had ever seen one before.

This isn’t hard, just a little topical diagram of what stuff lives where, would go a VERY long way to knowing what the impacts are to changing things.

For most Mac apps one can figure this stuff out by inspection, as it’s only going to be in one of two places. (/user/library/preferences or /user/library/application support of possbily /boot drive/system/application support, and whichever one it is ALL the stuff will be there, not scattered all over the place where this part does that and lives here and that part does this and lives there, and some other part you don’t even know exists lives in yet another place.

Which I have no idea where t here these “libraries” live, what they do, why there are two of them, and what differences it makes if I put in a command on a tool bar from the defaultmac from the default.

So yeah, I know you guys are getting hammered on this all over the place but you kind of have to see it from our end (i.e. the users, particularly long time Mac users). I (maybe we) get that you want to unify the UI across the platforms to save development time, support time, make training easier etc. I get that. I did application development and was the software product manager over several different apps and we didn’t even HAVE Mac versions and I get what a headache it is to try to keep a roadmap on track.

That being said, when you’ve only used one flavor (i.e. the Mac one) of an app for a very long time and the UI changes, that impacts the UX. And I think most of us just want to be able to get our stuff done. I’m not particularly beholden to a particular UI Metaphor for doing things, as long is there IS a means of doing it and that I understand how it works and where it lives, and hopefully that it doesn’t require and inordinate amount of pointing and clicking to do.

Now I know this forum is chock full of PO’d posts about all this, and while I get it, I also VERY much appreciate how reachable you guys are, and that you interact with the user base. As one who’s had years of fighting Autocad’s myriads of gawdawful bugs (some of which have been there literally for decades) and even worse UX, when that’s coupled with an absolute inability to even get someone there to acknowledge let alone provide any assistance or workaround, that’s a place you don’t wanna be as a user.

And as rough as this transition is, even with the “wierdness” of the UI, it pales in comparison to Fusion (which I also almost use daily, simply because I need the parametric stuff for certain types of things), as even the most common types of things anybody would take for granted having used any other CAD regardless of platform can just be mind numbingly impossible to achieve. Like really trivial things, copying, moving, rotating are just an exercise in "WTAF were you thinking"d. So take the heavy whinges with a grain of salt, those folks need to spend some time in either AC or Fusion to get a feel for how well Rhino actually does what it does.

And for the most part (at least now after a few updates) I’m pretty comfortable using R8 for daily production work, so you’re getting there.

[Gijs (Gijs de Zwart)]

@LewnWorx

Much earlier on I’d ask what the difference was between the. “Mac library” and the “Rhino” library was when assigning menus.

I don’t have an exact answer to that question, but seeing that defaultmac is an empty library on my system, I’d say that it’s best to ignore it until I have a better answer.
@LewnWorx I’ve added RH-80302 confusing Default and Defaultmac

I’ll try to address your other post bit by bit, thanks

[LewnWorx]

Greatly appreciated.

it shows up in a few places (and they aren’t ALL empty) so it must serve some kinna purpose, I just have no clue what that is.

[Helvetosaur]

@LewnWorx
Maybe I can answer some of this stuff… To start with, although there are certainly a number of Mac-only issues right now, there are a number of others - notably toolbars etc. - that are on both platforms.

2 - Duplicated menus - Don’t know about this, never messed with menus, only toolbars - but

@LewnWorx

Where do these things live anyway? Is this some XML or JSON file we can go look at?
A tutorial or doc on where these various prefs live and which one modifies what would be really good to have, as since R8 changed everything most of us Mac users have no clue where any of these new stuff lives, what and what they do.

I don’t know where this stuff is stored on Mac, but on Windows, the system has also changed and much of this stuff is stored in .xml settings files. I know where they live in Windows, but it isn’t really all that helpful, as reading that xml isn’t all that easy and I would be leery of modifying them. In Windows they are here:

C:\Users\username\AppData\Roaming\McNeel\Rhinoceros\8.0\settings

On Mac, I guess it might be in your user library somewhere… There are a bunch of them, one main settings file and others to manage containers, workspaces, the default library and any other .rui library you might have created or used.

The Mac Rhino Help appears to be structured a bit differently than the Windows one, but there are some sections on Toolbars and Containers in the V8 Mac help. I am hoping to write a Wiki page on this stuff once it stabilizes a bit more.

I don’t really know what this is all about either, it is still there in the latest Mac version. It does not show up in Windows Rhino.

@LewnWorx

3 - Vanishing Defined Container When Locked and Docked:

This one I was finally able to cure only by deleting every “custom” container I had, quitting, re-opening and manually rebuilding all my containers. That managed to fix that, except for when

I had different problems with the Windows toolbars/containers, but some of them needed to be solved the same way - just rebuilding starting from scratch.

@LewnWorx

In Options, toolbars gets it’s own panel & icon:
…and furthermore part of it shows up there, and more of it shows up here:

Yes, that is the case in Windows Rhino as well. Options>Toolbars has two sections - one section with a list of all the toolbars in the various libraries which is used for showing/hiding/opening/saving etc., the second section with all the “sizes and styles” options. Under the Window menu, there is the Toolbars popup window that is basically the same as the first section in Options>Toolbars. They do the same thing.

@LewnWorx

Worksession has vanished from the UI

I think maybe you are confused here. Worksessions does not have anything to do with the UI - it is a system for attaching reference files while working on big/collaborative projects. I’m not sure it has been implemented on Mac yet - so it didn’t disappear, it was never there.

You are probably thinking about Workspaces, not Worksessions. Actually this is now under “Window Layouts”. It’s what allows you (theoretically) to save, recall and manage different toolbar arrangements for different tasks.

@LewnWorx

What’s an RUI file? it’s not in help. What’s a linked RUI file? NO idea. Not covered in help. There’s some very cryptic discussion of them there but it’s written like everybody is intimately familiar with them and (and a least on the Mac side) prior to R8 nobody had ever seen one before.

Yes, for a Mac Rhino person this will be completely new. And for a Windows Rhino person, the concept of a .rui has also completely changed. In Windows Rhino V7 and earlier, the .rui file was just a set of toolbars. There was the default.rui supplied as the basic set as well as any number of custom ones you could create or import. You could modify the default set and also save it under another name. It was possible to have several open at once, they were all managed in the Toolbar section. The equivalent did not exist on Mac.

In V8, the default.rui - which is what you had in V7 when you opened a just-installed, unmodified Rhino - was removed from the Windows side. The default set of toolbars is now integrated into Rhino itself on both platforms and cannot be closed or deleted - it can be modified though. An entire toolbar set is now called a ‘library’. Any modifications to the default library are not stored in the library itself, but rather in one of the settings files mentioned above. Modifications to other .rui libraries are also stored outside the .rui itself in yet another settings file. This makes management of libraries somewhat complicated (to say the least).

In V8, .rui files still exist, although their form has changed somewhat since V7. You can open .rui files in V8 - either those that were made in Windows V7 and imported, or new ones you create in V8. The .rui files are basically secondary toolbar libraries, independent of default. There are a number of outstanding bugs surrounding the saving of modifications and the management of having more than one open library, far too long to go into here. There have been at least 30-40 posts by me on the subject over the last several months.

I haven’t yet tried to see if importing an .rui file made in Windows Rhino into Mac Rhino actually works. I am still waiting for more bugs to be fixed, I think some major improvements are coming for 8.5.

I can certainly see how the change in how the UI is structured would destabilize someone on the Mac side, having never experienced the previous Windows system. Even experienced users like me are destabilized just on the Windows side in that respect.

The thing is, in order to bring the two systems closer together and also work with a common GUI element system (ETO) they basically had to re-write everything from scratch on both platforms. I think this task ended up being far more complex than they had imagined; plus there were some newly-introduced concepts that were not thought out well enough.

It IS an incredibly complex system - basically you are allowed to modify the toolbars in any way you want - and that means there are bazillions of possible configurations that people will try that have never been tested. I imagine we’re going to continue to discover bugs for awhile yet, and they will slowly get squashed. It will take patience.

[Gijs (Gijs de Zwart)]

@LewnWorx

Worksession has vanished from the UI

as mentioned by @Helvetosaur Worksessions is a tool to split up large projects. This is not yet available on Mac.

[LewnWorx]

@Helvetosaur

I think maybe you are confused here. Worksessions does not have anything to do with the UI - it is a system for attaching reference files while working on big/collaborative projects. I’m not sure it has been implemented on Mac yet - so it didn’t disappear, it was never there.

You are probably thinking about Workspaces, not Worksessions. Actually this is now under “Window Layouts”. It’s what allows you (theoretically) to save, recall and manage different toolbar arrangements for different tasks.

First, pardon my covid brain fog.

Right workspaces (although the work sessions tool is IN there, it just doesn’t do anything which is how I got confused, which these days doesn’t take al lot).

That does explain why my menu for it doesn’t work as it got renamed at some point.

[LewnWorx]

@Gijs

@LewnWorx

2 - Duplicated menus

Stlll alive and raging, and furthermore can no longer be deleted (you used to be able to make the dup go away, until sometime after the next launch and manual re-involke via add one to the menu as an edit, close that, reopen the menus to delete the one just added in order to have menus work for that “session” until the next quit or crash. At least then when the dups showed up you could invoke menus and delete it. No longer.

A little update on that one…

I got brave and tried to delete the one of the two that showed up in the menu editor, thinking that might lose the 2nd instance of the menu.

Well it did, however the drawback is that the other one that remains? Can’t be edited, or deleted. Likewise with the “settings” menu I’d also added, that one is inaccessible as well.

(the 2nd align is gone but the one remaining isn’t in menu editor)

I’d be totally ok with nuking them all and rebuilding them like I did with containers, but I don’t know where they live to do so. I’d rather not do a full on factory reset as there’s myriads of little settings I’ve tweezed and I’d rather not have to spend the mess of time required it’d take to remember them all and rebuild them from scratch.

So if there’s a fairly easy way just to nuke the user created menus, I’m all on board with that.

And thanks for diving on the myriads of hand grenades here. Greatly appreciated.

[Gijs (Gijs de Zwart)]

hi @LewnWorx can you rung _Reset, and without resetting anything, click the save settings for support button and send the resulting zip to me?

[LewnWorx]

Took me a minute as rung_Reset didn’t work nor run g_reset. had to walk the iterations to just “_reset”

LewnWorx_RhinoSettingsForSupport.zip (86.3 KB)

[LewnWorx]

@Gijs

So right before getting that post and after screen shotting the section IN appearances on the linked RUI files, it dawned on me that my “frequently used tools” container had been empty for a few days (didn’t notice when that happened).

I had however previously exported its’ toolbar contents to a RUI file. I went back to appearances and linked that externally saved one.

Then I went back to the container, and hit the toolbars option in its’ settings (or gear icon, or whatever you call that dropdown menu) and when toolbars came up I could see the linked RUI file I’d just previously opened, and when I selected that, it loaded up the container with stuff stuff I’d previously put in it.

Neat.

Then I got your _reset post, ran that to get you the zip file and after doing so thought “oh there’s a reset menus only” option, and figuring if that worked I could just rebuild the menus I’d cooked and put that whole issue to bed.

So I ran it again, did the toolbar delete, closed as directed and reopened, and yup the errant inaccessible menus (and the accessible ones) were gone.

Ok fine.

But THEN I noticed the frequenlty used commands container was again empty.

Went back to the toolbar settings under appearances (not the standalone panel) and saw my opened linked RUI was gone from the list and it was again empty.

Figuring the toolbar reset probably caused that I hit the menu and reopened the externally saved RUI file figuring I’d just go back to the container and re-add it like I’d just done 10 minutes prior.

Despite my external RUI showing as being opened in appearances, this time when I went to the “frequently used commands” container and hit the toolbar menu item, the dropdown that previously had both the default and my opened linked RUI now just has the defaults, so despite the external file being shown as actively linked, the container Toolbar menu no longer sees it.

Now having done a fair bit of development over the years I’m gonna file that one in the “wierd shit compounded by differing bugs in different versions that collectively make this a difficult bird to chase”. I may just need to nuke the container, unlink the RUI, rebuild the container and manually re-add the tools.

What I’m not sure is if it makes sense to re-export that container?

My original notion for doing so (back on Jan 24th when this was created) was to have some kind of mechanism to start keeping these configuration & settings things to try to save having to redo all this sorta stuff if for some reason the install craters completely, the mac rolls over and dies or whatever.

Not sure what exactly is the best approach for that, and maybe due to this stuff all being in flux it may be best to let you guys get this stuff a bit more settled and then find out what the best practices for that will look like.

Just figured it was worth a heads up.

[Helvetosaur]

I don’t know how it works exactly on Mac - haven’t tried yet - but there are still some serious bugs with saving (and I assume exporting) .rui files. Don’t know about containers.

What was happening (may still be happening) is that just saving an .rui file would destroy it. Because…

…the modifications made to an open .rui file are not automatically saved in that .rui file. They are saved in a separate .xml settings file linked to that .rui, and only that file is automatically updated when you close Rhino (I think).

The .rui file itself is not re-saved over unless you do that “manually”. The act of manually saving an .rui is supposed to integrate all the changes stored in the related settings file into the .rui and then reset the settings file. That part is totally broken - at least it was the last time I tried. The result of saving the .rui file was to nuke virtually all the toolbar button images in the .rui as well as some of the commands. Plus it also killed the settings file that contained the changes. The result is the next time you opened Rhino all the toolbars in the .rui were trashed.

In theory replacing the newly-trashed files with a backup of the .rui and its related settings file before it was saved should work to restore the workspace - it did once for me.

So - my current custom .rui file is still dated 10 January. I have a settings file related to that .rui that is dated today - the last time I closed Rhino. Those two together work correctly. I am not going to attempt another .rui save for awhile yet, maybe when the first 8.5 comes out, and then only after having copied the previous files first to somewhere else.

[Gijs (Gijs de Zwart)]

Yes there are bugs right now in the system that are high on the list to get solved. One of them is RUI files saving. I’m an advocate of bringing back how this worked in Rhino 7, for at least the external RUI files:
So the last opened (as in: the last that is still opened and being closed) Rhino session will save any changes you make to a RUI file. Right now you can save changes to a RUI file explicitly, but the system is not water tight.

@LewnWorx I’m going to have a look at the file you sent, thanks!

[Gijs (Gijs de Zwart)]

I am seeing this, after opening Menus, going into defaultmac and deleting the Align menu:

So I think that the double menu is not really a bug.
I would just add menus to default and ignore the existence of defaultmac.

[KelvinC (Kelvin Cheng)]

@Gijs

@LewnWorx

Worksession has vanished from the UI

as mentioned by @Helvetosaur Worksessions is a tool to split up large projects. This is not yet available on Mac.

The Worksession toolbar should not be on Mac until it is implemented.
RH-80414 Toolbar: Remove Worksession toolbar from Mac