The same styling as for a selected row, is applied for a hovered row.
This makes the UI more intuitive, helping users better navigate through and focus on specific rows, especially in large tables.
A few CSS selectors affecting table and list row coloring were moved the dark theme stylesheet (theme-dark.css) to the common stylesheet (bisq.css).
These selectors are theme-independent, since they re-use variables defined in each theme stylesheet (like -bs-background-color). Therefore a more appropriate place for them is in the common stylesheet.
This move means that alternating row background colors are now available for all tables and lists, in all views, in both dark and light themes.
The OfferBook tables now show the amount and the volume as min-max range, where appropriate.
For the offers that have no range defined, the single values are shown.
Fixes#3129
When creating an offer the small QR code displayed for funding
was off by an amount that represent the mining fees. This was due
to the QR code being displayed simultaneously with the wallet
calulating the fee.
We fix the issue by listening to the data model `missingCoin`
value of the offer object, and updating the QR code image
appropriately.
Fixes#3666Fixes#4194
The table in the BondsView uses string sorting by default. This results in unexpected behavior when sorting non-string columns.
This commit adds custom comparators to the numeric columns to address that.
Fixes#3231
and do not broadcast.
It is unclear why we receive expired data (some are very old), but a
manipulated node might produce that and as it only removed at each
batch process running each minute to clean out expired data it still
could propagate. Is an attack vector also to flood the network with
outdated offers where the maker is likely not online.
Should fix https://github.com/bisq-network/bisq/issues/4026
We add a second button (displayed as first) to the preferences UI for
resync from latest resources. We add a warning to the resync from
genesis as it takes very long time and causes heavy network load for
seeds.
The resync button at the stateMonitor does now a resync from resources,
not from genesis.
We add handling of the UnconfirmedBsqChangeOutputList file as well.
In Filemanager we add a check if file exists.
The trader chat view can be opened either by clicking on the chat icon
of a trade in the list, or clicking on "OPEN TRADER CHAT" button for the
currently displayed trade. In the latter case, the count of new messages
displayed on the chat icon was not cleared even though trader chat
was shown. The solution is to move the scope of the routine that
updates trader chat message count from within the table cell handler
to the PendingTradesView class so that it can be called whenever
onChat() is invoked (i.e. when the Trader Chat screen is shown).
Clicking on the trader chat icon of a trade that is not selected
should select that row in the trade list. It does not. This causes
confusion as it gives misleading cues as to which trader you are
communicating with.
Issue a call to select the row of the button when clicked.
Fixes#4172
When editing an offer to adjust the price the fiat amount is
recalculated to reflect the new price. The BTC amount should
not change. Due to a bug, sometimes the BTC amounts were
changed due to a recalculation from the fiat amount.
This PR Fixes 2798 by disabling a call to recalculate BTC and
min BTC amounts when editing.
Fixes 3871. The BTC amount of an offer was being adjusted up in
certain cases due to a rounding calculation from the fiat value
and price. This would prevent some offers from being taken.
There's an existing check to ensure that the amount is not adjusted
below the minimum, here we add a check to ensure that the amount
is not adjusted higher than the maximum defined in the offer.
* Add signed witness filter
- Add a filter to pubkeys used in AccountAgeWitness signing
- Fix inverted arbitrator signing of initial account age witnesses from
disputes
- Add test to verify that signed witness filter works
- Add test to verify that the arbitrator signing was fixed
* Fix codacy complaints
* Prevent NullPointerException during toggle group initialization
* Add scrollbar to filter window
* Format test class
Co-authored-by: Christoph Atteneder <christoph.atteneder@gmail.com>
The moment we are validating the tx is not committed and therefore the
connected tx output is not wired up and thus null.
Refactor and consolidate the validation code to the static class and
improve error handling.
The moment we are validating the tx is not committed and therefore the
connected tx output is not wired up and thus null.
Refactor and consolidate the validation code to the static class and
improve error handling.
The runAfter* methods delegate to UITimer::run(Later|Periodically) in
the case of the desktop application. These use the JavaFX TimeLine API
(via bisq.common.reactfx.FXTimer) to schedule future events. However,
this API isn't thread safe and isn't meant to be called outside the FX
application thread. This causes occasional misfirings and out-of-order
scheduling when UserThread::runAfter is called outside the user thread.
Make the UITimer::run* methods safe to call from any thread by checking
we are in the application thread and delegating to UserThread::execute
otherwise. This also improves consistency between the contracts of the
runAfter* and execute methods. As the former has many call sites, this
is safer than trying to track down all the non-thread-safe uses.
(The Timer used in the headless app already appears to be thread-safe.)
This fixes#4055 (Bisq sometimes fails to prompt user for password to
unlock wallet), caused by out-of-order scheduling of the execute and
runAfter tasks in the WalletConfig.onSetupCompleted anonymous class
method in bisq.core.btc.setup.WalletsSetup.initialize.
Also prevent an exception caused by non-thread-safe calls into JavaFX
during the shutdown of OpenOfferManager, which was uncovered by the
above, by adding a missing UserThread::execute call.
Showing an `Open Trader Chat` button until the trade period is over will
reduce the number of unnecessary support tickets and encourage
trader-to-trader dialogue. If the trade timer expires without
completing the button changes (as before) to open a mediation ticket.
Implementation of this feature requires the button in TradeStepView to
notify its parent TradeSubView which in turn notify its parent
PendingTradesView that trader chat is to be opened. Basically a
callback interface is passed two levels down the GUI hierarchy.
Fixes#3801
- added a comment describing the `removeDust` method and its effects.
- use more descriptive variable names.
- made the logging more verbose to help log readers.
- use a constant for the dust limit
- add a notice to the user when dust is padded to the fee
Before, the graceful shutdown procedures have been executed in the
user thread. However, the sync mechanics for connections/offers
caused a lockup, as some little parts of the code do execute on the
user thread as well.
Display the account number on the same row as the sort code in the trade
step view, to prevent scrolling with the extra name field (as suggested
in the code review).
(This also affects the layout of old accounts without the extra field.)
Also apply the suggested popup text simplifications.
Open an info popup in the take/create offer view, upon choosing to take
or make a new offer, to instruct the user to recreate their old Faster
Payments account with an owner full name (and preserved salt). Also show
the popup upon manual selection of any old (i.e. missing full name)
Faster Payments account from the trading account combo box, analogously
to the ClearXchange (Zelle) warning popup logic.
(Also eliminate slight differences between the private
'maybeShow[ClearXchange|FasterPayments]Warning' methods in TakeOfferView
and MutableOfferView, to make the code easier to deduplicate in future.)
This change fixes an issue whereby dust change outputs are
inadvertently created when users make withdrawals from their
wallets. (Funds -> Send Funds)
The solution taken here is to detect a dust TXO during the withdrawal
fee estimation process and add that amount to the fee thus eliminating
the dust output.
For example if the user has 1 BTC and goes to withdraw 0.99999900 BTC
it will detect a change TXO of 100 sats which is below the dust limit,
increase the fee by 100 sats and therefore withdraw 1 BTC.
This fix only applies to user withdrawals from their wallet. Other
use cases such as P2P trading, deposits and fees will be handled
separately.
Related to #4039
