Currently only the name of the option is shown for GUI options
overridden by command line (or configuration file). This commit
adds the value of the options as well, which is useful for
troubleshooting.
This shows the minimum relay fee for non-free transactions in btc/kb.
The armory developers requested this so that they can prevent users from
creating transactions that not even their local bitcoind will relay.
This also slightly reorders the getinfo output so that the fee related
lines are grouped and changes the help text to reflect that the units
are btc/kb.
Changes for the datadir chooser have made it impossible to specify
the network (testnet/regtest) in the configuration file for the GUI.
Reorganize the initialization sequence to make this possible again.
- Moves the "datadir" QSetting so that is no longer dependent on the
network-specific application name (doing otherwise would create a
chicken-and-egg problem).
- Re-initialize translations after choosing network. There may be a
different language configured in network-specific settings
(slim chance, but handle it for sanity).
Fixes point 1 of #3840.
This resolves a case in which a mismatch could be used to bloat up the
mempool by sending transactions that pay enough fee to relay, but not
to be mined, with the default policies.
Last Transifex pull (064a690) introduced a few control characters
into the Korean translation, which sometimes causes the build to fail.
Manually remove these characters for now to get the build working --
they should still be removed at Transifex too.
After the Qt5 switch, status icons were being cut off by 1-2px.
Also fixes some other cases where the UI is slightly off mentioned in #3800.
Fixes#3800.
When bitcoind can't bind, bitcoin server (or Bitcoin Core Daemon) is probably already running. Add the missing word "server". Bitcoin itself is definitely running ;-)
Add _(...) so the string can be localized.
I apologize for such trivial changes, learning github interface.
These days we regard transactions with one confirmation to be
'Confirmed'.
Waiting for 6 confirmations is a recommendation but should not
keep the transaction shown as unconfirmed.
Misc code sanity:
- Merge maturity/status enums, they had become completely disjunct
- 'confirmed' flag is now called 'countsForBalance' for clarity
By default tinyformat errors such as 'wrong number of conversion
specifiers in format string' cause an assertion failure.
Raise an exception instead so that error handling can recover or can
show an appropriate error.
Just a pet peeve.
(PrintException has exactly the same body as PrintExceptionContinue but
does a re-throw at the end. Move these re-throws to the call
site, this aids understanding what is going on as well as eliminates a
bit of code duplication in util.cpp)
This was a bad idea. This can't be solved with macros as any
other library that includes inttypes.h will get in the way.
The parent commit has removed all usages from the source, this commit
removes the definition.
Amend to d5f1e72. It turns out that BerkelyDB was including inttypes.h
indirectly, so we cannot fix this with just macros.
Trivial commit: apply the following script to all .cpp and .h files:
# Middle
sed -i 's/"PRIx64"/x/g' "$1"
sed -i 's/"PRIu64"/u/g' "$1"
sed -i 's/"PRId64"/d/g' "$1"
# Initial
sed -i 's/PRIx64"/"x/g' "$1"
sed -i 's/PRIu64"/"u/g' "$1"
sed -i 's/PRId64"/"d/g' "$1"
# Trailing
sed -i 's/"PRIx64/x"/g' "$1"
sed -i 's/"PRIu64/u"/g' "$1"
sed -i 's/"PRId64/d"/g' "$1"
After this commit, `git grep` for PRI.64 should turn up nothing except
the defines in util.h.
As the tinyformat-based formatting system (introduced in b77dfdc) is
type-safe, no special format characters are needed to specify sizes.
Tinyformat can support (ignore) the C99 prefixes such as "ll" but
chokes on MSVC's inttypes.h defines prefixes such as "I64X". So don't
include inttypes.h and define our own for compatibility.
(an alternative would be to sweep the entire codebase using sed -i to
get rid of the size specifiers but this has less diff impact)
We were losing information about sent/received by overriding the
category in case of a conflicted transaction.
Hence, remove the "conflicted" category.
Conflicted status of a transaction can still be determined by looking
for confirmations<0.
Cozz Lovan