I am in the process of recreating a custom workspace from scratch, as all my attempts to successfully import/convert previous V5 workspaces have ended in a brick wall - either the icons are fuzzy, or the toolbars refuse to stay put, or generally both - with different behaviors on different computers, so I finally gave up. So I will make one attempt to rebuild the whole thing starting from a default workspace and hope it will behave better - otherwise, I guess I will just quit trying to use V6.
So, now in my clean copy of the default toolbar layout, each button has 3 icons - 32, 24 and 16 pixels square. It appears that the 24 px is standard, I have no idea how the others are used. What is a current problem is importing a V5 toolbar that has just one 24 px image into V6, it scales the 24 px image up to 32 and then back down to 24, making it fuzzy⌠Hence the âstart from scratchâ.
So, if I want to modify an icon image somewhat, how do I go about editing it so it behaves correctly under all circumstances? I would ideally like to make mods to only the 32 px image and have it cascade down through the others, and not to have to make 3 separate image edits, one for each size.
Workspace editing was made pretty painful in V5, and the system hasnât changed since. Although it was well-intentioned at the time, the end effect was that instead of facilitating personalization, it has made it into a jumbled mess that most people donât want to get intoâŚ
Indeed a very unfortunate episode. Itâs because of this mayhem that I have since tried to keep myself from mentioning or suggesting anything UI related.
That just sounds like a bug that needs to get fixed. Why donât we fix that so you donât have to start from scratch? Iâve reported this in our bugtracking system at http://mcneel.myjetbrains.com/youtrack/issue/RH-32857
Hi Mitch, Steve -
I believe we decided that the V5 toolbar buttons that you (Mitch) had were V4 (orignally) and did not have other than 24 pixel bitmaps in them. I donât think this is a bug itself. If these are used in V5, the 32 is a scaled version of the 24. V6 then⌠uses the 32 and scales it. It is a nasty chain of events but I think it goes back to the 24 pixel only icons that you have⌠am I remembering correctly?
Yep, I think thatâs it exactly. That is to say, there are actually 16 and 32 px versions in V5 if I check, but I think V5 created them automatically from the 24 px ones when it imported the V4 workspace. Whatâs happening I guess is that V6 is seeing that there are 32 bit maps in the V5 .rui and using those⌠but theyâre fuzzy because they were interpolated by V5 from 24 px maps. I donât know how the new system works and how to specify which size icon V6 actually uses⌠Hence my dive into a new clean start.
Mitch, are you using âmediumâ sized buttons or âlargeâ? I may have misled you when you were here because I thought that control had been removed in the WIP, but it has not. Steve says that if your monitor in ânormalâ, not high res, and you are viewing at native resolution, then medium should look like if does in V5.
OK, maybe there is a problem with the WIPâs detecting of a ânormalâ monitor then. The phenomenon occurs on my laptop running at its native 1920 x 1080 resolution. On my fixed install at the school, where I have two 1920 x 1200 screens, it looks like V5 - it uses the 24 bit icons.
Does your laptop its text scaling set to something other than 100%? Iâm talking about the scaling in Windows in general (attached screenshot of control panel)
Itâs possible. This was already happening when the machine had its original Windows 7 install, but I have recently upgraded it to Windows 10 and I think there is something like 125% scaling applied. Let me check and get back to you. --Mitch
OK, dialed the type setting back to 100%, shut down Windows and started up again - necessary to get Rhino to acknowledge the change - and now the toolbar icons look sharp again. Unfortunately, the type everywhere - Rhino, Windows, etc. is now too small for my tasteâŚ
I donât think the solution should be changing the size of everything else to get these tabs back to a normal size. Looking at the bug tracker it appears that there was some kind of fix applied, but Iâm not seeing that here.
And @stevebaer finally the question is - even if I start from scratch - seems the best route now anyway - and I want to modify the images on some buttons, what to I have to do to be V6 and multi-resolution compatible? Do I have to edit all three bitmaps for each ? (or at least 24 + 32, I think we can forget the 16âs) If thatâs the case, then that is also out of the question.
Thanks; thatâs exactly where the problem lies. The images are being scaled to accommodate for the 125% scaling. If I remember correctly, the algorithm I wrote for the scaling will choose to scale the 32pixel bitmap down if it is available; otherwise it will scale the 24pixel bitmap up.
You shouldnât have to edit all three bitmaps. Most likely the 32pixel image will get you the best results for the minimal work. My guess is in a year or so there are going to be more high resolution monitors sold than what we consider normal resolution today. In that case, the 32pixel image will always be used (unless the user has incredibly good eye sight). If you want medium sized images to look crisp on normal resolution screens, youâll probably have to tweak the 24pixel version.
We will most likely have to revisit the images stored in toolbar files in the future (post V6) since we will probably even need vector based artwork in the files. This is something we are currently trying to figure out for plug-in support on OSX and retina displays
Dan, in your screenshot the tabs look to be the same size as the âLayersâ and âNamed Viewsâ tabs. I would also guess the viewport tabs are also the same size. I would really like to have some level of consistency across all of these tabs in Rhino. Do you only want the toolbar tabs to be bigger and if so how much bigger are we talking?
I vote for vector. Yes, I know it sounds like more work initially, but wouldnât you then be covered at all monitor resolutions and sizes?
I mean, youâre already talking about two or three separate sets of bitmaps ⌠doesnât the vector effort make more sense after you pass two or three bitmap sizes?
If all monitors were 4k or 5k, I would agree with that statement. Unfortunately that is not the case and bitmaps at smaller sizes are crisper than vector artwork. It is quite a bit more work and is highly unlikely to be added to V6.
Yes the tabs are all consistent, but if you choose to display them without text theyâre all too small. I suppose we would eventually get used to it, but our workforce is getting older, and eyesight isnât getting better!
However, if you display them with image and text they are large enough to be easily selected (seeing the small tabs is only half the issue. Slowing down the cursor to hone in on the tiny tab is the other half of the problem),
So this really eliminates the option of displaying the image only. We are forced to display with image and text.
I believe the consistency should be maintained. I agree with that. However, I think the user should be given the choice as to how large or small to display the tabs. The medium tab size in V5 seems to me to be a good choice.