* Allow webpack to bundle *most* dependencies
* Exclude *most* node_modules from getting packaged by electron-builder
* Import only the required icons instead of bundling the whole icon pack
* Reduce packaging blacklist to only include the few things that still need blacklisting
* start to implement some parental controls
* Hide share + Hide Unsubscribe
* Hide live streams
* fix hide live streams
* Add "parental-control-settings"
* Implement Hide Live Streams & Hide "Age Restricted"
* Hide live streams from Subscriptions + fix hide live streams from search
* enable safe search on showFamilyFriendlyOnly
* Move some settings from parental control to distraction free
* fix channel loading
* make parental control settings collapsible
* fix lint
* dont show age restricted on videos that are loading
* improve hide live videos
* code refactor
* grammar
* nvm im dumb
* use named placeholder for age restricted message
* improve readability
* change Hide Description to Hide Video Description
* update translated strings
* fix age restricted component
Co-authored-by: Preston <freetubeapp@protonmail.com>
Co-authored-by: peepopoggers <72892531+peepopoggers@users.noreply.github.com>
* History: Refactor history module
* Profiles: Refactor profiles module
* IPC: Move channel ids to their own file and make them constants
* IPC: Replace single sync channel for one channel per sync type
* Everywhere: Replace default profile id magic strings with constant ref
* Profiles: Refactor `activeProfile` property from store
This commit makes it so that `activeProfile`'s getter returns
the entire profile, while the related update function only needs
the profile id (instead of the previously used array index)
to change the currently active profile.
This change was made due to inconsistency regarding the active profile
when creating new profiles.
If a new profile coincidentally landed in the current active profile's
array index after sorting, the app would mistakenly change to it
without any action from the user apart from the profile's creation.
Turning the profile id into the selector instead solves this issue.
* Revert "Store: Implement history synchronization between windows"
This reverts commit 99b61e6178.
This is necessary for an upcoming improved implementation of the
history synchronization.
* History: Remove unused mutation
* Everywhere: Create abstract database handlers
The project now utilizes abstract handlers to fetch, modify
or otherwise manipulate data from the database.
This facilitates 3 aspects of the app, in addition of
making them future proof:
- Switching database libraries is now trivial
Since most of the app utilizes the abstract handlers, it's incredibly
easily to change to a different DB library.
Hypothetically, all that would need to be done is to simply replace the
the file containing the base handlers, while the rest of the app
would go unchanged.
- Syncing logic between Electron and web is now properly separated
There are now two distinct DB handling APIs: the Electron one and
the web one.
The app doesn't need to manually choose the API, because it's detected
which platform is being utilized on import.
- All Electron windows now share the same database instance
This provides a single source of truth, improving consistency
regarding data manipulation and windows synchronization.
As a sidenote, syncing implementation has been left as is
(web unimplemented; Electron only syncs settings, remaining
datastore syncing will be implemented in the upcoming commits).
* Electron/History: Implement history synchronization
* Profiles: Implement suplementary profile creation logic
* ft-profile-edit: Small fix on profile name missing display
* Electron/Profiles: Implement profile synchronization
* Electron/Playlists: Implement playlist synchronization
* Makes reload buttons' position fixed
* Changes reload buttons' positions to absolute on narrow enough screens
Co-authored-by: Preston <freetubeapp@protonmail.com>
There are now two separate settings related to Invidious instances:
- currentInvidiousInstance
- defaultInvidiousInstance
'currentInvidiousInstance' is a value that exists solely in memory
and it's the value used by the app to make the API calls,
while 'defaultInvidiousInstance' is the value that can be persisted
in the database by user action and will be used to initiate
the 'currentInvidiousInstance' on startup.
If the user has not saved a default value to the database,
'currentInvidiousInstance' is randomized from
a fetched list of viable candidates.
absidue
ChunkyProgrammer
Svallinn
Jason
Preston
Luca