When the application window is being created, it checks what the
maximum bounds for a window is in order to set the window size.
However, multi-screen environments may encounter an
IllegalArgumentException (Window must not be zero).
Just ignore the exception and continue, which means the window will
use the minimum window size since we are unable to determine if we can
use a larger size.
Fixes https://github.com/bisq-network/bisq/issues/2452
- As teh network is used for filtering asset types BSQ has 3 asset
types, one per network we need to use REGTEST as network. The methods
for checking which BaseCurrencyNetwork are using name() now instead of
network as we have 2 times REGTEST.
- Fix bug with not calling showFeeInfoAndPublishMyProposal for bonded
role proposals.
- Set BTC_DAO_TESTNET as last enum to not break existing regtest port
convention which is derived from enum order
- Remove BaseCurrencyNetwork.isBitcoin as always true
-
Currently, the download update task will download the deb package for
any Linux distribution. Not only is this incorrect, but now that we are
able to provide an rpm package (see #2200), the download update task
needs to be able to differentiate Linux distributions and provide
the appropriate package.
The download update task will now differentiate between Debian and
RedHat based distributions (the two distributions for which we have an
install package) and download the appropriate package.
In addition, the isSupportedOS method was changed to exclusively check
for Debian and RedHat based distributions, as opposed to just Linux in
general. This means that any other distribution will encounter the
following error, which seems appropriate:
> Unable to determine the correct installer. Please download and verify
manually at https://bisq.network/downloads
- Rename model.getBtcSyncProgress() to model.getCombinedSyncProgress()
to reflect correct property
- Use bisqSetup.getBtcSyncProgress() instead of
getCombinedSyncProgress() in showFirstPopupIfResyncSPVRequested as we
need to listen to btc progress only not DAO progress.
- Make all PaymentMethod constructors private
- Use PaymentMethod.getPaymentMethodById in Offer for getting the
PaymentMethod. This change a bit the context as now we always create the
PaymentMethod from the actual code base in contrast to the data which
have been used when creating the offer. As our fields as final and must
not change in software updates it should have no issues but we have to
keep that in mind to not alter the default values.
- Added a runtimeException in case the maxTradeLimit does not match one
of our default values.
- Use PaymentMethod.getDummyPaymentMethod(GUIUtil.SHOW_ALL_FLAG)
instead of new PaymentMethod(GUIUtil.SHOW_ALL_FLAG))
- We had an automate remove accounts for those payment methods for long
time, so we can assume that no traders have any of those accounts still
in their persisted user objects and it is safe to completely remove them.
Only part where we cannot remove it is the PB definitions (actually I
think we could remove those as well, but not 100% sure and it seems to
be more safe to mark those as deprecated and leave the entries).
- Assign paymentMethods in static final field
- Add static fields for default trade limits
- Remove deprecated payment methods
- Remove onAllServicesInitialized and use static initializer instead
- Re-purpose maxTradeLimit for indicating risk factor
- Calculate real trade limit in the getMaxTradeLimitAsCoin method
- Rename getActivePaymentMethods to getPaymentMethods
