Upgrade font_family to a list_property

[HalfWhitt]

Wow, it was apparently over a year ago that I added list_property to Travertino. This finally makes use of it.

As discussed briefly on Discord with @freakboy3742, the source of truth for Font objects is shifting slightly. Previously, if you created a Font object and it wasn't able to load its font face, it would fall back to system. Now, it throws an UnknownFontError — the fallback behavior is instead implemented one level "higher", in Pack.apply. This does mean that in the rare few cases where an end user creates their own Font object, they'll need to make sure the font family is valid.

I made adjacent cleanups in some of the files I touched. Some were just typos or changes in wording, but I'll comment inline on a couple that are less self-evident.

PR Checklist:

• All new features have been tested
• All new features have been documented
• I have read the CONTRIBUTING.md file
• I will abide by the code of conduct

[HalfWhitt]

Unlike every other backend's Font, which does its try-to-load-the-font logic directly in Font.__init__, the Android version does it in its Font.typeface method. This is called in the set_textview_font function, which in turn is called by TextViewWidget.set_font whenever any text-displaying widget sets its font. I think I'll need to do some refactoring to get the UnknownFontError to bubble up in the right spots and not in others, but I'll need to study the Android backend before I know how to do that.

[HalfWhitt]

@mhsmith First of all, thanks a ton for helping me get the Chaquopy example app up and running. Its Python REPL is super handy for API exploration.

Second — just to sum up what I've found from the source, Android's docs, and talking with you and Russ on Discord: all text widgets in the Android backend cache their default typeface and default font size, because those aren't the same for every kind of widget, specifically:

• Buttons have a weight of 500 (or "medium", bolder than 400/normal but lighter than 600/"semi-bold")
• Text inputs have a larger-than-usual font size.

Have these been / do we expect these to remain stable? Is there a decent chance those defaults might change, or that other widgets might gain default font quirks, in future versions of Android?

I ask for two interrelated reasons.

• If we were to decide we can reasonably trust these, it could simplify logic elsewhere (and vastly cut down on the amount of font-caching) if we special-case this behavior to just those two widgets.
• If there is a decent chance of other idiosyncrasies appearing... As it's currently implemented, I believe that if a widget had its default typeface set to bold and/or italic, that would get overwritten when we apply the default Pack style.

[mhsmith]

Have these been / do we expect these to remain stable? Is there a decent chance those defaults might change, or that other widgets might gain default font quirks, in future versions of Android?

It's possible, they change the system theme fairly often.

• As it's currently implemented, I believe that if a widget had its default typeface set to bold and/or italic, that would get overwritten when we apply the default Pack style.

Wouldn't that be covered by the same mechanism that handles the Button and TextInput differences?

[HalfWhitt]

Is there a decent chance those defaults might change, or that other widgets might gain default font quirks, in future versions of Android?

It's possible, they change the system theme fairly often.

Okay then, safer to stick to caching everything's font across the board.

• As it's currently implemented, I believe that if a widget had its default typeface set to bold and/or italic, that would get overwritten when we apply the default Pack style.

Wouldn't that be covered by the same mechanism that handles the Button and TextInput differences?

Currently the code applies the bold/normal and italic/normal values that are found on the interface; it doesn't distinguish between a normal that the user explicitly set vs. the default value. I can add a check for that, just to be safe. That way, if a widget is natively bold, and the user creates a new one without specifying yea or nay on boldness, it'll stay bold.

Correction: I was misreading the code a little, and had it backward. It's not that it would get overridden to normal; it's that the user wouldn't be able to make it normal even if they explicitly request it, because each of the two qualities is only applied if it's turned "on".

[HalfWhitt]

Just laying out what I understand the expected behavior to be:

Font Family

SYSTEM, whether set by the user or present as the default value, means use whatever the widget would use by default. Anything else is applied if possible.

Bold / Italic

For each of these, the default value is NORMAL. If it's that because it hasn't been set, follow whether the widget's text would be bold/italic by default or not. If it's been explicitly set, either to NORMAL or to BOLD/ITALIC, use that.

Font Size

SYSTEM_DEFAULT_FONT_SIZE, whether set explicitly or not, means use the widget's default font size; anything else is applied as requested.

[HalfWhitt]

...Now that I think about it, I was mixing up layers in my head. Differentiating between implicit and explicit NORMAL at the implementation level wouldn't be possible without altering the core/interface layer Font to record the difference when created; the Font implementation has no knowledge of the Pack instance that led to its creation. I'm starting to wonder if that's worth it for something that may or may not ever happen.

[HalfWhitt]

Okay, maintaining status quo on behavior of Android fonts — that is, we're still good for now, and will still have a quirk if any widget ever gets a bold or italic font by default. I don't know if it's worth creating an issue for posterity, or if this thread is sufficient.

[freakboy3742]

I've flagged a couple of minor things inline, but otherwise I think this all makes sense.

I'd definitely like Malcolm to take pass at it - especially for the Android side of things. It looks OK to me, but I want to make sure we're not missing anything on Android as part of eagerly caching fonts on instantiation, rather than use.

[HalfWhitt]

Looks like the docs are failing because https://pygobject.gnome.org/ and http://docs.gtk.org are both down.

The sites are back up. How do I rerun the Read the Docs build? I don't see an option to do so, nor, it occurs to me, do I even know where that's invoked.

Edit: now a moot point because I made another change, but I'm still curious for future reference.

[freakboy3742]

Edit: now a moot point because I made another change, but I'm still curious for future reference.

If you're a project maintainer on RTD, the UI on the RTD build page has a "rebuild" option. Happy to add you as a maintainer if you want.

[HalfWhitt]

If you're a project maintainer on RTD, the UI on the RTD build page has a "rebuild" option. Happy to add you as a maintainer if you want.

I'd appreciate that, thanks!

[HalfWhitt]

Could you take a look at this when you get a chance please, @mhsmith?

[mhsmith]

Sorry, I'll look at it tomorrow.