Toolbars, again

Ah… so maybe this is a width issue with the image only tabs. If the image only tabs got their width bumped up by a little bit, would that work for you?

Yes, unfortunately that leaves us in somewhat of a quagmire today, trying to do production work with existing equipment as well as planning for the future evolution. I’m probably not alone in having a mix of monitors, my laptop is only HD but it’s old and will probably get upgraded to a 4K unit soon, my workstations have generally two 1920 x 1200 monitors, and I don’t really feel the need to go to 4K with those (yet). And I am adding a color-calibrated 2560 x 1440 (2K?) monitor to the mix for photo work… What happens anyway if you have a desktop across 2 monitors with 2 different resolutions and you slide the Rhino window from one to the other…?

–Mitch

Yes, that would definitely be better.

Thanks,

Dan

Indeed, it would seem that on the hi-res monitors, visual issues take second place to mouse ergonomics. That is: for anyone with 20-20 near/mid vision (corrected or uncorrected) it is possible to see, identify and visually target a pretty darn small icon, but as Dan points out the mechanics of carrying out a mouse operation requires a larger target than our eyes do. You refer to making the tabs wider, but I think height matters too. Perhaps a standard for minimum actual mm of tab height and width needs to be established and adhered to regardless of pixel size. Minimums for icons can be treated independently, subject to being able to fit on the tab. A look at Dan’s examples will also make it obvious that, visually, contrast is important too.

On the matter of vector icons, isn’t that what openGL is all about: making bitmaps of vector objects? I’m not suggesting it wouldn’t take some effort, but it seems, from my OGL groupie viewpoint, that perhaps sizing and creating icons from vectors might even be something that could advantageously be moved onto the GPU in a shader? Or maybe not, since they only need to be created for each new instance of Rhino or those rare occasions when the user wants to change the size.

I bumped up the size of the tabs for the next WIP. Let me know if you think they are still too small.

Sure thing. Thanks for doing this.

Dan

Hey Mitch,
I added some code to try and handle these in between scales (like 125%). You shouldn’t get fuzzy buttons in the next WIP, though they will be a little smaller than they currently are on your screen. Let me know if this is better or worse than what you are currently seeing. (I’m basically rounding the 125% scaling for button sizes down to 100%).
Thanks
-Steve

OK, will do, thanks Steve!

OK, @stevebaer the icons now look better when the type scaling is at 125%, thanks. Now I have something different happening - same Win 10 laptop, the window border color no longer responds and is white (actually 240,240,240)… On my Win 8 machine, it works as expected… Particularly noticeable if you have a dark background/toolbar color… Anyone else on Win 10 see that?

I see it. Working on a fix

I just pushed a fix for this so you should see this fixed in the next WIP
https://mcneel.myjetbrains.com/youtrack/issue/RH-33051

Hi @stevebaer,

The tab width is better. Would it be possible to increase the height by 25%? I notice some of the images in the tabs are being truncated.

Thanks,

Dan

Got it, thanks
http://mcneel.myjetbrains.com/youtrack/issue/RH-33058

So, Steve. You know how us old guys know absolutely everything about everything. I’m wondering: isn’t WPF supposed to allow developers to work to physical dimensions and automatically take care of the details for any given display? Can WPF forms and Windows forms coexist in the same application? Could Rhino migrate one form at a time? Am I nuts?

I can’t be the judge on if you are nuts or not :slight_smile:

We are already using WPF in some elements of Rhino’s UI (Eto uses WPF as it’s user interface API on Windows). Switching the toolbars over to WPF would be a rather large project and it wouldn’t ‘automatically’ solve this issue.

I understand. I meant that AFTER you did all the non-automatic work of conversion, WPF would automatically take care of making the UI objects the designed physical size no matter what the display resolution. Is that right?

In the context of toolbar code where everything is custom, WPF doesn’t really help respect to automatically resizing things.

The tab height should be slightly larger in the next WIP

Thanks

I’ve given this a few months to try to get used to the smaller tabs, but I find that it’s slowing the workflow down by having to be more precise with the mouse movement to hone in on the small tab. My only option is to display the tab with “image and text” to force a larger tab surface area. I tried increasing the overall Windows experience to 125% but that just makes everything too big.

Any chance the tabs could get another slight size increase? I think if the height of the toolbar tabs was the same as the height of the docked tabs it might be enough to make a difference. Also, the docked pane tabs are too narrow. The images are truncated due to the narrow size,

Thanks,

Dan

1 Like