Enable required fonts in sdkconfig.defaults of the project generated by Squareline (BSP-318)

[igrr]

This issue is at the boundary between ESP-BSP and Squareline, I'm filing it here for now for discussion.

Currently when we use a font in Squareline which isn't enabled by default in LVGL, the build will fail due to missing definitions. For example, if we use Monserrat size 48, CONFIG_LV_FONT_MONTSERRAT_48=y option should be enabled in sdkconfig.

This could be solved by:

• Adding some placeholder in sdkconfig.defaults of our Squareline package
• Squareline IDE should put the font-related settings instead of that placeholder
• [Optional] Squareline package JSON file can define mapping between font names and the lines to be put into sdkconfig.defaults, to avoid hardcoding the Kconfig option names in Squareline

An alternative, simpler, solution:

• Enable all the fonts in sdkconfig.defaults by default. Unused fonts will be eliminated at link time, since IDF build system uses -ffunction-sections -fdata-sections -Wl,--gc-sections options.

cc @kisvegabor @espzav

[espzav]

As I remember right, I mentioned this problem in e-mail discussion some months ago.

[kisvegabor]

Hi,

I was about writing you about a related topic, so it's great that you have opened this discussion.

I think we should discuss this topic in a more generic way: How to how to add custom options to the slb file and how to export config options in a custom way?

My idea is that we can add a custom_options and a custom_tags section to the slb file which would look like this:

{
  {
	"custom_options": [{
		"name": "Display type",
		"description": "This board is available with multiple displays. Select the version you have",
		"options": [{
				"name": "Display 1",
				"description": "320x240, 3.2 inch, 16 bit display",
				"tag": "__UI_ESP_BOARD_DISPLAY_TYPE_1__"
			},
			{
				"name": "Display 2",
				"description": "800x480, 5 inch, 16 bit display",
				"tag": ["__UI_ESP_BOARD_DISPLAY_TYPE_2__", "__UI_ESP_LARGE_DISPLAY__"],
				"width": 800
			}
		]
	}],
	"custom_tags": [{
			"file": "path/to/sdkconfig",
			"tag": "__LV_FONT_MONTSERRAT_10__",
			"value_if_true": "CONFIG_LV_FONT_MONTSERRAT_10=y",
			"value_if_false": "CONFIG_LV_FONT_MONTSERRAT_10=n"
		},
		{
			"file": "path/to/file",
			"tag": "__UI_ESP_BOARD_DISPLAY_TYPE_1__",
			"value_if_true": "CONFIG_DISPLAY_TYPE_800_480=y"
		}
	]
}

This what happens:

• In custom_options we create a new selector to select the display type. It will be shown in the Project settings of SLS. In this case the drop down will have two options: "Display 1" and "Display 2".
• If you select an option the related tags will be true the tags of t the other options will be false.
• You can also overwrite values from the slb file. (e.g. "width": 800 in case of "Display 2")
• In the custom_tags section you can specify how to export the tags. Here you can tell how to replace a tag if it's true or if it's false
• You can also add custom representation for the build in tags. (e.g. __LV_FONT_MONTSERRAT_10__).

What do you think?

[espzav]

Hi @kisvegabor,
that looks good. It will be nice feature to add select for user options. But as I see, there must be all font options from configuration. And then the SquareLine Studio will select only these fonts, which are used in project?

[kisvegabor]

And then the SquareLine Studio will select only these fonts, which are used in project?

Yes, but something just came to my mind. Normally we replace the "tags" when a new project is exported. However the list of used fonts can change after the project is exported too. So the font related tags needs to replaced on "UI file export" too. However if the tags are replaced with their final value, they can't be replaced again. E.g. when
__LV_FONT_MONTSERRAT_10__
is replaced by
CONFIG_LV_FONT_MONTSERRAT=y
we cannot replace
__LV_FONT_MONTSERRAT_10__
again, as it's already not there.

So it means there are some "dynamic data" which needs to be recreated and replaced again and again on UI file export. The recreate these dynamic tags we can add a special markup in the files. For example:

#__UI_DYNAMIC_DATA_START__
delete the content here on export, add the dynamic tags (e.g. fonts), and replace them
#__UI_DYNAMIC_DATA_END__

What do you think?

[espzav]

That's good point that there must be some mechanism to replacing exported data.
Your solution sounds good. The easier way is to regenerate again all files when "Export UI files" selected. Your solution is better, when user change something in these files. Then, as I understand right, you re-write only the selected part, do you?

[igrr]

Do note that modifying sdkconfig.defaults after sdkconfig has been already generated has no effect: the build system will not generate sdkconfig again unless it is deleted.

[kisvegabor]

Do note that modifying sdkconfig.defaults after sdkconfig has been already generated has no effect: the build system will not generate sdkconfig again unless it is deleted.

In this case we can de two things:

1. Call a custom script on UI files export which can trigger sdkconfig rebuild: it's a generic solution but harder to implement for the vendors. E.g. how to run that script on any OS?
2. Always use all fonts and let the build system eliminate them if they are unused: we can add an option to SLB file to whether automatically adjust the font usage in lv_conf.h or leave them as they are. We cannot decide if a font was enabled manually or automatically so automatic changes will overwrite user settings. However in lv_conf.h the user can add some #undef LV_FONT_.... #define LV_FONT_.... 1 trick to manually enabled fonts. As we cannot do the same in sdkconfig the fonts cannot be enabled automatically there.

I vote for 2) because calling the script might cause more issues than it resolves. And it seems the "dynamic data" problem is limited to the fonts so there is no reason to introduce a more complex and generic solution.

[tore-espressif]

@kisvegabor I'm sorry for the naive question but:

Could the whole mechanism of adding fonts to an application be reworked according to your point 2? That is: there are no options in lv_conf.h about enabled fonts. All fonts are enabled by default and the linker will eliminate the unused fonts.

[kisvegabor]

Could the whole mechanism of adding fonts to an application be reworked according to your point 2? That is: there are no options in lv_conf.h about enabled fonts. All fonts are enabled by default and the linker will eliminate the unused fonts.

I think it would be the simpler case and we do it even with the current SLS.