Scenarios where active livestreams will not appear:
- creation date is way back.
- homepage section options excludes livestreams.
Make an explicit `claim_search` but with `has_no_source` if the client wants `liveLivestreamsFirst`.
If there are lots of channels with livestreams, there's a possibility that the final list will be larger than what was requested. We could trim it to be within the original `options.pageSize` range, but I left that out for now.
It would have been a clean implementation through `renderProperties`, but due to the need to adjust the opacity of `claim-preview__file-property-overlay` (the parent elemtn), I ended up having to create a new `live` attribute.
## Issue
One of the items in 5865 Video shortcut issues
This one is not really an issue, but it would be nice to match what the arrow keys are doing. Also, in slower regions, seeking 10s will almost always end up buffering.
## Issue
Channel links were showing the "This channel isn't staking enough LBRY Credits for link previews." -- channel links shouldn't be showing previews in the first place.
## Change
Moved the logic into `ClaimLink`, which is the better place to put it anyway. I think I was trying to not touch as many components as possible (i.e. not passing `allowPreview` down too many layers) in the initial implementation. This caused the `isChannel` consideration to be missed.
These only work in the `selectThumbnail` component. If it's small enough, it'll get past the transaction limit-check, but ultimately it doesn't appear correctly in the claim list.
It'll probably appear correctly if we tweak the ClaimPreview code, but since this also fails the Google Video metadata test, I think we should disallow this.
## Issue
5923
Thumbnail errors were just being used in `selectThumbnail`. The form doesn't know about it and was using allowing invalid thumbnails like 'helloworld' to pass through.
I believe the rest of the GUI is setting 'thumbnail'.
'thumbnail_url' is only populated right before publishing.
So, the flag was always false -- we just never see the error on screen because the component is incorrectly hidden (fix for this is coming up next...)
* FileExporter: add 'fetch' hook + Web support
* Re-add ability to export transactions
Closes 4793: Export Wallet History For Taxation Purposes
* Move file-creation to the background.
Don't let the file-creation process block the GUI.
Requires lbry-redux update.
* Bump redux | doFetchTransactions: bump pageSize to 999999; remove doFetchSupport
* bump redux
Co-authored-by: Thomas Zarebczan <thomas.zarebczan@gmail.com>
* CopyableText: add 'onCopy' for clients to change the text-selection
* Swap: only copy the amount (without currency)
## Issue
5873: Rounds 2 of LBC swaps
## Notes
It was an intended feature to include the currency -- I can paste the full string into my note book, while pasting into wallet apps like Exodus will automatically trim off the currency anyway.
Regardless, removed the 'feature' :D
- For the active swap, switch from polling to websocket. The returned data is now the Charge data from the commerce, so some parsing will be required.
- Allow the user to send other coins that the commerce supports.
- Only save the 'chargeCode' to the wallet. The other data can be repopulated from this.
- Store the receipt currency. I'm not sure if the commerce supports sending bits from various coins. Take the coin that came with the 'COMPLETED' message for now.
- Fix 'lbc' calculation to match IAPI side.
- Allow users to see full detauls from "View Past Swaps".
- String cleanup
- GUI cleanup.
While it would be nice if we can swap anonymously through Desktop, the IAPI will tie a wallet address with an account. Final decision is to require authentication.
- Users should be able to see the entered and promised amount, otherwise they might forget how much to send over.
- This change also prepares for the future upgrade to support multiple coins.
## Issue
- Patch for 5316: "Home and End keys not working in search box"
## Notes
Seems like 'shift+home' wasn't highlighting the text. 'shift+end' works.
Was pretty sure I tested that previously. Anyway, adding the direction variable seems to fix it.
- The icon makes the screen too busy when there are lots of images in a page.
- Use src as the last resort for the text (I though `title` and `alt` was mandatory in markdown; apparently not).
## Issue
4945: Simplify / revamp search filters for odysee (and lbry.tv)
## Changes
- Tweaked the "claim type = file | channel | everything" a little to hopefully make it more intuitive.
- Added "Sort By".
- Added "Upload Date".
- Fixed the affected files to handle both Desktop and Odysee.
- Tweaked the layout to be more condensed so that we can see some results as we change the filter.
- Added animations.
- Added "Exact match" option that helps user to surround with quotes.
## Issue
- Redo 5636: Disable video previews in comments/posts made by channels below a certain channel staked level
- Closes 5738: expand video preview level requierment to markdown images also
I think using the 'values' for the keys should be fine since each language name is unique. A key-clash would also help us catch mistakes like not differentiating sub-languages if support any (e.g. "English" vs. "English (British)")
Had to cast to String for lint.
- SUPPORTED_SUB_LANGUAGE_CODES[] that I introduced was pretty redundant when SUPPORTED_LANGUAGES[] already hold the information. The logic to ignore sub-languages (i.e. reduce the locale's "en-GB" to "en" is now located in getDefaultLanguage()).
- SUPPORTED_BROWSER_LANGUAGES[] and SUPPORTED_LANGUAGES[] look so similar and hard to tell what the former is for at first glance. The functionality to map 'zh-CN' to 'zh-Hans' is now handled by resolveLanguageAlias(), which makes the intention clearer.
This leaves us with a single list -- SUPPORTED_LANGUAGES[], whose key also tells us the desired language code to use.
Also, clients now need to call `resolveLanguageAlias` to map any language code aliases, as they differ depending on how it is queried (e.g. `navigator.language` vs. `app.getLocal()` uses different standards).
I think we no longer need to explicitly migrate existing user's 'zh-CN' into 'zh-Hans' because the rest of the system will always use the desired language code as long as 'resolveLanguageAlias' is called appropriately. e.g. the system uses `selectLanguage` and `selectLanguage` calls `resolveLanguageAlias`.
