Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fyne History Page Implementation #439

Open
wants to merge 74 commits into
base: master
Choose a base branch
from

Conversation

Sirmorrison
Copy link
Contributor

@Sirmorrison Sirmorrison commented Nov 5, 2019

Fixes #439

image

image

image

image

image

image

image

@Sirmorrison Sirmorrison marked this pull request as ready for review December 4, 2019 07:01
@oshorefueled
Copy link
Contributor

The history page seems to work when using one wallet. However, it's not fully functional with multiple wallets. First, how multiple wallets are displayed. A dropdown would be more suitable for displaying users' wallets. You can use the "receive" page as a reference for that.

Screenshot 2019-12-15 at 1 55 53 AM

I get an empty transactions result when I try switching between wallets and that's just one of the issues. Kindly create multiple wallets and test.

Screenshot 2019-12-15 at 2 09 57 AM

terminal/pages/history.go Outdated Show resolved Hide resolved
cli/go.sum Outdated Show resolved Hide resolved
fyne/helpers/amount.go Outdated Show resolved Hide resolved
@oshorefueled
Copy link
Contributor

Copy link
Contributor

@metaclips metaclips left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should try to split components to separate functions and place them in the handler package for easy review also scrolling seems very slow, can we reduce transaction table per scroll to 15 instead of 25?

fyne/pages/history.go Outdated Show resolved Hide resolved
fyne/pages/history.go Outdated Show resolved Hide resolved
fyne/pages/history.go Outdated Show resolved Hide resolved
@Sirmorrison
Copy link
Contributor Author

You should try to split components to separate functions and place them in the handler package for easy review also scrolling seems very slow, can we reduce transaction table per scroll to 15 instead of 25?

As a matter of uniformity, across all godcr interfaces, the txperpage is 25.

@metaclips
Copy link
Contributor

You should try to split components to separate functions and place them in the handler package for easy review also scrolling seems very slow, can we reduce transaction table per scroll to 15 instead of 25?

As a matter of uniformity, across all godcr interfaces, the txperpage is 25.

Scrolling is slow and table contents distorts while scrolling we should reduce table contents.

@oshorefueled
Copy link
Contributor

oshorefueled commented Dec 24, 2019

Is it necessary that we use a horizontal scroll?
Screenshot 2019-12-24 at 9 45 56 AM

cmd/go.mod Outdated Show resolved Hide resolved
@metaclips
Copy link
Contributor

Is it necessary that we use a horizontal scroll?
Screenshot 2019-12-24 at 9 45 56 AM

There are contents we can do away with.
I don't see why the texts are needed with the icons in Direction line, type can also be removed and also hash text can be reduced so that the width wont be jumpy when users switch pages.

@Sirmorrison
Copy link
Contributor Author

Sirmorrison commented Dec 25, 2019

Is it necessary that we use a horizontal scroll?
Screenshot 2019-12-24 at 9 45 56 AM

There are contents we can do away with.
I don't see why the texts are needed with the icons in Direction line, type can also be removed and also hash text can be reduced so that the width wont be jumpy when users switch pages.

Is the recommendation that i remove the icon?
About the jumpy pages why dont we give the fyne interface a fixed min width?

@Sirmorrison
Copy link
Contributor Author

Is it necessary that we use a horizontal scroll?
Screenshot 2019-12-24 at 9 45 56 AM

resolved

@oshorefueled
Copy link
Contributor

The transaction details popup seems to be losing part of its content to the edges of the window.

Screenshot 2019-12-27 at 10 31 14 AM

cmd/go.mod Outdated Show resolved Hide resolved
}

// Append widget adds to the bottom row of a table.
func (table *Table) Append(data ...*widget.Box) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You changed quite a number of code in the table.go. It's a widget I used on the overview page. It seemed to work well, any reason for the change? Would my existing implementation work without an issue if I used this?

Copy link
Contributor Author

@Sirmorrison Sirmorrison Dec 28, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had this these codes already before the overview page was implemented. Anyways have you tested your implementation on the overview page just to be sure there are no issues because overview page seems fine to me.?

@Sirmorrison
Copy link
Contributor Author

Sirmorrison commented Dec 28, 2019

The transaction details popup seems to be losing part of its content to the edges of the window.

Screenshot 2019-12-27 at 10 31 14 AM

so basically the issue is the change @metaclips suggested that we reduce the width of the history page. this also affected the txdetails popup as its wider than the current history page.
planetdecred/godcr#439 (comment)

Two things can done here.

  1. increase the width of the default history page to accommodate the details page.
  2. reduce the width of the details popup and add a horizontal scroll to view the hidden details to the right.

for now i will make it scroll horizontally.
image

Copy link
Contributor

@metaclips metaclips left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

scrolling seems to be much better, still needs little changes to UI.

  • Status table contents should be centered.

Screenshot 2019-12-28 at 20 04 13

- On transaction details page, confirmations-Data contents are not aligned, can we place them in a form widget? - All tables on transaction details page should be properly aligned

Screenshot 2019-12-28 at 20 08 13

- Info icon should be right aligned, and popup width should be reduced.

Copy link
Contributor

@metaclips metaclips left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should add an init prefix to component on history page and make the component that is to be initialised the first calling function and other helper functions below on each files for easy review and so that others wont have issues implementing features on the page.

}

if prepend {
txTable.Prepend(txBox...)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should try as much as possible not to use Prepend and Append function especially when users change to history page, can we instead call A NewTable instead for faster rendering , if users view history page?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will function more like pagination reason is for every update a new table will be called and this will have only data from the last tx fetched.


txCountForFilter, err := historyPage.MultiWallet.WalletWithID(historyPage.selectedWalletID).CountTransactions(allTxFilters["All"])
if err != nil {
historyPage.errorMessage = fmt.Sprintf("Cannot load history page page. Error getting transaction count for filter All: %s", err.Error())
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why are we passing error messages here? isn't there already a widget that handles that? Also, if err!=nil parameter is met, the app crashes, all component functions that require using dcrlibwallet should have a return parameter "error", you should stop all history page initialisation if any function throws an error.

Copy link
Contributor Author

@Sirmorrison Sirmorrison Dec 29, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is not true if there is an error at any point the error is returned the app does not panic... you should do well to test this properly as i have done so from my end...

if you are changing != to == you should comment out err.Error() else it will panic as there is no error to be returned.

image

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Screenshot 2019-12-30 at 19 58 06

This is what is shown when I make err == nil here, you are showing parts of history page components even when there was an error.
You shouldn't be passing errors to variables and then making a return

You are still calling up functions even if there was error on other functions called recently and then checking if any of the functions returned an error here

This shouldn't be as any of the functions that errors and returns early without initialising struct variable "HistoryPageData struct" could cause a panic in other functions if they use the uninitialised variable, you should instead pass return parameter "errors" to all functions that uses dcrlibwallet also InitHistoryPage function and then if any of the dcrlibwallet library functions return an error,

  • Stop the failed function, return the error
  • Stop history page initialisation in the handler package, return the error passed to InitHistoryPage
  • Check if InitHistoryPage function which is to be called in history.go file returns an err if there was an error, only show on history page a label indicating that there was an error initialising history page.

@oluwandabira oluwandabira added enhancement New feature or request fyne godcr-fyne labels Jan 13, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request fyne godcr-fyne
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants