Uses a more finegrained method of deciding whether or not to adjust the brand color: Instead of simply using the brightness of the color, we calculate the contrast ratio and adjust the color by increasing the contrast until it is sufficient.
The thresholds also try to preserve the brand color in its original form, so that the color only gets adjusted if the contrast is very low.
* Histograms: Add Lightning data and API endpoints
Ported over from the mobile-working-branch.
Adds histogram data for Lightning and exposes the wallet/lightning histogram data via the API. It also add a dashboard graph for the Lightning balance.
Caveat: The Lightning histogram is calculated by using the current channel balance and going backwards through as much invoices and transactions as we have. The "start" of the LN graph data might not be accurate though. That's because we don't track (and not even have) the LN onchain data. It is calculated by using the current channel balance and going backwards through as much invoices and transactions as we have. So the historic graph data for LN is basically a best effort of trying to reconstruct it with what we have: The LN channel transactions.
* More timeframes
* Refactoring: Remove redundant WalletHistogram types
* Remove store property from dashboard tile view models
* JS error fixes
Does the same, but the `GetPayment` call explicitly wants a payment
hash, which is clearer this way (thought there might be a bug here when
I first read the code)
* Refactoring: Move AppItem to Client lib and use the class for item list
This makes it available for the app, which would otherwise have to replicate the model. Also uses the proper class for the item/perk list of the app models.
* Remove unused app item payment methods property
* Do not ignore nullable values in JSON
* Revert to use Newtonsoft types
make sure link provider is per payment method of liquid assets. Also remove ETB as it has been unused. Also hide the send button as it is not supported thrrough BTCPay
* refactor: make `BitcoinCheckoutModelExtension` support other payment handlers
The bitcoin checkout extension doesn't have to be tied to the native
bitcoin handler since it only really needs the payment details to be in
a specific format, which can be provided by other handlers aswell,
allowing for better code reuse.
* refactor: initialize payment methods in constructor
* Store selector
* Footer
* Notifications
* Checkout Appearance
* Users list
* Forms
* Emails
* Pay Button
* Edit Dictionary
* Remove newlines, fix typos
* Forms
* Pull payments and payouts
* Various pages
* Use local docs link
* Fix
* Even more translations
* Fixes#6325
* Account pages
* Notifications
* Placeholders
* Various pages and components
* Add more
