Continuing the discussion from Update toolbars in all rhino instances:
⌠this is the equivalent off selling a pickup-truck where the instruments are all messed up in chaos
⌠and advertised as 4x4 but had no Differential
this would be this case Is the subsurface UV mapping problem being addressed?
⌠and the vanâs roof top was desintegratingâŚ
This oneâs was last answered by Steve in 2014: âI will try to, Need to engineer some time first.â
Iâm loosing 20% of the time just with the toolbar chaos and latency regarding moving large drawings due to snap, ortho and other ârather long lagsââŚ
âŚwonder how would it be like in Russia. With all that degrading infrastructure⌠and that Russian Geometric Kernel - Wikipedia
It looks horrible!!! isicad :: Russian 3D-kernel RGK: Functionality, Advantages, and Integration
WellâŚthe thing with rants is that theyâre funny even if Iâm completely wrong and have the answer right in front of my round red nose 
âŚmeanwhile Iâm wondering if I should kill a rhino instance that irrenponsivelly whitish for quite a whileâŚ
Just for moving a tiny topological mesh
If you are going to rant, please do it all in one post instead of sevenâŚ
This post is an overviewâŚ
Feel free to respond in the original linked posts 
PS: I vote youâre allowed to curse by the way 
If youâve been following the forum, you might have noticed many posts where it has been mentioned that the the toolbar system is going to be completely revamped for V8. Until that system is actually up, working and testable in the WIP, itâs difficult to know which bugs have been addressed and which havenâtâŚ
This post still does not contain enough details or an example of what you are trying to achieve (despite the fact that they were asked for).
Probably. If you can reproduce the problem consistently, create a bug report and post it here or send it in to tech.
1 Like
This is just the general slowness with large scenes where âsnapsâ and even âorthoâ becomes irresponsible. Youâll have to wait a while until âTabkeyâ getâs an orthogonal lock.
In this case my new but âon boardâ GPU might have part of the guilt butâŚnot all for sure
Maybe that post got a little convoluted but puting it simply⌠how to project (meaning positioning in this case) a selection of block instances to a surface âŚand and of course have the choice to orient not only by surface normal but world.
A useful use case would be to project vertically Trees on a terrain surface.
By the way:
Is there a block insertion Snap?
Is there a way to reset block instance transforms?
When using the Gizmo, is there a choice to transform object (namelly block instances) relative to itâs local coordinates?
If I have 3 or 4 rhino instances and want to change something in the âtoolbar layoutâ how should I go on saving that? If I save changes in my own toolbar file how can I reload that in the other rhino instances?
Thereâs no ârefreshâ in Options->Toolbars, I can only close and open it again⌠and lose some positional parameters.
Is there a way to refresh toolbars that Iâm missing?
Also, Iâm not sure but⌠does Rhino automatically update toolbar files? When? can it overwrite my explicit toolbar file update?
Yes, thatâs the way it works currently. You can save the .rui file in one instance and then close (without saving ) and re-open in the others, but thatâs painful. There is currently no mechanism to do this differently - I have no idea if the V8 version will be changed in this regard.
Other settings update between open instances immediately, but the toolbar layout is a complex combination of two different files - the toolbar file itself plus the individual positions. Lets say you have two instances of Rhino open on a setup with two screens - one of the screens has Rhino maximized and the other doesnât. Now you add or modify a toolbar in one instance. Rhino doesnât necessarily know where to put the toolbar in the other instance - it needs to âguessâ. I donât know how this stuff gets solved.
That used to be the case for the default.rui at one time, but AFAIK it does not get overwritten anymore. Custom workspaces (saved under another name) never get overwritten during SR updates.
If I understood correctly, the whole concept of default.rui will be going away for V8.
Currently, here in V8, with the system not yet public, the latest instance to close determines what the toolbars will look like on the next one to open - this is the same as V7.
How should it work, if different from that?
However, updates to toolbars from McNeel will be reflected in the next builds automatically, there will be no need to update âmanuallyâ.
-Pascal
I think he wants to work like settings do currently, i.e. as soon as a change is made in one open instance, all the other open instances update immediately.
Ah, yeah - on Windows that is less straighforward, and may come, but on Mac that should happen automatically with the new system, currently at least.
-Pascal
Any updates on this?
How to import blocks from file - Rhino Developer - McNeel Forum
Any resemblance of a type of âLibrariesâ thatâs more than a simple âfile explorerâ??
On what?
Youâve linked to a few developer questions - which appear to have been answered.
What is the problem that you are trying to solve?
â Dale