Fyne: Seamless Entry widget typing

[botsarehots]

Is your feature request related to a problem? Please describe.
Typing in an Entry widget is not seamless. If you type fast enough, or just mash the keyboard, the displayed characters do not catch up to what was actually typed. The characters will eventually all be inputted, but if you press the Tab key before they all appear, the queued keys that have already been pressed will be inputted into the next Entry widget if pressing the Tab key leads to another one.

Is it possible to construct a solution with the existing API?
I have not been able to find a way at this time. Maybe finding a way to manipulate WigetRender to Refresh() after every KeyDown?

Describe the solution you'd like
Typing in an Entry widget to be as seamless as typing in a text editor or web browser. In addition, keys pressed before the Tab key should not be put in the next Entry widget.

[andydotxyz]

Can you provide some more information about the operating system and fyne version that you have seen this issue on?
We have been working on a more advanced event queue that should have addressed this so if we can know more about your setup then we can see if it's a new or old issue.
Thanks

[botsarehots]

OS: Ubuntu 18.04.3 LTS
~Fyne version: GitHub as of 2019/11/24~
Correction
Fyne version: go get fyne.io/fyne is where I got the code from and imported it from.

The feature request is still valid for the code in GitHub.

This is expected because it seems the imports are expected to have this code as a dependency anyways: "fyne.io/fyne/widget"

tool.go:4:2: code in directory ~/GolandProjects/src/github.com/fyne-io/fyne/app expects import "fyne.io/fyne/app"
tool.go:5:2: code in directory ~/GolandProjects/src/github.com/fyne-io/fyne/widget expects import "fyne.io/fyne/widget"

[andydotxyz]

OK, thanks. We have a fix in place on the develop branch that will be in our beta release today/tomorrow. Perhaps you can test again on either of those and if it's not resolved we can come back to it?

[botsarehots]

I've tested the code from go get fyne.io/fyne and go get github.com/fyne-io/fyne (which I then had to move to $GOPATH/src/fyne.io/fyne). Both are still not seamless.

[andydotxyz]

Did you manage to switch either from the default git “master” branch to our “develop” branch where we are preparing the next release?

[botsarehots]

I did not, I should have done that first.

But after I read that, I cloned the develop branch directly into the emptied $GOPATH/src/fyne.io/fyne and tested the demo just now. It is still affected.

[andydotxyz]

I'm sorry to hear that. Can you please confirm which commit this is so we can check?
Alternatively you could check out the v1.2.0-beta1 tag which we created this morning that marks the beginning of the preparation for 1.2 release.

[botsarehots]

But after I read that, I cloned the develop branch directly into the emptied $GOPATH/src/fyne.io/fyne and tested the demo just now. It is still affected.

The commit ID for this is: 0acd0c1031422a48a0441b60609ed535d8c14db2

Alternatively you could check out the v1.2.0-beta1

Sure thing. I just did this, it looks like its the same commit ID as the most recent commit, , 0acd0c1031422a48a0441b60609ed535d8c14db2. It is still affected.

[botsarehots]

Here's a quick screen capture video I made for this:
https://streamable.com/9fv3d

Here's the code for the example Fyne application:

package main

import (
    "fyne.io/fyne/app"
    "fyne.io/fyne/widget"
)

func main() {
    fApp := app.New()
    w := fApp.NewWindow("Example for GitHub")
    w.SetContent(widget.NewHBox(
        widget.NewVBox(widget.NewEntry(), widget.NewEntry()),
    ))
    w.ShowAndRun()
}

[andydotxyz]

Thanks, I think I see the source now.
Though I have not been able to replicate I have managed to write a test which simulates the problem.
There is another commit on the head of develop now that should resolve this issue.

[botsarehots]

Under commit f2b698cdca33e7454fb805bd6214629da3b21630 the effect in the screen capture video is still present.

[andydotxyz]

Thanks for this. Is the output exactly the same?
If you are running on top of that commit then neither entry would have cursors until focused - whereas in the previous video they both displayed one initially.
Apologies to ask, but I wanted to clarify

[botsarehots]

I tested it again.

neither entry would have cursors until focused

As of this commit, yes. Only the focused entry has a cursor which I did not notice until you pointed it out. But the typing is still not seamless and you can switch focus between widgets with the Tab key before the queued text is entered.

[andydotxyz]

Oh dear. Is there anything unusual about your computer of note? I see in the video that the text entry is very slow which is probably a factor. Are you running in a virtual machine or on a low power device?

[botsarehots]

Is there anything unusual about your computer of note?

Not to my knowledge.
Other programs that require input, such as the terminal or a text editor read and display input as expected.
In the video I used screenkey to show what I was typing in real time vs the real time behavior the Fyne application.

This is standard Ubuntu 18.04.3 LTS with gnome-session-flashback. I rebooted and tried it in vanilla 18.04.3 LTS and I get the same result.

The OS is the only OS (not dual booted, a VM, or anything) installed on my hard drive which is an SSD. It has a modern consumer processor: i5-9600K and 16 GB 2666MHz DDR4 RAM.

I installed golang from sudo snap install go --classic here is the entry from sudo snap list:

go                    1.13.4                      4762  stable    mwhudson      classic

Not that it should matter, but I tried another method and removed the snap and installed golang this way:

sudo add-apt-repository ppa:longsleep/golang-backports
sudo apt-get update
sudo apt-get install golang-go

I rebuilt and reran the test as usual, the effects are the same.

[andydotxyz]

Thank you for all the details, I will have to get an ubuntu installation and see if I can replicate the issue

[andydotxyz]

I have managed to replicate this on develop now as well

[andydotxyz]

Ok I have tracked this down. Somehow when lots of keys are pressed the underlying GLFW driver is sending the characters later than the key presses. The result is that the Fyne code is processing the events in the order they are sent resulting in what you describe.

I will probably have to take this upstream unless any GLFW experts know how to avoid this. Fixing for 1.2 now seems unlikely :(.

[andydotxyz]

I think this depends on #183, so it needs to move to 1.3 proposed release of Fyne.
This is a shame but it should not be a daily hassle for average users :)

[andydotxyz]

There seems to be a small improvement in the latest release of the library but it has not fixed it completely unfortunately.
We will need to work with the upstream project to explore this further.

[steveoc64]

Cannot replicate yet - either the latest develop branch has improved this to the point where the text update is much faster ... or my machine is too quick.

[andydotxyz]

You need to absolutely smash on the keyboard then press tab very fast.
That said I'm struggling too replicate now as well.

@botsarehots could you please test on the current develop and see if it's fixed for you please?

[botsarehots]

Using Ubuntu 20.04 and the latest fyne develop branch or when using v1.2.4 there is no longer any delay when typing rapidly or leaking over into another input widget when using Tab. (From what I can tell.)