[Accessibility] Let User Modify Font Size

[cibersheep]

@bhdouglass There's a couple of tries to make a theme / options in the system more accessible to people with special needs.

A user (David) suggested looking UC Font Utils

• What are the thoughts?
• Is it viable?
• What are the downsides?
• Will this break compatibility?

[dobey]

This is far more difficult than having a simple dark mode switch which simply changes the theme in an ini file between SuruDark and the default.

I don't think this is viable in UITK at all, as it would mean breaking API and requiring all apps to be updated to handle it. Then there's the issue of apps using other toolkits, or only using qqc2, or such. I also think it would be better to work on moving away from UITK to qqc2 in general, and finding solutions for this that work with upstream Qt (and other toolkits).

[JassMan23]

Sorry but I beg to differ.

I can't code in C++ but I do understand the basics of how the themes work. Specifically Ubuntu.Components. The fonts for everything running under the Touch UI are determined by The code can be reviewed C++ code and its header. This is not the actual code used at the moment but I am sure I can find the files given a bit more time. At the moment, a public variable:

public:
static constexpr float fontUnits = 14.0f;

sets the base font size to a nominal 14 (points?) and the code in the cpp file returns a multiple corresponding to the requested xxsmall, small , medium or whatever. The cpp just needs to to read an env variable eg BASE_FONT_SIZE=17.5.
If set, use it as fontUnits, else:

return modularScale(size) * UCUnits::instance()->dp(fontUnits);

Also, I believe you can replace Context Properties in place so there is no reason why the same code couldn't be used in individual themes if necessary, but I think most people would be less confused if everything stayed the same when changing themes to get a different color palette.

[JassMan23]

Apologies all round. I hadn't realised that you were working on replacing Ubuntu.Controls with qqc2. Or more correctly I had seen mentions of qqc2 but not realised that it was a replacement UI.

In some ways though I think my original argument still stands. I see that in qqc2 you have a set of font sizes which are altered by a multiplier SURU_FONT_SIZE_MULTIPLIER. Instead of that size being hardcoded, I believe that it should have a default (currently 0.85) but read an env var FONT_SIZE_MULTIPLIER to allow the user to change it. It would be a good idea to have some sort of bounds checking such as 0.7 to 2.0.

UTTT could be used to set the environment variable to a different value in the event of limited visual accuity.

[bhdouglass]

Some thoughts:

• Is there something in Qt/qqc2 that already does this?
• Would it make sense to make the font preference something that is exposed to apps but not enforced on them? So that way the apps need to be updated to be "font size aware" rather than forcing a font size on the apps that might make it out of wack.
• How does iOS/Android do handle this?

[JassMan23]

Yeah I have been looking at all the qt documentation on this. I looks like we need to create a "style" eg. Suru. The style can have themes say SuruDark and Suru light and whatever "Attached properties" are defined in the style can modified by the theme. The themes themselves can be modified (or swapped for another). Attached properties can include any of the attibutes of any of the controls within the style such as varying font sizes, font face, all the colors used. I assume we could even define the radius and width of the buttons in the theme which means we can make accessibilty themes for people with low visual accuity. The QT docs say there are a set of standard env variables for each of the built in styles, one of which set the base font size.

However, I was thinking that since the themes are QML/jscsript, why not have a universal theme which reads a json file for all its attributes. Because QQC2 has a fileswap utility we could do the light/dark/size change just by swapping the json read at any specific time. I think the style might need to include a trigger to reread the file but as far as I can see we wouldn't even need to restart Unity to make changes. QT have examples which show a theme change happening immediately.

Another useful part of qqc2 is a configuration file which allows you to make say Suru the default style. So developers wouldn't need to develop specifically for Suru, just for qqc2 which would make code much more portable (probably why they did it). The only small problem is that all apps would need to be launched by a launcher which implements the use of the configuration.

[JassMan23]

Just found this bit about configuation which implies that clickable could copy an appropriate config to set suru style at build time.

[dobey]

@bhdouglass For your second point, it is not feasible nor possible to enforce font configuration on apps. An app can always do what they want in that regard.

I'm not sure if there is a way to do automatic global font size changes nicely in Qt either really, currently. Using attached properties with a style module import requires apps to add extra code, which relies on the style being there.

Regarding the light/dark/highcontrast theme comments above, QtQuick already has a palette solution that could be used for that.

I haven't looked too deeply into solving this specific issue yet though, as there are much bigger fish to fry still. It would be nice if we could fix this in a way that works as live updates, than requiring system restarts; so I'm against any solution that would depend on an environment variable for example.

[bhdouglass]

I'm specifically saying that we shouldn't force a size on apps, it could break to many things. I'm thinking provide an option to the user that is a preferred font size (normal/large/xlarge?) or something and then expose that to app developers to adjust if they want to. Similar to how we want the dark preference to be an "opt-in" for apps.

[JassMan23]

I think the qqc2-suru-style project is probably heading in the right direction. Having read a bit more about qqc2, I am convinced that a properly written style (as suru appears to be) offers the ability for all apps to share a common look without developers needing to worry about font size etc. I think it may possibly mean different themes for different hardware but qqc2 appears to offer "theme independence" as far as the dev is concerned. ie. There is a virtual "system" theme which returns variables and methods based on the configured default theme. As long as we can maintain a consistent interface between all styles and themes, end users should be able to mix and match as they like. I think the most important thing to produce is "style guide" which helps developers falling in the bad habits of hardcoding their own sizes, colors etc. The existing doc at mimecar.gitbooks is a good start but needs updating to show where we are heading with qqc2. For instance it currently suggests

`Button {

text: "8"

color: UbuntuColors.graphite

}`

Whereas to ensure that apps remain consistent, color should be defined

color: System.graphite

This means that the UI could eventually contain time based profiles such that a reselection of the theme would allow graphite to be slightly more yellow during the hours of darkness to avoid resetting circadian ryhtms but slightly more blue during bright viewing so it still looks neutral.

Possibly we also need a "theme and style writers" guide to ensure that all themes are consistent with all styles.

I think it may also be worth exploring the possibility of storing json files (as outlined in a previous comment ) in say ~/.local/themes to allow users create a flourescent pink theme if that is what floats their boat.

[UniversalSuperBox]

Ubuntu UI Toolkit has moved to https://gitlab.com/ubports/core/lomiri-ui-toolkit. If this issue is still relevant, please file it again at https://gitlab.com/ubports/core/lomiri-ui-toolkit/-/issues.