The primary keys shouldn't be editable from the recovery path in the
Multisig Savings template but only from the primary path. It could bring
to weird behaviors and corner cases.
1bc6248063c908219d4f1e343ca487c4f64d7843 gui: upgrade managed bitcoind version to 28.0 (Michael Mallan)
Pull request description:
This is to resolve#1372.
Hashes were taken from https://bitcoincore.org/bin/bitcoin-core-28.0/SHA256SUMS.
File names we use can be found here:
2d5991cb0c/gui/src/node/bitcoind.rs (L42-L60)
ACKs for top commit:
edouardparis:
utACK 1bc6248063c908219d4f1e343ca487c4f64d7843
Tree-SHA512: c6c5976c357164dc2f6e31f5af7981c41ef63197bfb1aac1f54ddb30dff423796fe23957e5a2c6014fcdabb64b91057a97b22d3c9e7ea33bcfa5ce47c912846a
If opening an existing wallet that uses a local backend, indicate
that it is checking for new transactions until the first poll
completes.
A remote backend is always synced after the initial scan.
If the user has imported a descriptor and is using bitcoind as
a local node, then they will need to perform a rescan in order
to see past transactions.
Treating the wallet as syncing in this case could mislead the
user that a rescan is being performed. Therefore, it's better
to keep the past behaviour here to avoid further confusion.
This is for convenience in case we need to know the node type
being used.
Although we expect there to always be a node type, it is kept as
`Option` to be consistent with the daemon config.
6f4eb79a5a45751a1c919565ea9c88f59fbda0ab gui: refresh cache more often while height is 0 (Michael Mallan)
a51110269c96e7a9d7c4143e0bd6f8cf27a703a3 gui(home): indicate that wallet is syncing (Michael Mallan)
b452966653da1f2d857dd5901972171aa9d1250c gui(home): track blockheight from cache (Michael Mallan)
1d1e735ae975bb73af5389090e1eee68c727c7ea ui: add loading spinner that types text (Michael Mallan)
3c46a7337c57ef646626d052a0ab23a7fa0ecb17 ui: add carousel loading spinner (Michael Mallan)
e4c1ab106d74ad193aa1ba2f5746ce598c4801e5 ui: render amount with chosen colors (Michael Mallan)
013feb3909ebed0a8850a51a7d61383f327b5d4d ui: refactor amount function (Michael Mallan)
Pull request description:
This is to resolve#1361.
The home page considers the wallet to be syncing if its height is 0. In this case, the balance will slowly blink and a "Syncing..." text will appear just below.
The home page will check the wallet's height upon each cache refresh, and will reload the home page once the syncing has completed so that the updated balance is displayed without the user needing to do anything.
Both the blinking balance and "Syncing..." text use a new `Carousel` widget that cycles through different child widgets at a specified rate.
EDIT: I've added an extra commit to address #1363 as that is also related to the wallet height and cache refresh.
ACKs for top commit:
edouardparis:
ACK 6f4eb79a5a45751a1c919565ea9c88f59fbda0ab
Tree-SHA512: 04214ccb1cf998ae6f7589f2c37335416a6d39b668269c4e07e30c8713e1a0e9e46257c60cea7b19ee6d6e35cbdccaf1122d25a66e6e7e905de51fce185f9180
The secondary button is light grey border and transparent
background that has border and text green on hover.
It brings consistency with item list selection that
has green border on hover.
The wallet's height is taken from the cache and is used to check
if the wallet has been initially synced after creation.
For the remote backend, the cache refresh should be done with the
usual frequency while the wallet's height is 0 so that the sync
completion can be detected sooner.
We check if we are able to fetch master fingerprint
to see if the bitcoin app is open. The error is then displayed
with the generic connection error message.
The problem:
We display the button if the size of the list is a multiple of the page
size. Otherwise, we assume that the user has reached a partial page,
indicating they've reached the bottom. However, since we chose to
include all transactions with the same block time on a single page
(because it's not possible to order them by block index in the database,
as we don't store the block index), this can cause the page size to
exceed the set limit. As a result, the list size may not be a multiple
of the page size.
The solution:
keep in the state if the last fetched page has a length inferior
of the expected page size and do not display the button 'See more'
then as we reached the bottom.
