-
Notifications
You must be signed in to change notification settings - Fork 141
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update ChromeToBrave.py script to include Sparkle update keys #344
Conversation
Converted spaces to tabs because that's what the manifests are formatted ... just for consistency.
Since we have preferences that are going to live in different segment sections, this will make it easier for long-term use
- With changes to Brave domain specific plist formatting, add any key segments (ex. Updates) from the domain file not already present in chrome_segment_titles - Also ensure that these missing key segments have an array for preferences to live - Append the pfm_name for each preference to the appropriate segment array - Append the preference dictionaries to the root pfm_subkeys
@relgit this is now working as expected! Proved to be more challenging to wrap my brain around, but it works to recursively take any preferences given the updated domain specific .plist format (to include the segment title since we don't want to assume these preferences are all going to dump into 'Misc.') and add the key name and preference dictionary in the necessary locations. The one thing this doesn't do at the moment but would like it to is to not add a preference from the domain specific plist if it already exists in the Chrome manifest. For example, if a preference's pfm_name in the brave specific plist already exists in Let me know what you think and if anything can be improved. |
@relgit not trying to bother if you're busy, just proud that I was able to figure this out on my own :). Whenever you have time to review so I can merge this, 👍 |
Thanks for waiting @apizz. Looking good. I'd argue that if a preference key is both in the Chrome and the Brave-specific manifests, then the Brave-specific should prevail. This would allow us to add rudimentary modifications to existing Chrome keys if necessary. So basically as far as I'm concerned you're good to move ahead and merge. |
Awesome, thank you @relgit ! I'm starting to work on a ChromeToEdge PR as well, but is a bit different since there are a number of chrome prefs edge doesn't use as well as prefs edge has that chrome doesn't. Hoping to get your help on that once I PR it. |
Ooof I haven't looked at this in a while. I'm going to get this committed since it is in a working state. |
Still a work in progress, and need feedback given my limited Python skills ...
Previously, we just had an array of dictionaries with preferences that were all appended to the bottom of the manifest and appended to the 'Misc.' menu segment. Given the addition of other preferences that we do not want to have fall under 'Misc.', my thought is in order to better handle additional Brave-specific preferences moving forward is two-fold:
Right now, the segment key is being written as needed, but the preferences themselves are not (below). On that front, @relgit I could use some help 😄
Closes #342