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>
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.
Run through the 'DecryptedBallotsWithMerits' list of each cycle in
parallel, when filling the cycle list of the Vote Result view, to speed
up the signature verification of all the 'Merit' objects found in the
DAO state. Checking all the signatures is necessary to correctly compute
the total merit stake and hence the vote weight of each ballot list, and
profiling shows that it is by far the biggest bottleneck during the
initial view load (with all subsequent activations of the view skipping
'doFillCycleList()', when outside of the Vote Result DAO phase).
(Since each signature is checked only once from 'doFillCycleList()' and
skipping the checks could potentially affect the computed vote weights,
we cannot obviously do any better than parallelise the checks, to speed
up this method.)
(Even though it may be a little more efficient to parallelise the outer
loop of the method, over the cycles instead of the decrypted votes of
each cycle, each individual signature check is expensive enough that it
probably wouldn't give much improvement over this one-line change.)
Uniformise the log patterns somewhat, by making the 'Logger' classname
field width either 15 for the seednode & statsnode, or 40 for the other
applications (lengthened from 30 in a few cases).
Also clean up the logback XML files somewhat, in particular removing
references to the old Thali (thaliproject/Tor_Onion_Proxy_Library) Tor
library, which was replaced years ago with our own fork of NetLayer
(https://github.com/cd2357/netlayer).
Finally, add a missing space back to the log pattern for bisq-desktop,
to prevent DEBUG, ERROR or TRACE lines appearing as follows:
... [JavaFX Application Thread] ERRORb.c.s.CommonSetup: ...
(It isn't clear whether this recently introduced behaviour was really
intentional, though it did prevent two consecutive spaces appearing in
the majority INFO log lines.)
This should hopefully resolve images failing to load from resources
on Windows due to problems with imread encountering "can't open/read
file: check file path/integrity".
This restores the functionality that was removed in b5beea58. However,
this implementation utilizes the JavaCV library rather than the
webcam-capture library as discussed in #4940. As a result, this should
now provide macOS support.
Fix raw usage of the following types, all of which (apart from
Comparator) touch the DAO packages somewhere:
Comparable, Comparator, GetStateHashesResponse, NewStateHashMessage,
RequestStateHashesHandler, PersistenceManager
(Also replace 'Integer.valueOf' with the non-boxing but otherwise
identical method 'Integer.parseInt', in the class 'TxOutputKey'.)
Replace all raw uses of 'Bond<T extends BondedAsset>', mostly with
wildcards (that is, 'Bond<?>'), to prevent compiler/IDE warnings.
Also rename the 'T extends Bond<R>' & 'R extend BondedAsset' type params
of 'BondRepository<..>' to 'B' & 'T' respectively, as this is a little
less confusing.
Use 'Tx::getBurntBsq' instead of 'Tx::getBurntFee', so as not to exclude
BSQ burned by invalid txs from the supply calculations. There are no
invalid BSQ txs at present on mainchain, but accidentally burned BSQ
should definitely count as a reduction in supply, so this fixes a bug.
1. Tidy up the stream pipelines which sum over time intervals, by
summing directly with a grouping collector, instead of wastefully
collecting to an intermediate map of lists;
2. Move duplicate 'memoize' static method to the base class;
3. Factor out 'getDateFilteredMap' static method, to replace the
repeated pattern of filtering date keys by a provided predicate and
collecting into a new map;
4. Use 'Map::replaceAll' instead of the pattern:
map.entrySet().forEach(e -> e.setValue(updateFn(e.getValue())));
5. Fix a quadratic time bug in 'getBsqMarketCapByInterval' by passing an
ordered map to 'issuanceAsOfDate', so that it doesn't have to
repeatedly sort or linearly scan the entire keyset of time intervals,
to find the latest one before the provided date.
Fix inspection warnings and other minor defects (unchecked casts, bad
'assert*' usage, unused assignments/declarations, missing null checks,
object equality on enum instances, needless statement lambdas, missing
final, redundant 'toString', needless visibility) in 'TxValidatorTest'.
Also, uniformise and slightly tidy resource loading in other test
classes, replacing 'Files.readAllBytes' with Java 11 'Files.readString'
(which assumes UTF-8 as desired, instead of the default charset).
Set loge level for org.berndpruenster.netlayer.tor.Tor to WARN (we get repeated logs about HS announced to network from netlayer - would be better to change in netlayer).
Make data request/response logs more visible with line breaks
When creating or taking an offer the user gets the choice to fund the
trade from an external wallet for potentially better privacy (avoid
coin merge if inputs from ext. wallet are kept separated). From
feedback it seems that most users are not using that option and then
they need to do that extra click on the "Fund from internal Bisq
wallet" button.
We offer a way to avoid that extra step if the user chooses
to use the internal wallet. We show at the first time a popup
with background info why funding from an external wallet could
improve privacy and if the user prefers to not use that to give them
an option to skip that step in future. In the settings we could add
a toggle to re-enable it again.
The review screen can be skipped if user chooses this feature,
leading to data entry > confirm rather than
data entry > fund > review > confirm.
This is useful in cases where a user did not receive the ticket
closure message:
The user messages the arbitrator asking for clarification.
Arbitrator re-opens the ticket and re-sends the closing message.
Previously the dispute message would only be sent once the DPT had
finished propagation. To a user it would appear as if nothing
happened and they would attempt to initiate the process again.
That would cause the DPT logic to fail (we already have an
open timer etc..) and the logic failing would result in no
happy path therefore no Dispute message being sent.
Testing confirmed there is no requirement for the dispute to be
chained on the successful propagation of the DPT to nodes.
Both the DPT and the dispute can be attempted again by the user
if necessary. Rebroadcasting an already published DPT causes
no harm. Re-sending the dispute message also causes no harm
as there is logic to detect if it already exists and handle it
gracefully.
