Add import/export settings buttons

[Shadorc]

Pull Request Type

• Bugfix
• Feature Implementation
• Documentation
• Other

Related issue

#1018 (comment)
#7345

Description

This pull request adds support for importing and exporting FreeTube settings.

Some settings are not exportable, they are represented by the settingsNotTransferrable set inside settings.js. They are OS/user-specific settings, experimental settings, and settings that depend on process.env.

I'm not entirely satisfied with having to duplicate setting keys, but the other solution that I thought of was to replace the state object values with a more complex structure, having additional fields like isExportable. However, in my opinion, it would have required too much refactoring.

Screenshots

Testing

Basic test

1. Change some settings (a and b)
2. Export settings
3. Change some other settings (c and d)
4. Import settings
5. Check that a and b have the same values as step 2 and that changes made on c & d in steps 3 have been reverted

Non-exportable setting test

1. Changes value of proxy settings
2. Export settings
3. Revert change made on step 1
4. Import settings
5. Check that proxy settings are the same as step 3

UI test

1. Minimize the window to make it similar in size to a phone
2. Go to Settings > Data
3. Check that the title, tooltip button and import/export buttons are correctly displayed
4. Check that the tooltip bubble is not hidden by anything

[absidue]

absidue was warning that it could be an issue with some settings, but I didn't experience problems with the mentioned settings.

You won't see a warning, it will purposefully silently drop them because they are not meant to be writeable by the window and you won't see any issues in the same window because in the same window you are showing the stuff in-memory in that window but it won't be saved to disk, synced to other windows or actually get used.

While I don't want to discourage new contributors, could I please ask that you put a bit more thought into your pull requests or at the very least put more effort into testing them, as this is the second one that you have submitted that doesn't actually work in practice.

[Shadorc]

You're right, I'm sorry. I'm a bit too eager to contribute. I did test my changes, but I saw your warning about the folder fields a bit late, and I only tested the settings value after import rather than actually testing whether the folders were correct.
I'll put this MR as draft and see if I can fix it and test it properly. I'll either close it if I can't fix it properly or mark it as ready otherwise.
Sorry for wasting your time, I know that's not cool!

[Shadorc]

Maybe folder paths should not be allowed to be imported, does it really make sense? It is user and OS dependent, in most case the imported path would be invalid.
It could be an exception, with a little help icon indicating which settings (corresponding to paths) would not be part of the export / import process
What do you think?

[PikachuEXE]

What probably should not be transferred:

• OS specific like screenshot settings
  (at least path, not idea about others, related: Prompt for default screenshot folder when it is unset #8581)
• external player
• proxy
• experimental settings
• not sure about password...
• Any other?

[Shadorc]

I checked all the settings, I think that settings impacted by env like process.env.SUPPORTS_LOCAL_API and process.env.IS_ELECTRON should also be ignored. A custom logic for those settings could be implemented during import, but it's probably safer to not export them and it only concern one settings currently (if we consider that screenshotAskPath would be not exported anyway because it is a path).

Concerning passwords, they are not encrypted, so exporting them as plain text would not be an issue. As for whether this is relevant, I’d tend to say yes, but it could be changed if needed.

There are also settings that need the app to be restarted. I've made the implementation similar to the list of non-exportable settings for the declaration, and when they are imported, the user is prompted to restart the app or to revert the settings that needed a restart. It works but I will see if I find something more "elegant"

[Shadorc]

I'm now satisfied with the state of this MR!
I have updated my initial MR description accordingly.
I have also written and tested all the test cases that I could think of, they all pass.

[PikachuEXE]

Does this mean the prompt is shown for web build (even though not officially supported) and will do nothing?

[Shadorc]

I've asked myself the same question, but I've used the same template as everywhere else
https://github.com/FreeTubeApp/FreeTube/blob/development/src/renderer/components/ThemeSettings.vue#L317
https://github.com/FreeTubeApp/FreeTube/blob/development/src/renderer/components/ExperimentalSettings/ExperimentalSettings.vue#L68

[absidue]

@Shadorc The difference is that in the other places it will never even get to that code, the electron check is just there to ensure that the electron only code gets removed properly during the build (as deadcode removal isn't guaranteed with Vue in the mix) and makes it clearer to people reading the code that it is electron only.

E.g. for the smooth scrolling switch is not shown outside of electron: https://github.com/FreeTubeApp/FreeTube/blob/development/src/renderer/components/ThemeSettings.vue#L20 and the entire experimental settings component is Electron only: https://github.com/FreeTubeApp/FreeTube/blob/development/src/renderer/views/Settings/Settings.vue#L174-L181

So you can either make the entire settings import and export feature electron only or write it in a way that also has a non-Electron restart and flexible enough that an Android specific restart could be added in downstream FreeTubeAndroid.

[Shadorc]

Thanks for the clarification.
I had searched for settings depending on the IS_ELECTRON env var, but I missed disableSmoothScrolling and hideToTrayOnMinimize.

Concerning your suggestions, I see one more option.
Instead of making the entire feature electron-only, all electron-only settings could be marked as not transferrable.

It would not remove a lot of settings because, according to my searches, here are the settings depending on process.env:

/* Depends on process.env.IS_ELECTRON */
// ProxySettings
'useProxy',
'proxyProtocol',
'proxyHostname',
'proxyPort',
'proxyUsername',
'proxyPassword',
// ExternalPlayerSettings
'externalPlayer',
'externalPlayerExecutable',
'externalPlayerIgnoreWarnings',
'externalPlayerIgnoreDefaultArgs',
'externalPlayerCustomArgs',
'showAddedExternalPlayerCustomArgs',
// Others
'disableSmoothScrolling',
'hideToTrayOnMinimize',
'screenshotAskPath',
'screenshotFolderPath',

/* Depends on process.env.SUPPORTS_LOCAL_API */
'backendFallback',
'backendPreference',
'proxyVideos',

If we remove settings mentioned here, we get:

  /* Depends on process.env.IS_ELECTRON */
  // Others
  'disableSmoothScrolling',
  'hideToTrayOnMinimize',

  /* Depends on process.env.SUPPORTS_LOCAL_API */
  'backendFallback',
  'backendPreference',
  'proxyVideos',

The last three depend on process.env.SUPPORTS_LOCAL_API, they should probably not be transferrable.
hideToTrayOnMinimize is OS-specific because it is not available on macOS.
The remaining one is disableSmoothScrolling.

So, making the whole feature electron-only would only be useful to support the smooth scrolling feature but would prevent users from importing and exporting settings on mobile.
It could still be possible to later implement your idea of having a flexible way to restart the app, no matter if it's electron or not, and add the missing support for disableSmoothScrolling.

I will update my MR to change the settingsNotExportable with all the settings mentioned above.
Let me know what you think, I've tried to imagine the best scenario for users, code maintainability and complexity.