Use I²C Config Values to Initialise CustomFontDisplay #342
Conversation
I agree. We should start to gather up a list of software tasks related to the X that people can pick up and run with. GitHub issues, with an appropriate tag, seems like the logical place, but there are other choices if that doesn't seem appropriate. |
GitHub Issues is perfect I think, especially how easy it is to link them to PRs and back to keep track of changes. I'm going to make an issue that's specifically about elevation of functions out of experimental as I think for firmware changes (like custom font capability) having a proper route to getting this into Having read back through #275 I do think that some form of user contributed extra library would be good for anything other than real firmware stuff, the things that can be used across scripts. This could be part of the elevation process, where users just add to experimental with features that might fall into either, and a more thorough review/waiting game for another script to use it happens before a decision is made about where to elevate it to/whether to leave it in experimental. I think the name "experimental" does imply this kind of functionality, where robust and specific enough code will eventually be granted a higher status and no longer be considered experimental, and I think that's a good thing |
Relies on #340
Use configured I²C values to initialise CustomFontDisplay instead of just 0 and 1
This might be the point where it becomes worth having the discussion about elevating custom font functionality out of experimental, as larger displays are a nice opportunity for certain scripts e.g. Pams to use larger fonts for parameters when they're in edit mode. I think that the functionality can be included with very little overhead, but the fonts themselves should be picked more carefully as they're quite big (10kb - 22kb), so maybe normal vs big font would be a nice middle ground rather than a wide range of fonts