Hi Pascal, I downloaded the latest Rhino 8 WIP from today and it got even worse, because the left sidebar disappeared after the update. I had to move my 3 custom toolbars on their usual place, because upon every opening of the program they are located in a wrong position. Here is a screen-shot of the Toolbars page as you requested:
On a side note, I use a 4K screen with 200% scaling from the Windows 10 settings, so I wonder if this could create some mess to the toolbar arrangement in Rhino 8 WIP? Older versions of Rhino 8 WIP didn’t had that issue, nor my Rhino 7 which works perfectly fine with the toolbars.
The rui file is a copy of the rui I use on my Rhino 7, only in a separate folder dedicated to Rhino 8, and has the latest customizations I made in Rhino 7 before importing it into Rhino 8 WIP, despite the name that suggests it’s 8 months old file.
Hi Bobi - the screen is exactly what should be properly accommodated now… I don’t think that is the problem - my guess is there have been changes that make your linked file no longer behave. @JohnM - how should we investigate this one?
And, please, remove those unnecessary dark gray borders around the icons, because they make the UI look overly-complicated and more difficult to read the icons. Why don’t keep the proven clean look of Rhino 7?
Rhino 7 in comparison. Note that its icons are slightly blurry due to the fact that they were designed years ago for low-res monitors, whereas I use a 43" 4K screen with 200% scaling, so they are basically meant for use with a 1080p resolution. I definitely prefer their thin border with perfectly balanced blue over the thick border of the Rhino 8 WIP’s icons. Since the icons in Rhino 8 are going to be based on vector graphics, why don’t let the user choose the thickness of the black border? Should be possible.
Some SubD icons use extremely dark blue shade that’s difficult to the eyes (SubD Truncated cone, SubD MultiPipe etc).
Also, not sure why some icons are named “Toolbar item ##”, since they must have a specific text. Here is how the GH icon appears as “Toolbar item 00”:
hi @Pascal, besides all the very good feedback from Bobi, I wanted to point out something else. I know this is all preliminary, but up t oV7 the amount of frames, outlines and padding around icons was already problematic, and my hope is that with a re-write things would get better, but so far they are worse, using a lot of extra pixels.
Here please see from the upper corner of the screen, how many pixels it takes until you see actual workarea (viewports or canvas), compared to Photoshop (it’s similar with a lot of other creation software):
I will add another clear disadvantage of Rhino 8 WIP’s UI. I consider it a bug, because it behaves in a highly unwanted fashion. It’s an addition to point number 4 from my original post:
4b. Right-clicking on a blank space of a toolbar to “Add or remove toolbars” will add HIDDEN tabs to the vertical docked toolbars, ultimately forcing the user to unlock the original docked tab, move it towards the viewport and eventually be able to see the hidden new tab consisting another toolbar. Then, the user is forced to detach the tab to separate the newly shown toolbar, and then move the original toolbar to its old place and adjust its shape, because 99% of the time it gets lost.
In Rhino 7, this whole struggle is non-existent, because a right-click on a blank space of any toolbar lets the user hover over the “Show toolbar” pop-up window and then show (or hide) any toolbar from the vertical list. Once that’s done, the newly shown toolbar (or multiple toolbars) appears as a floating window inside the viewport, giving the user a convenient way to choose from 4 options:
Keep the floating window and use it that way, or move it around the viewport, with the ability to quickly close it when it’s no longer needed;
Drag the floating window and add it as a tab to an existing floating toolbar;
Drag the floating window and add it as a tab to an existing docked toolbar;
Drag the floating window and make it a docked toolbar next to an existing docked toolbar.
I suggest to learn from the great UI of Rhino 7 and keep the things simple, user-friendly and with toolbars taking as fewer pixels as possible.
Bug number 12: Just opened Rhino 8 WIP again, first time since I reported all the bugs and downgrades yesterday in this topic, and there are a whole lot of problems that appear for no reason.
First off, nearly all icons lost their RMB command. Then, every toolbar except for the left one lost their tiny triangle at the bottom right corner that opens the linked toolbars. All the custom macros I had in numerous icons also got lost. That’s on top of the bug with the toolbar arrangement which loses its state upon every start of the program.
Also, the issue with the bad rendering of the edges of polysurfaces reported in this topis is till not resolved in the latest Rhino 8 WIP, despite the claim that this particular bug has been finally fixed. Rhino 7 renders those much better.
Check the last one named RH-66088. Still not fixed:
Shot in the dark with out reading alot about WIP trouble:
Have you tried running Rhino 8 once with "Run as Administrator " ? I recall this solved a similar issue back when V6 was in beta if memory serves me well.
No matter how I run it, it still loses the state of the toolbars from the previous session.
Bug number 13: Each time I open Rhino 8 WIP, it disables: Grid snap, Ortho, Planar and Record history. On the other hand, Osnap and Gumball (CPlane) are active. This happens even after I removed my linked RUI file and run as administrator a completely default Rhino 8 WIP with no custom changes.
I’m aware of the tabs and all that. And because I want to continue to use tabs, and I also want to continue to use the command line, we don’t want the new workspace tools to get all padded everywhere and lazy.
In order to have enough room for our work, we need your team to budget their pixels very well in all areas, this is why I posted a side-by-side example with tabs of what V8wip has now vs. what I think it should have:
Exactly my thoughts, too. Way too much space was wasted for unknown reasons that do zero favor to the users. This is why I posted my 2nd and 3rd images in the original post where I compared Rhino 7 and Rhino 8 WIP.
Not only the main toolbar at the top has an unnecessary dark gray border, it’s also surrounded by two extra thick bars (one above and one below) that the Rhino users don’t need at all. Along with eating up important space and reducing the size of the viewports, they are also flashing in a very distracting way upon each hovering with the mouse while trying to reach some icon or the Command line. In order to click on some option in the Command line, a simple mouse movement will cause those two thick bars to flash 4 times total!
Leaving those 4 dots next to each toolbar is also a huge mistake, because they reduce the space and make the UI look busy. Why the Rhino users will be forced to see those dots all the time while they work? I suggest to make them invisible unless the mouse pointer hovers on them.
I completely agree. I didn’t even mention the dots because then I would have to get into proper UX standards, guidelines, mouseovers, grids, etc. And I’m not their UX designer. so I’m limiting my feedback to one simple and hard-to-argue concept: “Pixels are not free, please don’t use them irresponsibly”
Who ever is making decisions about the layout and appearance of the user interface is acting as the designer. Whether they are referred to as the “designer” and whether they have appropriate experience and knowledge is a different question.
We’re actively working on all this stuff… and getting all of it to look and feel right takes time. Keep the feedback coming; I completely agree that we need Rhino to look and feel good by default. My guess is that none of this is going to feel better for many more weeks.