Right click on a toolbar, then Show Toolbars, and the popup always appears at the top-left corner of the primary monitor, rather than near the toolbar / mouse position.
This is already inconvenient on a multi-monitor setup, especially when the primary monitor is large or physically farther away. What makes it much more annoying is that the popup cannot be dragged, so I have to physically move over to that corner of the other monitor just to interact with it.
I agree. I also found out that if you save a workspace (Window Layout) on a laptop with multiple Floating Toolbars without an external monitor attached, when you then later restore the workspace when Rhino is running on an external monitor, all of the Floating Toolbars will be stucked on the internal monitor on your laptop. My expectation is that the Toolbar position should be related to the monitor where Rhino is running. I have not experimented further with this on multiple monitors.
I have been testing this and have not found the same behavior. On mine the floating toolbars on the second monitor stay through Window Layout restores.
Are these layouts created with Rhino 9?
Can you run Systeminfo in Rhino and send us the results? I will see if I can recreate the same setup here.
I created the workspace on a ThinkPad P53 (1920 x 1080 px) while it was NOT connected to an external display. When I later restored it, Rhino 9 BETA (15-09-2026) was running on the same ThinkPad P53 while it was connected to an external 27" HP monitor running (2560 x 1440 px).
I have also testet this on a different external monitor running the same resolution as the internal display (1920 x 1080 px). Nothing work as expected, so I will not spend more time experimenting with this for now. Changing from “Extended Desktop” to “Only on Secondary” and back again will only add to the frustration: Rhino now running on the internal display and floating toolbars are at the external display. When loading a new Windows Layout (let’s call it Workspace) while a lot of Panels are in the RightContainer, you get a very ugly first look until you collapse and expand the RightContainer.
Consider it done. Happy to help. - NB If you use the Icon in the Options Toolbar to export options it is currently set to a nonexisting Command called “OptionsExporter” where it should be “OptionsExport”, so actually found a papercut to be fixed there
I did not mention it in this post but please note that NO titles are visible in ANY of the floating toolbars when they only have 4 columns and the Tab-size is set, so that all the icons in the Panels are legible.
The next issue we are tracking is with window layouts and multiple monitors?. I see the same window layouts you have in the menu, is there a specific window layout that should be different? What is it named? How should it lay out different?
I know there is some code internally that will collect toolbars onto one screen if the resolution does not seem exactly what it expects. But, we will see if it is something else.
We are looking into the Windows layout restore issues across multiple monitors. In my case if the layout is saved in exactly the same monitor setup it can be restored without and issue. But if anything changes, even Rhino being on the other screen, the restore can make changes.
It will take us a bit of time to figure out what is happening.
My expectations for Floating Toolbars is that they should primarily follow the application (and the position of the cursor for “pop-ups”). If Rhino is running on an external monitor the floating toolbars should be on that monitor - with the possibility to be manually moved by the user. Asus have a fantastic laptop with 1+1/2 internal monitor and Dell + Apple laptops often support 3 external monitors and could have Retina or 4K for the internal display in the laptop.
Tim
But if the problem is restoring window positions when the monitor configuration changes, either because the user intentionally switches between different physical monitors, such as home and office, or because Windows assigns inconsistent identities to the same monitors, I use a strategy that doesn’t rely on display identity or absolute position on the display.
Displays are recognized by their relative position. For example, if at recording time there are three displays, one on the right, one at the top left, and one at the bottom left, at restore time I look for the display that most closely matches that arrangement, regardless of the monitor IDs assigned by Windows or their exact position.
Window positions and sizes are also stored as percentages of the display dimensions rather than absolute pixels. That makes the restored layout work well even when the monitor resolution changes. At home, for example, I have a standard 40" 4K display 3840px wide, while the corresponding office display is 4096.
This also prevents windows from being restored partially or completely outside the visible area.
Since I started using this approach, I haven’t had complaints from users about window restoration.
There is one additional thing that bothers me about toolbar and panel positioning: resizing them by dragging their borders can be surprisingly difficult.
The draggable area seems to be only one pixel wide, so you need to be a sharpshooter to grab it.
I often need several attempts before I manage to widen or shrink panels such as Properties or Layers.
