Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Traders chat #3165
I share the PR so that others can add optimisations for design and wording.
On the way to adding chat for traders this is a first step. Mainly just moving functionality out of TraderDisputeView to Chat class. There are still remaining dispute functionality that needs to be factored away.
The naming of DisputeCommunicationMessage has to stay but they otherwise fit what would be more aptly named ChatCommunicationMessage or something in that spririt.
Move session classes to core. Break out DisputeCommunicationMessage handling from DisputeManager and put in ChatMananger prepare for other uses of ChatManager. Renaming of DisputeCommunicationMessage would be nice but it's representing the protobuf messages so the name has to stay.
- Add communication messages to Trade protobuf message to be able to save chat messages per trade - Add Type enum and field to DisputeCommunicationMessage protobuf to be able to dispatch Dispute and Trade chat messages properly - Rename some function as isClient instead of isTrader to make it easier to understand who is who when two traders are communicating with each other
# Conflicts: # core/src/main/java/bisq/core/arbitration/DisputeManager.java # core/src/main/java/bisq/core/arbitration/messages/DisputeCommunicationMessage.java # core/src/main/java/bisq/core/trade/Trade.java
# Conflicts: # desktop/src/main/java/bisq/desktop/main/disputes/trader/TraderDisputeView.java
I just did more in-depth testing and everything works as expected. Also having arbitration case in parallel to the trader chat for a specific message doesn't cause any issues. Great work @sqrrm and @chimp1984
If that is done I'm happy to merge this PR to master.
- Store last position of the chat window so if it gets closed and opened again it opens at the last position. - Fix issues with the listener for new messages. The handler was called multiple times before. Now its is called only once. Tested with multiple trades and scrolling. We use maps for each trade to avoid multiple listener registrations when switching views. With current implementation we avoid that but we do not remove listeners when a trade is removed (completed) but that has no consequences as we will not receive any message anyway from a closed trade. Supporting it more correctly would require more effort and managing listener deactivation at screen switches (currently we get the update called if we have selected another view. This part can be improved if any dev feels motivated but its not trivial...