Note that this will also require translation changes in Transifex for the key
"A fee higher than %1 is considered an insanely high fee." which is now
"A fee higher than %1 is considered an absurdly high fee."
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
- this is based on #4122 (which can be closed)
Currently a payment request is only checked for expiration upon receipt.
It should be checked again immediately before sending coins to prevent
the user from paying to an expired invoice which would then require a
customer service interaction.
- add static verifyExpired() function to PaymentServer to be able to use
the same validation code in GUI and unit-testing code
- extend unit tests to use that function and also add an unit test which
overflows, because payment requests allow expires as uint64, whereas we
use int64_t for verification of expired payment requests
Move transaction new/update notification to TransactionTableModel.
This moves the concerns to where they're actually handled.
No need to bounce this through wallet model.
- Do wallet transaction preprocessing on signal handler side;
avoids locking cs_main/cs_wallet on notification in GUI thread
(except for new transactions)
Thanks to Pieter Wuille for most of the work on this commit.
I did not fixup the overhaul commit, because a rebase conflicted
with "remove fields of ser_streamplaceholder".
I prefer not to risk making a mistake while resolving it.
The implementation of each class' serialization/deserialization is no longer
passed within a macro. The implementation now lies within a template of form:
template <typename T, typename Stream, typename Operation>
inline static size_t SerializationOp(T thisPtr, Stream& s, Operation ser_action, int nType, int nVersion) {
size_t nSerSize = 0;
/* CODE */
return nSerSize;
}
In cases when codepath should depend on whether or not we are just deserializing
(old fGetSize, fWrite, fRead flags) an additional clause can be used:
bool fRead = boost::is_same<Operation, CSerActionUnserialize>();
The IMPLEMENT_SERIALIZE macro will now be a freestanding clause added within
class' body (similiar to Qt's Q_OBJECT) to implement GetSerializeSize,
Serialize and Unserialize. These are now wrappers around
the "SerializationOp" template.
This number was still tracked even though it's shown nowhere in the UI
anymore. It was originally removed because it didn't match the actual number of
records in the view (which contains outputs, not transactions) thus was
confusing people.
contrib/devtools/fix-copyright-headers.py script to be able to perform this maintenance task with ease during the rest of the year, every year. Modifications to contrib/devtools/README.md to document what fix-copyright-headers.py does.
- rebuilt some ui file layout to remove unreal values from the files
- remove an unneeded attribute from an ui file
- add / remove some spaces in files
Keep a list of requested payments in the Receive tab so that a user can
recall previously created requests after closing their windows.
Currently this list is not stored between bitcoin-qt sessions. This can
be implemented later, but it is not clear where it should be stored as
I don't think it belongs in the wallet (maybe in QSettings?)
- add missing license headers
- make compatible with Qt5
- enforce header cleanup style
- small code style cleanups
- rename Coin Control dialog into Coin Control Address Selection
- use default font for the windows labels (no monospace)
Use misc methods of avoiding unnecesary header includes.
Replace int typedefs with int##_t from stdint.h.
Replace PRI64[xdu] with PRI[xdu]64 from inttypes.h.
Normalize QT_VERSION ifs where possible.
Resolve some indirect dependencies as direct ones.
Remove extern declarations from .cpp files.
395d0d5 rework an ugly hack in processPaymentRequest() (Philip Kaufmann)
952d2cd make processPaymentRequest() use a single SendCoinsRecipient (Philip Kaufmann)
983cef4 payment-request UI: use SendCoinsRecipient.message for memo (Philip Kaufmann)
c6c97e0 [Qt] Rework of payment request UI (mainly for insecure pr) (Philip Kaufmann)
- this shows insecure (unsecured) payment requests in a new yellowish
colored UI (based on the secure payment request UI) instead of our
normal payment UI
- allows us to receive paymentACK messages for insecure payment requests
- allows us to handle expirations for insecure payment request
- changed walletmodel, so that all types of payment requests don't touch
the addressbook
Also update URI parsing to fill in this field.
Note that the message is not currently used in any way with the client.
It should be stored with the transaction.
Correctly use the purpose of addresses that are added after the start
of the client. Addresses with purpose "refund" and "change" should not
be visible in the GUI. This is now handled correctly.
Add support for a Payment Protocol to Bitcoin-Qt.
Payment messages are protocol-buffer encoded and communicated over
http(s), so this adds a dependency on the Google protocol buffer
library, and requires Qt with OpenSSL support.
- try to enforce the same style to all Qt related files
- remove unneeded includes from the files
- add missing Q_OBJECT, QT_BEGIN_NAMESPACE / QT_END_NAMESPACE
- prepares for a pull-req to include Qt5 compatibility
- fix ThreadSafeMessageBox always displays error icon
- allow to specify MSG_ERROR / MSG_WARNING or MSG_INFORMATION without a
custom caption / title
- allow to specify CClientUIInterface::ICON_ERROR / ICON_WARNING and
ICON_INFORMATION (which is default) as message box icon
- remove CClientUIInterface::OK from ThreadSafeMessageBox-calls, as
the OK button will be set as default, if none is specified
- prepend "Bitcoin - " to used captions
- rename BitcoinGUI::error() -> BitcoinGUI::message() and add function
documentation
- change all style parameters and enum flags to unsigned
- update code to use that new API
- update Client- and WalletModel to use new BitcoinGUI::message() and
rename the classes error() method into message()
- include the possibility to supply the wanted icon for messages from
Client- and WalletModel via "style" parameter
This adds a field labelled 'Immature' in the overview section under the 'unconfirmed' field, which shows mined
income that has not yet matured (which is currently not displayed anywhere, even though the transactions
exist in the transaction list). To do that I added a 'GetImmatureBalance' method to the wallet, and connected
that through to the GUI as per the 'GetBalance' and 'GetUnconfirmedBalance' methods. I did a small 'no-op'
change to make the code in adjacent functions a little more readable (imo); it was a change I had made in my
repo earlier...but I thought it wouldn't hurt so left it in. Immature balance comes from mined income that is
at least two blocks deep in the chain (same logic as displayed transactions).
My reasoning is:
- as a miner, it's a critical stat I want to see
- as a miner, and taking into account the label 'immature', the uncertainty is pretty clearly implied
- those numbers are already displayed in the transaction list
- this makes the overview numbers add up to what's in the transaction list
- it's not displayed if the immature balance is 0, so won't bother non-miners
I also 'cleaned' the overview UI a little, moving code to the XML and removing HTML.
