SUMMARY I have some issues with the readability of the scrollbar. 1. Too little colour change when hovering over the scroll box: hovering over the scroll box results in a very slight colour change that is very hard to see. It is very subtle and only shows on part of the scroll box. My regular drawing app is clip studio paint in light mode, where the scroll box changes from rgb(217, 217, 217) to rgb(195, 195, 195) when hovered over. The color of the scroll bar backing is rgb(239, 239, 239). In my opinion something like this is vastly preferable for readability. My preference would also be to have the entire bar change color rather than the gradient. I would prefer the box to be dark against a lighter scroll bar, in line with modern standards, but that is just personal preference. I cannot speak to what would be ideal for dark mode or high contrast, but in my opinion they also need to be changed. 2. scroll box should be bounded by scroll bar. The scroll box should be 2-3 pixels inside of the scroll bar to aid readability.
The size of the scroll box is determined by the widget theme; that is outside of Krita's capability to change. (On some platforms you can choose between widget themes, though.) The colors theme is determined by files in the resources section: https://docs.krita.org/en/reference_manual/resource_management.html#resource-management -- you can create new themes. Unfortunately, I cannot find the docs for that right now, since their location on the KDE project wikis has moved so often. The current color themes have been created by a long-term Krita user, David Revoy, so I am not sure we should modify them without his input.
(In reply to Halla Rempt from comment #1) > The size of the scroll box is determined by the widget theme; that is > outside of Krita's capability to change. (On some platforms you can choose > between widget themes, though.) The colors theme is determined by files in > the resources section: > https://docs.krita.org/en/reference_manual/resource_management.html#resource- > management -- you can create new themes. Unfortunately, I cannot find the > docs for that right now, since their location on the KDE project wikis has > moved so often. The current color themes have been created by a long-term > Krita user, David Revoy, so I am not sure we should modify them without his > input. (In reply to arthurfermor116 from comment #0) > SUMMARY > I have some issues with the readability of the scrollbar. > > 1. Too little colour change when hovering over the scroll box: > hovering over the scroll box results in a very slight colour change that is > very hard to see. It is very subtle and only shows on part of the scroll > box. My regular drawing app is clip studio paint in light mode, where the > scroll box changes from rgb(217, 217, 217) to rgb(195, 195, 195) when > hovered over. The color of the scroll bar backing is rgb(239, 239, 239). > > In my opinion something like this is vastly preferable for readability. My > preference would also be to have the entire bar change color rather than the > gradient. I would prefer the box to be dark against a lighter scroll bar, in > line with modern standards, but that is just personal preference. I cannot > speak to what would be ideal for dark mode or high contrast, but in my > opinion they also need to be changed. > > 2. scroll box should be bounded by scroll bar. The scroll box should be 2-3 > pixels inside of the scroll bar to aid readability. (In reply to Halla Rempt from comment #1) > The size of the scroll box is determined by the widget theme; that is > outside of Krita's capability to change. (On some platforms you can choose > between widget themes, though.) The colors theme is determined by files in > the resources section: > https://docs.krita.org/en/reference_manual/resource_management.html#resource- > management -- you can create new themes. Unfortunately, I cannot find the > docs for that right now, since their location on the KDE project wikis has > moved so often. The current color themes have been created by a long-term > Krita user, David Revoy, so I am not sure we should modify them without his > input. Thanks for replying so quickly :) As a follow up, I was curious about whether you know of any documentation of the .COLORS file format? I tried to make one of my own but struggled with how to save with that file extension. All I could find online was that it is associated with corel painter, which I don't own. I think that it does make a lot of sense to change the default color schemes from what they originally were. I don't understand the reasoning behind keeping the themes because they were made by a long term user. He couldn't have used all of the color schemes at the same time, and getting other peoples input is important if they are the ones using it. My complaint is that, when compared to dark mode, the amount of change in value in the scroll bar is almost imperceptable on the scroll box in breeze light. From looking at the files in qt creator, some of them date as far back as 2012, and I don't think it is unreasonable to consider how much design sensibilities (and our understanding of accessable design) have changed in the intervening 12 years. Also consider how much visual redesign does to make people want to try new products: Apple have barely changed the iPhone feature set in recent years, but people continue to buy new versions because of the new colors and the adjustments made to iOS over the years. Part of what got me (and a lot of people) to try using blender again was the visual redesign that came with the 2.8 update. I am sure you and the rest of the team are working very hard on new features, but how many people will actually update the program if the visuals remain the same?
> how many people will actually update the program if the visuals remain the same? I think many people do get excited about the new useful features when they see it. Though of course visuals are important too. Anyway, the problem with scrollbars and color-schemes/themes is that there are not two separate colors for the bar and the background of the scrollbar, but just one color that is modified to be lighter and darker for the bar and the background respectively. That color is "BackgroundNormal" in section "[Colors:Normal]". You can set it to "255,0,0" to see the whole bar changing to red. From what I checked, you can get better contrast (using the standard Krita Dark theme) if you set it to "90,90,90", and basically the lighter it is, the better the contrast. "100,100,100" is mostly usable too, but keep in mind that the higher you go, the less contrast you have with text. It looks a bit uglier but it works better, I guess. The theme that works best is Krita Bright, I believe. The documentation I could find is here: https://docs.kde.org/stable5/en/plasma-workspace/kcontrol/colors/index.html There is a chance that the settings on top: "[ColorEffects:Disabled]" and "[ColorEffects:Inactive]" might have some effect on the scrollbar but I doubt it. There is an option to create a new style (but that would mean forking Fusion, I think? Probably bundling Breeze would be way less invasive and there is a good reason why we don't do that), or apply a stylesheet (but in that case we wouldn't be able to use themes). We could possibly patch Fusion for our own builds, or maybe replace all scrollbars with a custom one with a custom painting process. Not sure if the effort is worth it. I've seen people complaining about this before so it does seem to be at least partially an issue, but whether or what we should do about this is another matter. Maybe we should downgrade it to a wishlist, too. The slider is not unusable, and one can use Krita Bright theme for better contrast.
(In reply to Tiar from comment #3) > > how many people will actually update the program if the visuals remain the same? > > I think many people do get excited about the new useful features when they > see it. Though of course visuals are important too. > > Anyway, the problem with scrollbars and color-schemes/themes is that there > are not two separate colors for the bar and the background of the scrollbar, > but just one color that is modified to be lighter and darker for the bar and > the background respectively. That color is "BackgroundNormal" in section > "[Colors:Normal]". You can set it to "255,0,0" to see the whole bar changing > to red. > > From what I checked, you can get better contrast (using the standard Krita > Dark theme) if you set it to "90,90,90", and basically the lighter it is, > the better the contrast. "100,100,100" is mostly usable too, but keep in > mind that the higher you go, the less contrast you have with text. It looks > a bit uglier but it works better, I guess. The theme that works best is > Krita Bright, I believe. > > The documentation I could find is here: > https://docs.kde.org/stable5/en/plasma-workspace/kcontrol/colors/index.html > > There is a chance that the settings on top: "[ColorEffects:Disabled]" and > "[ColorEffects:Inactive]" might have some effect on the scrollbar but I > doubt it. > > There is an option to create a new style (but that would mean forking > Fusion, I think? Probably bundling Breeze would be way less invasive and > there is a good reason why we don't do that), or apply a stylesheet (but in > that case we wouldn't be able to use themes). We could possibly patch Fusion > for our own builds, or maybe replace all scrollbars with a custom one with a > custom painting process. > > Not sure if the effort is worth it. I've seen people complaining about this > before so it does seem to be at least partially an issue, but whether or > what we should do about this is another matter. > > Maybe we should downgrade it to a wishlist, too. The slider is not unusable, > and one can use Krita Bright theme for better contrast. my point is not that it is unusable, but it seems like a broken feature, and is not achieving the intended effect. My main issue is with the hover over animation which is almost imperceptable. I have a screen capture here that hopefully demonstrates the comparison. https://drive.google.com/drive/folders/1bErfDRO0mhAQmpO1PpmKTL_123R9jVsI?usp=drive_link In terms of usability, I think this is well below the recommended contrast for accessability https://webaim.org/articles/contrast/#sc143 My preference would be to have a lower contrast UI to emphasize the components that I am actually interacting with, like the color selector, while maintaining visual contrast through context sensitivity.