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

Call OnChange with every updateText, fixes #4117 #4121

Merged
merged 6 commits into from
Aug 20, 2023

Conversation

mbaklor
Copy link
Contributor

@mbaklor mbaklor commented Aug 2, 2023

Description:

This adds a call to entry.OnChanged() every time entry.updateText is called.
While I was at it I also added a call to e.Validate where I didn't see one.

Fixes #4117

Checklist:

  • Tests included.
  • Lint and formatter run with no errors.
  • Tests all pass.

@coveralls
Copy link

coveralls commented Aug 2, 2023

Coverage Status

coverage: 65.282% (+0.007%) from 65.275% when pulling d21ec3e on mbaklor:entry-callback into 6f2c727 on fyne-io:develop.

Copy link
Member

@Jacalz Jacalz left a comment

Choose a reason for hiding this comment

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

Thanks for the PR. This does indeed fix the issue but I noticed that introduces some unwanted side effects that I think we need to handle. Some of the functions that now validate and run OnChanged does unfortunately later on call them again. I left some comments inline about what we need to look out for.

widget/entry.go Outdated
e.propertyLock.Unlock()

e.Validate()
if changed && e.OnChanged != nil {
e.OnChanged(provider.String())
Copy link
Member

@Jacalz Jacalz Aug 2, 2023

Choose a reason for hiding this comment

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

You should avoid calling provider.String() multiple times. If you look at the code you will see that it allocates an entirely new string each time. You probably want to save the string to a variable. Have a look at TypedRune to see how it is handled there.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

np, fixed in next commit

widget/entry.go Outdated
if e.CursorRow == e.selectRow && e.CursorColumn == e.selectColumn {
e.selecting = false
}
e.propertyLock.Unlock()
e.Validate()
Copy link
Member

Choose a reason for hiding this comment

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

This leads to unwanted side effects. Pressing tab inside a multiline entry calls validation twice but we also validate the text even in all cases where we know that nothing has changed (i.e. moving the cursor using tab keys but also pressing keys like home, page up, end etc.). I don't think doing validation that often will be good if users have slow validators.

widget/entry.go Outdated
e.updateText(provider.String())
changed := e.updateText(provider.String())

e.Validate()
Copy link
Member

Choose a reason for hiding this comment

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

This change also leads to verifying twice (potentially running OnChanged twice as well, I would assume) when selecting something and then pressing another key using TypedKey or TypedRune to replace the text.

@Jacalz Jacalz changed the title fix #4117 call OnChange with every updateText Call OnChange with every updateText, fixes #4117 Aug 2, 2023
@Jacalz
Copy link
Member

Jacalz commented Aug 2, 2023

FYI @mbaklor. I think the Fixes # needs to be on a separate line for GitHub to understand that it should be closed. I updated the text for you :)

@mbaklor
Copy link
Contributor Author

mbaklor commented Aug 2, 2023

Very fair, I actually threw the validate in all those cases as an afterthought because I think hitting backspace should validate as well. I'll take a look tomorrow and remove unnecessary ones and think how best to validate backspace 😁👍

@mbaklor
Copy link
Contributor Author

mbaklor commented Aug 3, 2023

okay as you can see I'm very good at using the comments thing in the code lol, I just tested (manually, I should've probably written a test but I only thought of checking after the commit 😅) and looks like everything now calls validate and onchanged only once

@andydotxyz
Copy link
Member

I haven't tested myself, but at a glance I would be concerned that highlighting text and the entering a key may validate and fire handlers twice - once when clearing selection and another when entering the new text.
The "clearSelection" was created as a helper so be sure to check all the places it is called.

@mbaklor
Copy link
Contributor Author

mbaklor commented Aug 5, 2023

Within TypedRune there's a little snippet to clear OnChanged before erasing selection, so I figured it was fine, I'll go over where eraseSelection is called again just to be sure

@mbaklor
Copy link
Contributor Author

mbaklor commented Aug 9, 2023

okay so there were some repetitions of the callbacks from eraseSelection, so I removed the callbacks from there and into where it wasn't called when not in eraseSelection. Hope this was the correct choice, lmk if that's not the solution

@Jacalz
Copy link
Member

Jacalz commented Aug 15, 2023

There are a lot of test failures (crashes). Would you mind having a look at those?

@mbaklor
Copy link
Contributor Author

mbaklor commented Aug 15, 2023

oh my god I should not push commits at 1:00 AM (not that now isn't 1:00 AM but it is what it is)

yes I didn't check that OnChanged exists before calling it. fixed now. commit incoming 😅

andydotxyz
andydotxyz previously approved these changes Aug 18, 2023
Copy link
Member

@andydotxyz andydotxyz left a comment

Choose a reason for hiding this comment

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

Looks great, thanks so much

Copy link
Member

@Jacalz Jacalz left a comment

Choose a reason for hiding this comment

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

Thanks. This is looking great. I just released that we still are allocating new strings in this code so I added some suggestions inline to remedy the issue.

Sorry for the long review process. This will be ready to land very soon, I promise :)

widget/entry.go Outdated
Comment on lines 835 to 837
content := e.textProvider().String()
if e.OnChanged != nil {
e.OnChanged(content)
Copy link
Member

@Jacalz Jacalz Aug 18, 2023

Choose a reason for hiding this comment

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

I realized that this still is creating a new copy of the string. Looking at eraseSelection, it calls e.updateText() which sets the e.Text field and as we are in a lock we can simply reused that instead of recreating the string once more (slow and potentially uses a lot more memory for large strings).

Suggested change
content := e.textProvider().String()
if e.OnChanged != nil {
e.OnChanged(content)
if e.OnChanged != nil {
e.OnChanged(e.Text)

widget/entry.go Outdated
Comment on lines 1058 to 1060
content := e.textProvider().String()
if e.OnChanged != nil {
e.OnChanged(content)
Copy link
Member

Choose a reason for hiding this comment

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

Same comment as above applies here.

Suggested change
content := e.textProvider().String()
if e.OnChanged != nil {
e.OnChanged(content)
if e.OnChanged != nil {
e.OnChanged(e.Text)

@Jacalz
Copy link
Member

Jacalz commented Aug 20, 2023

@mbaklor Would you be able to get the last two changes done soon? This is one of the remaining release blockers and it would be good to have it resolved as soon as possible :)

@mbaklor
Copy link
Contributor Author

mbaklor commented Aug 20, 2023

Yes absolutely, I was planning on getting it done tonight, I'll see if I can get to it earlier but I doubt

@Jacalz
Copy link
Member

Jacalz commented Aug 20, 2023

Great. Thanks. There are other blockers that haven't been solved yet so a few hours earlier or later today isn't a problem

@mbaklor
Copy link
Contributor Author

mbaklor commented Aug 20, 2023

Sorry for the long review process. This will be ready to land very soon, I promise :)

No worries, I'm honestly glad for the long and thorough process, I'm still rather insecure in my golang and happy to have someone else make sure what I'm contributing won't break the library 😉

Copy link
Member

@Jacalz Jacalz left a comment

Choose a reason for hiding this comment

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

This looks great now and solves one of the important blocker bugs which is wonderful. Thanks for working on this and congratulations on landing your first change into Fyne :)

@Jacalz Jacalz merged commit 8be6541 into fyne-io:develop Aug 20, 2023
11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants