decrediton
decrediton copied to clipboard
decred
[UI/UX] Text and icon scaling settings
It is pretty hard on the eyes to use Decrediton on high-resolution monitors, and there seems to be no options to scale text and icons.
Below is the screenshot on 2560 x 1440 monitor (running on Ubuntu, Decrediton version 1.6.3):
Can this be improved upon somehow ?
Ideally I would like to have configuration settings (similar to how it is done in Jetbrains IDE products, such as Webstorm/Goland) to increase text & icon size.
Good issue. I've got this listed alongside with a high contrast mode as potential UI improvement for low vision users. Could address after the summer earliest.
Simplest approach that wouldn't break the UI too much would be going with a fixed scale of 3 or 4 steps (ie. small, mid, large 1/1.25/1.563rem something in lines of this). Some type instances will def. need fine tuning and exceptions to account for any context where either things simply does not fit within component/layout or visuals hierarchies get lost. If anyones interested in working on this already, feel free to sync up.
On implementation side would be good if anyone interested in working on this could pitch in on any pitfalls to minimize risk of excessive workload occurring when say some views are changed? Since icons aren't as type elements in decrediton, would assume addressing those adds some difficulty?
In pigui, we always show pages in 100% screen width to address high resolution issues, it would be great of we design decrediton to behave the same.
regarding icons, ideally all icons would be .svgs which scale easily.
we use pi-ui's Icon component in pigui, also here decrediton could use this component:
go to https://decred.github.io/pi-ui then components => Icon.
That way we would have optimized well defined set of icons which could be easily scaled up or down and defined only once, in pi-ui - the Icon component accepts size related props and uses only .svgs.
Technically not a prob, since all the icons are in vector, and actually the animated ones with lottie are in json as well. However I believe we've stayed with using gifs, so these might cause some issues or need separate variants? Maybe worth to re-consider if several gif variants still outweigh lottie?
@linnutee We could try lottie again, but if it still has a noticeable increase in CPU churn it's a no-go.
