Closed MarkOates closed 1 year ago
Consider adding a FontKit
which would have predefined named font styles like "title", "header1", "paragraph", etc.
Another way to look at this is to consider in what kinds of scenarios you might need the different arrangements?
For example, you might have a component that internally relies on the FontBin
, but is not intended to have customized fonts.
After using the components for awhile now, the solution is relatively simple, option 1:
Pass in two arguments,
font_identifier
, andfont_size
This allows the user to customize the typeface and the size, controlling each independently, without any additional requirements. For the Elements/Stopwatch
example, there are now several other components, some screens like TitleScreen
for example, that allow you to customize individual typefaces and sizes.
If any extra required "management strategy" or whatever is needed, that can be added as another layer up. The minimum pieces are the font_identifier
, font_size
, and font_bin
.
The (Elements/Stopwatch and Elements/Text) classes should be updated so the have the font_identifier
and font_size
options.
Right now, there isn't a clear strategy on how to customize fonts in the different
Elements
. Specifically,Elements/Stopwatch
andElements/Text
, both of which require you to pass in aFontBin
but not let you define a font (which is selected internally).Here are a few possible options:
1) Pass in two arguments,
font_identifier
, andfont_size
<-- 🌟 Update: this option is preferred 2) Pass in a single argument,font_data_str
, which is a single string in the format"[font-name] [font-size]"
. This is the current way aFontBin
references and loads the resource. 3) Create a newFont
object inAllegroFlare
, and, pass it into theElement
. This would leave open the decision: a)Font
will have aFontBin
injected into it. b)Font
will not have aFontBin
injected, but rather a component would join the two together, perhaps theElement
. 4) There's some kind of global font registry where{ identifier, ALLEGRO_FONT }
can be initially loaded and then referenced by anidentifier
. This would be accessible globally, and, breaks the design for using a global resource. The constant injection ofFontBin
across a bunch of stuff is what this is meant to fix. Maybe the registry can be included in aFramework
... but then again, that's whatFontBin
is.