UI: Merge Text Style "Widget Label" into "Widget", Add "Tooltip" #111712

New Issue

Harley Acheson · 2023-08-30T19:41:36+02:00

Harley Acheson commented

2023-08-30 19:41:36 +02:00

When controlling how big interface elements are displayed, users can not only change the Resolution Scale and Region Zoom but can change the size and styles of some elements separate from others. This document proposes changes to our Text Styles.

If you go to Preferences / Themes / Text Style you will see that you can change the size of different UI elements independent of the overall UI scale. You can make it so that regardless of scale you always have Header text twice as large as regular text, for example.

But the design is not fleshed out well. We have just "Panel Title", "Widget", and "Widget Label". There are many areas where one type of UIBut uses one when it should use another. There are assumptions, like in #102687, that "Widget" and "Widget Label" are the same size. The function mentioned in that bug report - ui_text_icon_width_ex() - is trying to estimate an element's width but does not have the information needed to know what style to use, so just uses UI_FSTYLE_WIDGET, which is hardcoded for the "widget" style.

It seems like a nice idea that we can have labels displaying differently to the inputs beside it. And I have personally proposed adding to these options to include width, weight, slant, spacing and other text features.

However, our interface is laid out programmatically using quite rough rules. We necessarily have a very tabular layout. For example we don't have (and might not be able to supply) a "line height": the vertical spacing between interface rows. This value is calculated from UI element width, considering scale and line width. So can't for example, leave the resolution scale the same but change the line-height to better accommodate languages that use fonts that are very tall (Arabic) or squat (Chinese).

This all means that we have little chance to make Label and Widget have varying sizes. The line-height can't vary with the largest of them, and we have to keep all interface rows the same height anyway.

I propose that we merge "Widget Label" into "Widget" text styles, leaving us with only two styles "Header" and "Widget". And then add a third back for "Tool Tips" because that text size is currently set as a hardcoded fraction of the widget size - and I can imagine some users with vision impairment wanting those proportionally larger.

The only real downside is this would remove the ability for "Widget" and "Widget Label" to have differences unrelated to the size. There could be some users who have the same size but have them differ in shadow. Right now the only non-size changes possible are shadow-related but, as mentioned, we could add other options. For example we could allow one to be bold and the other italicized. But I don't personally think this is important. I don't like our text shadowing and use of weight and slant differences should be more selective than this, having sematic meaning. I would rather embolden important words, italicize special sections, etc.

When controlling how big interface elements are displayed, users can not only change the Resolution Scale and Region Zoom but can change the size and styles of some elements separate from others. This document proposes changes to our Text Styles. If you go to Preferences / Themes / Text Style you will see that you can change the size of different UI elements independent of the overall UI scale. You can make it so that regardless of scale you always have Header text twice as large as regular text, for example. But the design is not fleshed out well. We have just "Panel Title", "Widget", and "Widget Label". There are many areas where one type of UIBut uses one when it should use another. There are assumptions, like in #102687, that "Widget" and "Widget Label" are the same size. The function mentioned in that bug report - `ui_text_icon_width_ex()` - is trying to estimate an element's width but does not have the information needed to know what style to use, so just uses UI_FSTYLE_WIDGET, which is hardcoded for the "widget" style. It seems like a nice idea that we can have labels displaying differently to the inputs beside it. And I have personally proposed adding to these options to include width, weight, slant, spacing and other text features. However, our interface is laid out programmatically using quite rough rules. We necessarily have a very tabular layout. For example we don't have (and might not be able to supply) a "line height": the vertical spacing between interface rows. This value is calculated from UI element width, considering scale and line width. So can't for example, leave the resolution scale the same but change the line-height to better accommodate languages that use fonts that are very tall (Arabic) or squat (Chinese). This all means that we have little chance to make Label and Widget have varying sizes. The line-height can't vary with the largest of them, and we have to keep all interface rows the same height anyway. I propose that we merge "Widget Label" into "Widget" text styles, leaving us with only two styles "Header" and "Widget". And then add a third back for "Tool Tips" because that text size is currently set as a hardcoded fraction of the widget size - and I can imagine some users with vision impairment wanting those proportionally larger. The only real downside is this would remove the ability for "Widget" and "Widget Label" to have differences unrelated to the size. There could be some users who have the same size but have them differ in shadow. Right now the only non-size changes possible are shadow-related but, as mentioned, we could add other options. For example we could allow one to be bold and the other italicized. But I don't personally think this is important. I don't like our text shadowing and use of weight and slant differences should be more selective than this, having sematic meaning. I would rather embolden important words, italicize special sections, etc.

👍 1 ❤️ 2

Harley Acheson added the

Type

Design

label 2023-08-30 19:41:36 +02:00

Harley Acheson added this to the User Interface project 2023-08-30 19:41:38 +02:00

Harley Acheson referenced this issue

2023-09-04 01:44:01 +02:00

Fix #102687: Use Proper Style for Label Length Estimation #111908

Harley Acheson commented

2023-09-04 02:06:44 +02:00

@pablovazquez @lone_noel

There is at least one good reason to keep separate text styles for widget and widget_label. But it needs some consideration because I might be the only person who finds the reason "good"...

Our text output code already supports "Variable font" features. These are new types of fonts that contain a continuous range of design variation. These fonts can change their boldness, width, tracking, slant, and quite often other features along variable axes.

Almost all of the fonts in our current "font stack" are variable versions. But our main font is still an old font that does not. I would love to one day replace our current font with something newer. That newer font would be variable. Then we could extend our Font Styles to include these attributes. So while using one font we could have widgets labels that are slightly bolder, or narrower, or slantier, etc

This is a bit of a change of direction for us. Once we started I can imagine a new text style just for the text editor, so you could change grade (weight without width change) for example. Or "placeholder" could even be its own font style.

I did propose this sort of thing when I first added support for variable fonts, but these "user facing" settings were removed from the initial patch because of some skepticism on their need and use.

Following is a link to Google Font's page for "Roboto Flex" where you can play with all all the variations of that font: https://fonts.google.com/specimen/Roboto+Flex/tester

@pablovazquez @lone_noel There is at least one good reason to keep separate text styles for widget and widget_label. But it needs some consideration because I might be the only person who finds the reason "good"... Our text output code already supports "Variable font" features. These are new types of fonts that contain a continuous range of design variation. These fonts can change their boldness, width, tracking, slant, and quite often other features along variable axes. Almost all of the fonts in our current "font stack" are variable versions. But our main font is still an old font that does not. I would love to one day replace our current font with something newer. That newer font would be variable. Then we could extend our Font Styles to include these attributes. So while using one font we could have widgets labels that are slightly bolder, or narrower, or slantier, etc This is a bit of a change of direction for us. Once we started I can imagine a new text style just for the text editor, so you could change grade (weight without width change) for example. Or "placeholder" could even be its own font style. I did propose this sort of thing when I first added support for variable fonts, but these "user facing" settings were removed from the initial patch because of some skepticism on their need and use. Following is a link to Google Font's page for "Roboto Flex" where you can play with all all the variations of that font: https://fonts.google.com/specimen/Roboto+Flex/tester

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

UI: Merge Text Style "Widget Label" into "Widget", Add "Tooltip" #111712