Filter offers at OfferBookViewModel when the DaoState changes.
Check for offers amount exceeds trade limit at OpenOfferManager and add it to invalidOffers.
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
Another option would be to store the selection the user has made, but the automatic navigation is kind of confusing and ppl forget that they might have previously selected to prefer to go to open offers. The intent of the popup is that users learn where they can find their created offer which is achieved if the user navigates once there.
If tests are run via gradle I get an error:
`Loading library prism_es2 from resource failed: java.lang.UnsatisfiedLinkError: Can't load library: /Users/dev/.openjfx/cache/16/libprism_es2.dylib`
If run from the IDE it works.
CI on windows also fails, other OS work.
Seems that there are some platfomr specific dependency issues...
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
Make the 'dataMap' field a ConcurrentHashMap instead of a HashMap, to
prevent a ConcurrentModificationException, which was recently observed
when calling 'IgnoredMailboxMap::toProtoMessage' from the persistence
manager inside the user thread during startup of bisq-desktop. Tracing
through the code, this likely happened during an iteration through the
keyset of 'dataMap' (to check for nulls, inside the proto serialisation
logic during persistence), while simultaneously adding ignored mailbox
messages to the map on a separate thread spawned from the method,
'MailboxMessageService::threadedBatchProcessMailboxEntries'. (The latter
was made asynchronous so as not to block the UI.)
(Since there is a call to 'PersistenceManager::requestPersistence' after
every addition to the ignored mailbox map, there hopefully won't be any
missed entries in the final persisted map, even though the snapshot of
ConcurrentHashMap being iterated through won't be fresh as long as new
entries are simultaneously added.)
As the MarketPricePresentation constructor had anyway a ugly setup code we resolve it by refactoring it to a bit less ugly solution. ;-)
Remove the btcWalletService and feeService dependencies from MarketPricePresentation.
Do the setup of static fields in TxIdTextField and GUIUtil in the applyInjector method in BisqAppMain.
Signed-off-by: HenrikJannsen <boilingfrog@gmx.com>
Make sure to include the BSQ stake, and not just the merit stake, when
summing to get the 'voteWeight' field of the vote on each evaluated
proposal in the exported vote results history JSON.
Avoid needlessly repetitive (once per cycle proposal) signature checking
of each 'Merit' object in the DAO state, when exporting the voting
history JSON, by moving the merit calculations to the outer loop over
each cycle, storing the sums in a map by blind vote txId. As signature
verification is expensive, taking seconds to run just once over every
'Merit' object, this is by far the biggest bottleneck when generating
the JSON.
Remove another hotspot in the proposals table creation for a selected
cycle, by making 'ballotByProposalTxIdMap' a field of 'VoteResultView',
recomputed at the same time the cycle list is populated upon calling
'doFillCycleListAndBallotMap()' (renamed from 'doFillCycleList'), when
the Vote Result view is activated.
Also remove an unnecessary outer loop when determining if the user's
vote is included in the result, upon selecting a cycle list item, to
avoid searching the BSQ wallet repeatedly for the same vote reveal tx.
The 'tableRow' field of each (voted upon) proposal list item is reset
upon selection of a cycle list item in the Vote Result view, but not set
anywhere, so remove the field along with its set/reset methods.
