Customization Menu stuck on "No control(s) defined" after defining controls in LivelyProperties.json

[NutchapolSal]

Describe the bug
While development, it is possible to remove all properties from LivelyProperties.json, then later putting new ones in afterward.

Currently "Restore Defaults" makes Lively read from LivelyProperties.json, so it also works as a "Refresh Properties" while developing a wallpaper.

However, if you press the "Restore Defaults" button to make Lively pickup new changes from the file, it could read the empty file and remove the "Restore Defaults" button, causing there to be no way to make Lively to pick up later changes.

To Reproduce
Steps to reproduce the behavior:

1. Open a wallpaper's LivelyProperties.json and remove all properties (entire file contains only {})
2. Go to wallpaper's Customize > press Restore Defaults
3. Add any property back into LivelyProperties.json
4. See that there's no way to make Lively refresh the list of properties in Customize

Expected behavior
Have a way for Lively to read properties from LivelyProperties.json when no properties are defined. I would prefer having it be automatically run on setting as wallpaper.

Implementation notes: If it's done by using current "Restore Defaults" then this functionality should not run when there are properties, as users would lose their settings, and "Refreshing Properties" could be done with the "Restore Defaults" button manually anyways. Or consider making it possible to merge current user settings with new properties definitions

Desktop (please complete the following information):

• OS: Windows 11
• Lively: v2108
• Custom web wallpaper

[rocksdanister]

However, if you press the "Restore Defaults" button to make Lively pickup new changes from the file, it could read the empty file and remove the "Restore Defaults" button, causing there to be no way to make Lively to pick up later changes.

Funny but the code is working as intended since technically there is nothing to restore 😅.. Lively creates a copy of the original property file from the wallpaper folder for various screen arrangement and displays (per, span, duplicate..) and the original file is never edited directly; restore default simply copies the original file over to the copy.

The problem here is when designing the restore default feature was made with users in mind and not wallpaper developers, I'll just change it to show the Restore button always.

[NutchapolSal]

The problem here is when designing the restore default feature was made with users in mind and not wallpaper developers

I got that, although if considering in-place wallpaper upgrades (possibly from gallery in the future or now with external tools etc.) and there's new properties from none, this bug would also appear for the end user.

I think the best way is to handle merging new properties and user settings, so you can have both not displaying the Restore Defaults button and Lively updating properties