Feature: MSP-OSD Font Manager

[evensis]

I found myself playing around with the fonts after a whole load of them appeared on Discord. However, the manual process of popping files in and out, unplugging the headset, plugging it back in, taking a look at the font, deciding you don't like it, etc. Drove me towards forking the configurator, and putting a small prototype together this evening (purely cosmetic at this stage):

SneakyFPV's font in my example as it's my current go to! :)

Ultimately, I wanted a way to preview the font quickly, and with the talented bunch we have at the moment going all out, it looks like there will be plenty to choose from! But ideally, I wanted to see this showing on the headset itself, it's hard to judge what it's going to look like until it's organised within the headset itself, as we are somewhat limited until additional R&D is done. Luckily, we have plenty of members showing their headsets with the fonts, which is fabulous towards this goal but gets lost in the noise of Discord.

Secondly, I do take my laptop to the field and have a decent internet connection, so being able to quickly flick the font while at the field with wtfos was going to be a nice touch. We can however also cache fonts locally for offline usage if the user suspects they will be outside of cell tower range. Especially useful for those with a Betaflight drone and an Ardupilot Wing on the same day.

We will only be reading, writing, and deleting 5 files and need to do a check to make sure msp-osd is installed before allowing it to be used as a menu item. The extra one is an identifier text file so we know which font is currently installed.

Some general thoughts:

• It would be preferential, that we have a font repository, containing a JSON blob, that we could hydrate a React component with. This way fonts can be added, removed, and updated, without having to update the main configurator.
• Quite dependent on font creator's contributions, and if they would be happy for their work to be within a system like this.
• We could add an additional component, which contains a form element, this form element can contain the elements that are currently being updated CLI. We can also use the same JSON to hydrate the web GUI with the current settings on the headset.
• Scalability with current UI if the font collection grows.
• Do we need to remove the custom fonts when msp-osd is removed as a package?
• It would be ideal if we could find out the flight controller type via the air link, so we can hide particular flight controller font types to stop incorrect installs.

These were just some off-the-cuff thoughts, but would be interested in further input on this, and fleshing it out if there is interest.

[bri3d]

This is an interesting idea directionally.

I think I'd like for things to work like this:

• Fonts are just IPK packages using some directory structure we invent. This way they can be loaded from repositories with repository automation we already have. Font creators can use automation to build the IPKs and push them to GitHub as we do today.
• Then, the JSON configuration system is used in msp-osd to select from fonts on the filesystem. Fonts can still be placed on the SD card which override fonts on the filesystem (to allow users prototype and to select in the field this way if they'd like).
• Yes, adding a component that takes in JSON from the existing configuration and displays it is already a task we should complete, we should reuse such a thing here.
• If the fonts are just packages, we could remove them automatically, or leave them. I suppose if the user uninstalls msp-osd they'd probably want the fonts gone too.
• I don't know what you mean by hiding font types to prevent incorrect installs. We should send the FC identification over the air link, no disagreement at all there! But, plenty of people fly with multiple FC types, so we should just subcategorize the fonts and ideally select between them at run time, not lock them out.

[stylesuxx]

I would also like to simply re-use the package system we already have. Font packages could depend on msp-osd and thus simply be uninstalled when msp-osd is removed. The only downside of doing it like this would be, that a preview image would only be available once the font package is installed.

In regards to settings in general, we were thinking about using JSON schema (and this react component, after trying to run with our own version of that) and extend it with custom widgets as we see fit. The font selection could then be just one of those widgets and we might for example re-use it for screensaver images at one point.

[stylesuxx]

Also: summoning @benlumley - IIRC he proposed JSON schema and mentioned he might at one point also be interested in working on the configurator and since he is involved in the msp-osd too, I would like to hear his thought on this too.

[benlumley]

I also think reuse what we have too; fonts font collections even) as packages... are there any other fields in opkg repo schema we can use to group packages? then we can tag fonts + have a way in the UI to narrow the list if we ever need it ?

@j005u said this on discord last week, which is relevant and makes sense....

