kando-menu
Adding support of exporting/importing menus
Features to be added:
- [x] Add structure checks (if error, show this error in error window and cancel menu import)
- [x] Add metadata fields (supported versions, etc.)
- [ ] Check if icon theme is present in the icon themes folder (if not, give a warning)
- [ ] Confirmation/warning/error windows
Thanks for the initiative! However, as written on Discord, there are a few things to consider here.
- Why do you want to put this into a zip? I think a JSON file is much more trustworthy. In a zip can be anything.
- Most of the time, people will want to export or import single menus. How would you do this?,
- What happens to my menus when I import something new? Are they overridden?
I think we actually want to support exporting and importing individual menus.
Yes, I will add export buttons for menus, and of course, I will make it use json instead of zip
I think we could add some confirmation boxes because you can entirely delete your menus if the JSON is corrupted or if there are no menus (Its optional)
Okay, so I will add structure checks and metadata fields to check that the menu is compatible with previous versions. Also, I will show warnings if the structure is correct, but the version is newer than entered in the metadata field
Also, we need to check if the required icon theme is present. If not show warning window
I added test error and warning windows with a built-in Electron window. In the future, I recommend adding them as part of the UI, as I'm unsure if it's compatible with macOS/Linux. Also, I have a problem with how to get available icon themes in my structure check, because for now IconThemeRegistry.getInstance().getThemes().has(item.iconTheme) always returns false, because IconThemeRegistry.getInstance().getThemes() is always empty (it's not initialized).
@yar2000T Please let me know when ready for review :)
@LitoMore, I'm ready
Thanks a lot, @LitoMore ! 🙌 Your review helped identify four great improvements — really appreciate your attention to detail and clarity. Much better now thanks to your input!
Yeah, I will. But most likely not before in two weeks as I'm currently traveling...
Yeah, I will. But most likely not before in two weeks as I'm currently traveling...
Yes, of course. No problems
Thanks for looking into this!
I think my main concern is that we now have a lot of duplicated code to maintain:
- The structure of the settings is defined somewhere.
- The default values are defined somewhere else.
- Now there is a schema which defines the same structure again, even in yet another place.
Currently, the config.json is not really validated for errors, menus.json is neither. With your PR, at least menus.json is partially validated. But why not use the same code to validate it when the app is started?
I think the proper way to handle this would be to define all our user-facing types using a lib like zod and use this to define the defaults and perform the validation in one place.
However, I think this is too much for this PR. So I think we should do this first in a separate PR.
I added an issue for that: https://github.com/kando-menu/kando/issues/1074. Anybody wants to look into that?
I can help. I'm familiar with the source code of zod.
I started now a similar endeavor in feature/backup-and-restore based on the zod validation. This is now only for backing up the menus.json and config.json and not yet for exporting individual menus which is actually something different, I think.
Maybe we should merge that branch and then create a new one for the missing menu export / import functionality?