Age | Commit message (Collapse) | Author |
|
a80b1a0 [Qt] make event() and eventFilter() in askpassphrasedialog protected (Philip Kaufmann)
|
|
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)
|
|
|
|
[Qt] remove unused optionsmodel from addressbookpage
|
|
|
|
|
|
|
|
No more fHaveGUI
|
|
Closes #839
|
|
No more specific handling of GUI in bitcoin core.
Replace the last usage of fHaveGUI with a fForceServer
parameter on AppInit2.
|
|
- use a QStringList to store valid addresses and format them for GUI and
debug.log usage via .join()
|
|
- as one this pulls main purpose is to change a payment request to
be displayed as a single sendcoins entry
|
|
|
|
- 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
|
|
9eb4ab6 transactionview: make exportClicked() use message() (Philip Kaufmann)
868d3ee transactionview: add message() signal (Philip Kaufmann)
|
|
71ba467 [Qt] sendcoinsdialog: convert QMessageBox usage to message() (Philip Kaufmann)
|
|
re-work -debug switch handling
|
|
- add new processSendCoinsReturn() function, which parses the
status of WalletModel::SendCoinsReturn and generates a pair consisting
of a message and message flags
- result is we only need one emit message() call
- this change ensures that the GUI is shown for warnings/errors in
sendcoinsdialog, because of message() taking care of that for modal
messages
- changes 2 warning message into error messages and removed "Error:"
in front of the actual error message string
|
|
- use message() for displaying success or failure of export
- rework the strings to be more detailed / informative
- additional small cleanups
|
|
- allow to use message() in transactionview by connecting to the
message() signal in WalletView
|
|
[Qt] walletview: make backupWallet() use GUIUtil::getSaveFileName()
|
|
- re-work -debug help message text
- make -debug log every debugging information again (even all categories)
- remove unneeded fDebug checks in front of LogPrint()/qDebug(), as that
check is done in LogPrintf() when category is != NULL (true for all
LogPrint() calls
- remove fDebug ONLY in code which is NOT performance-critical
- harmonize addrman category name
- deprecate -debugnet usage, should be used via -debug=net and remove the
corresponding global
|
|
Interaction cleanups between main and wallet
|
|
Use a GridLayout instead of a FormLayout. This makes the alignment
of the labels consistent between the tabs.
|
|
|
|
- this allows removal of several Qt headers and makes use of a
standardized function in GUIUtil
- adds selected path to the UI output
|
|
GUIUtil: make getSaveFileName() use native OS path separators
|
|
|
|
[Qt] additional small fixes for #3099 (new receive flow)
|
|
Use proper signals everywhere.
Removes the need to store a pointer to the BitcoinGUI object in
the walletview.
Also removes the interdependence between setWalletModel / setBitcoinGUI.
|
|
- remove 2 unneeded windowTitle attributes, which bloat our translations
- cleanup some unneeded .cpp/.h includes and class usages
- use a more generic string for clearing sendcoinsdialog and
requestpaymentdialog
- edit 2 strings in BitcoinGUI and replace "edit" with "show" as this
seems more clear in the context where it is used
|
|
|
|
This required some code movement (what was CWalletTx::AcceptToMemoryPool
doing in main?), and adding a few explicit includes that used to be
implicit through init.h.
|
|
allow emit message() in sendcoinsdialog and walletview
|
|
They're supposed to be children of the walletview, and are added with
addWidget later on.
Inconsequential change because the object passed was already 0.
|
|
- remove an obsolete connection to a signMessage() signal
|
|
- changes some strings that were forgotton or made no sense in the conext
they are used
- remove an orphan file from the qt project file
- revert a small change in signverifymessagedialog.ui
- guard #include "bitcoin-config.h" with #if defined(HAVE_CONFIG_H)
- remove windowTitle from addressbookpage.ui
|
|
- this allows us to use emit message() over MessageBox:: or gui->message()
calls in sendcoinsdialog and walletview
- move main handlePaymentRequest() functionality back to BitcoinGUI
- move a showNormalIfMinimized() before gotoSendCoinsPage()
|
|
qt: improve "receive coins" workflow
|
|
- We no longer have an address book, but "address lists", update message
accordingly
- Add tooltips here and there
- Clarify text on buttons
- add Copy Address button to receive request dialog
|
|
Qt: move paymentACK handling to paymentserver
|
|
|
|
- add new slot handlePaymentACK() to paymentserver, which handles
paymentACK messages (currently we just display them)
- make paymentACK message a modal information dialog
- change some QObject::tr() to just tr()
- clarify the processPaymentRequest() error, when IsDust()
- small string change to prevent a tripple + usage with QString
|
|
bitcoingui: show main window (if hidden) on modal messages
|
|
- as we have main.h included in transactiondesc.cpp, we now also use
COINBASE_MATURITY + 1 for the descriptive string
- fixes #3131
|
|
|
|
Simplifies the dialog (makes it look less crowded) as well
as the code and makes it possible to copy multiple fields at once.
Also format bitcoin URI as URI, add copy button for URI.
|
|
Follow the same pattern as the parseBitcoinURI function.
|
|
This brings some symmetry into the design by using the same object
both for incoming URIs that are parsed as for outgoing URIs that
are formatted.
|
|
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.
|