@benlumley i was thinking maybe you could add two params, fc type and font variant. and then use those two to construct a font path, falling back to some defaults when the selected fc variant combo is not available. that way maybe @Knifa could publish both the standard fonts and his new variants as packages (happy to walk through the process). the config files can already be used via the cli with wtfos-package-config. we plan to move to the schema definition you proposed for the web version and i'm sure stylesuxx would be super happy if you contributed there, but also a cli version is working already. migrating the schema is relatively trivial and doesn't really affect the msp-osd end of reading values. fc type can get auto as an option when bri3d implements it, and remain as a way to override (eg. bf mode on inav). ideally maybe there's also still a way to specify fonts of sd card too? but yeah, that's my general thinking. we can agree on something like /opt/usr/share/msp-fonts/ as a target where all packages can install their fonts, et voila.

[stylesuxx]

are there any other fields in opkg repo schema we can use to group packages?

We want to display links to a packages README. For this we will have to read the opkg config file anyway, we should (in theory) be able to put custom fields in there for further grouping/details. (Fonts packages could also be prefixed accordingly, or even have their own arch to be distinguished.)

[howels]

IMHO the main thrust was not just packaging fonts but providing a preview image to demonstrate the font elements so that user doesn't need to connect a quad each time to see the font contents. The preview image should be viewable in the package details before installation ideally. Perhaps when expanding the details of the font package?

[evensis]

I would also like to simply re-use the package system we already have. Font packages could depend on msp-osd and thus simply be uninstalled when msp-osd is removed. The only downside of doing it like this would be, that a preview image would only be available once the font package is installed.

We want to display links to a packages README. For this we will have to read the opkg config file anyway, we should (in theory) be able to put custom fields in there for further grouping/details. (Fonts packages could also be prefixed accordingly, or even have their own arch to be distinguished.)

Using the packaging system that's already available is ideal. Can we add custom fields to the opkg repository (something equivalent of yum info <package>)? Where we could conveniently pop the preview image url? I think it's important the user sees what they are getting. A wysiwyg of sorts as that's one of the main issues I wanted to defeat with this, as currently hard to ascertain the end result from looking at a sprite.

I don't know what you mean by hiding font types to prevent incorrect installs. We should send the FC identification over the air link, no disagreement at all there! But, plenty of people fly with multiple FC types, so we should just subcategorize the fonts and ideally select between them at run time, not lock them out.

More to do with dropping the font overrides into the root of the sd card at the mo. Was just thinking about putting something in place to prevent font corruption if someone decides to install Betaflight fonts for their Ardupilot FC. If you have an idea for msp-osd to look at separate directories for each font override per FC - a non-issue! :)

Will come back with a bit more shortly, day job - blah.

[j005u]

RE: previews in configurator.

I've made an earlier proposal in rendering either the README.md via expansion in the packages screen and/or using the first section of README.md or another specific Markdown file (could also be pointed at in package control) and rendering it by default as a block underneath each packages row.

This would be a generic solution to the preview problem that allows for flexibility in many cases.

Alternatively, we could define a control field including an array of images to display for a package. Since a package might include multiple fonts, just one doesn't seem to be enough?

We should be able to extended the control file with arbitary metadata fields. But I would be careful in bloating this as it can get out of hand very quickly.

None of which is to say bespoke solutions in the configurator can't make sense in some cases. But yeah so far, I think 90% can be handled via the framework we've already built up / are planning to implement and the other 10% can be handled by adding a custom widget type to the planned config system.

If we ever want to get fancy then I guess we can distinguish fonts by prefix or a control field like @stylesuxx pointed out and then implement a bespoke view for fonts.

We should discuss who is going to take on which part and maybe break things out into separate issues. @evensis there's probably plenty of opportunities to contribute if you want.

[stylesuxx]

I will look into adding and reading fields from package control. I know getting the Readme link by querying the package info is not a problem. I don't think adding arbitrary fields (and reading them via info) is possible. There might still be some unused fields that we can use for our purposes (or some hacks like for example stuffing JSON in the README field).

Another task would be implementing the general setting interface, implementing JSON schema react component. Maybe we could start here with a simple schema and implement the settings for enabling fake hd with msp-osd. Although this is "only" a checkbox UI wise, we will have everything in place for more komplex settings.

IMHO those are the two main things we need to get going first.

[j005u]

We could replace or enrich opkg info with cat /path/to/control/file.

[evensis]

Sorry for delay, ended up hitting the sack early last night.

I've made an earlier proposal in rendering either the README.md via expansion in the packages screen and/or using the first section of README.md or another specific Markdown file (could also be pointed at in package control) and rendering it by default as a block underneath each packages row.

This would be a generic solution to the preview problem that allows for flexibility in many cases.

How would the data be structured? As long as the ruleset for the markdown is kept to, we shouldn't have issues. If we can drop some kind of structured data blob inside the readme.md (JSON for example) that would be ideal. Otherwise, it will be reading the file into an array or something, and string matching to get what we want, which I'm not so keen on as a solution.

Another thing to consider is producing the font list for the user. In the ideal world, we'd grab a list, plus the preview images all at once so we can loop through it with a single call, one by one calls should be avoided if we can, can imagine it making the configurator very sluggish if we get a lot of fonts otherwise. 👍🏻

Another task would be implementing the general setting interface, implementing JSON schema react component. Maybe we could start here with a simple schema and implement the settings for enabling fake hd with msp-osd. Although this is "only" a checkbox UI wise, we will have everything in place for more komplex settings.

Agreed. I think perhaps breaking it up with one parent component, and then sub-components? Similarly how the configurator is structured out as features at the moment. And then users can flick between with some kind of tabulation perhaps. The main issue I'm predicting as time goes on, is the lists of fonts are going to get reasonably large, and if a user has spent a minute scrolling through it and then decides nope, want to change a setting in the configurator, etc...

I think separating the elements with a floating menu or tabs would be quite helpful, so users can quickly flick between the main configurator section with FakeHD, and fonts (plus anything else that comes in the future), keeping their position on the previous tab, rather than scrolling to the top, etc. We can tackle it with a search system if need be. This also allows easy future scalability for unthought-of things needing their own exclusive area (is for example an OSD configurator a possibility down the road?).

The preview image should be viewable in the package details before installation ideally. Perhaps when expanding the details of the font package?

I like this idea, we could have a tile, with a title and thumbnail of the OSD, and when selected, blows up a lightbox of sorts, which then displays the array of images mentioned by @j005u, using an image slider for UX. The title can go below the images, and the description below that, the install/remove button is on the top right corner underneath the image. Actually, on this we could have a thumbnail mode, that would allow us to display more font packages in a tighter area, this could be used to help towards the too much scrolling issue once the font database grows.

We should discuss who is going to take on which part and maybe break things out into separate issues. @evensis there's probably plenty of opportunities to contribute if you want.

Happy to contribute where I can! I have my local setup of the configurator running so can start once we have a consensus on this, and the bits you want me to do. 👍🏻

[j005u]

How would the data be structured? As long as the ruleset for the markdown is kept to, we shouldn't have issues. If we can drop some kind of structured data blob inside the readme.md (JSON for example) that would be ideal. Otherwise, it will be reading the file into an array or something, and string matching to get what we want, which I'm not so keen on as a solution.

If we want structured data, it should definitely go into the package control, or perhaps even a separate metadata file somewhere. I was talking about giving any package the ability to render what they want in a short section in markdown underneath each packages row. We could set a standard for how we expect fonts to be populated. So technically this would be a a generic solution to allow embedding of eg. preview images for fonts. But maybe some screenshots in some other cases. Or some important descriptive text where the description field doesn't cut it.

Alternatively we could just add metadata (to control or some other way) to have a standardized view for images to be shown as thumbnails and in a lightbox, next to packages. Again, doesn't need to be limited to just fonts.

And then yes, there's a section under the standard config interface for msp-osd for a most likely custom font preview widget.

But, this does still leave us with two distinct places. 1) the packages screen to install and preview fonts and 2) the msp-osd config screen to then preview installed fonts, and pick one from there.

I guess option b would be to do nothing special on the packages screen, and allow for the font selection configurator widget to actually browse all available font packages (via meta in this case, can't use markdown), and install if the selected font is missing when it's selected. This would actually achieve the experience you're looking for, I think.

I'm coming at it from a "let's do the least amount and most re-usable work we can". But if you're up for doing a more bespoke thing for fonts in the config section, then that could also tie into installs I think.

@stylesuxx thoughts? this probably isn't going to be the last time this comes up.

[vicewize]

Sounds interesting...